Repository navigation
feat(home): add an accessible pre-release banner - #6
Merged
Merged
Conversation
Adds a status strip above the hero: v0.1.0-rc.1 is in final testing, with no download links yet, plus a defensive footer-links wrap. Refs #5 Signed-off-by: Bugs5382 <12115015+Bugs5382@users.noreply.github.com>
The body sentence already said "follow progress on GitHub" right next to a link with the same label; the sentence no longer repeats what the link already says. Refs #5 Signed-off-by: Bugs5382 <12115015+Bugs5382@users.noreply.github.com>
My call: the README's lite emoji treatment (one emoji per H1/H2, decorative, nothing in code blocks or below H2) carries over to this page's headings -- a lock on the hero title, and one icon per section chosen to match its own wording (anchor for "trust anchor", key for "your keys", satellite for the fleet of linked nodes). Each icon sits in its content object as a Unicode escape rather than a literal character, since this repo's hooks block emoji in source files outside Markdown/GitHub config; the escape still renders as the real character in the built page. Every icon is wrapped in an aria-hidden span so screen readers read only the heading text. Refs #5 Signed-off-by: Bugs5382 <12115015+Bugs5382@users.noreply.github.com>
The two-line headline was wrapping to four visual lines on narrow phones and again in the two-column desktop layout, where this column is well under half the viewport. Scaled the font-size with a container query (clamp against cqw on the hero's own copy column, not the viewport) instead of a vw-based clamp, since the viewport width was never the real constraint, and added text-wrap: balance so a wrapped line breaks evenly rather than leaving a short orphan. Also bound the leading emoji to the headline's first word in a white-space: nowrap span, so they can never land on separate lines. Checked with a headless-Chrome script in scratch (line count from the h1's rendered height over its line-height, and scrollWidth vs clientWidth for overflow) at 320, 360, 390, 768, 1024 and 1440px: 2 lines and no horizontal overflow at every width. Signed-off-by: Bugs5382 <12115015+Bugs5382@users.noreply.github.com>
Moves each decorative emoji from the front of its heading to right after the word it pictures: the lock after "break into", the anchor after "anchor", the key after "keys", the satellite after "node". Added a shared splitTrailingWord helper (app/lib/text.ts) so both the hero H1 and the H2 Section headings can split off that last word and pair it with the emoji inside one white-space: nowrap span, still aria-hidden so screen readers only read the heading text. Re-checked the hero stays at or under 3 lines with the emoji now trailing: 3 lines at 320px, 2 lines everywhere else, no horizontal overflow at any of the 6 widths. Signed-off-by: Bugs5382 <12115015+Bugs5382@users.noreply.github.com>
The trust-model and fleetos-manager sections each put a single block of prose in a 42rem-capped column with nothing beside it, so on a wide screen the visible content sat in roughly the left half of the container while the hero and the what-it-is feature grid used the full width. Added an opt-in Section layout="split": head and body side by side in the hero's own 1.1fr/0.9fr column ratio, stacking to one column at the existing 860px breakpoint. The prose still wraps at its own readable max-width inside that column; only the section's layout changed, not its copy. what-it-is keeps the default stacked layout -- its feature grid already fills the width on its own. Extended the scratch check to measure the true rendered content width of each section (via Range rects over its text, not a wrapper div's box, since a block wrapper stretches to its parent's width even when its content doesn't) against the hero's, at 1024 and 1440px (the widths above the two-column breakpoint; narrower widths already stack to one column everywhere). It failed before this change (roughly 200-320px short at those two widths) and passes now (within 100px, matching how two columns of ragged prose and card text naturally differ). Signed-off-by: Bugs5382 <12115015+Bugs5382@users.noreply.github.com>
Contributor
Author
|
Approved. The site now carries the pre-release banner while v0.1.0-rc.1 is in final testing. |
This was referenced Oct 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
v0.1.0-rc.1 is in final testing and I want the site to say so before the first
release goes live, per the current plan. I added an accessible status strip
above the hero (a short badge, the heading and body, and a link to follow
progress) so visitors don't land on a page that looks finished with nothing to
download yet.
I also used this pass to work through the open items on #5 against the
seeded site (the design changed since that issue was filed against the old
docs-site home page, so each item needed re-checking on the new design, not
assuming it still applies):
(18.24:1 light, 14.81:1 dark) -- well past WCAG AA. No change needed; I'm
closing this one.
in the foreground/muted-foreground pair (always >= 5.8:1) rather than using
--warning/--warning-foregroundas a text pair, because that pair onlyhits 3.15:1 in the light theme (fails AA for normal text). The warning
token is used only as a border and a small dot, never for text.
was nothing to remove -- the new banner is now the real, accessible
pre-release warning.
(GitHub, Docs), so the old overflow doesn't reproduce, but I added
flex-wrap: wrapdefensively so a third link never causes horizontaloverflow on narrow screens.
style is for READMEs, and the seeded design already ships clean headings
without it, so I'm keeping this page consistent with the rest of the site.
Left open on #5 (not quick / not clearly specified for this PR):
Enterprise Number claim and its link to
/docs/using/tsa-policy-oid--that needs a fact-check against the docs site's content, which lives in a
different repo, before it goes on this page.
Verification
How this was verified
npm run lint,npm run typecheck,npm run buildall pass (lint showsone pre-existing warning on
home.tsxunrelated to this change, confirmedpresent on
mainbefore this PR too).node scripts/check-links.mjs build/client-- no broken internal links.task license-- every changed/added source file already carries theheader.
CI's lint/typecheck/build/link-check is the verification surface, same as
every other PR here.
(
vendor/cryptos-ui/tokens.css) rather than eyeballing them.Refs #5
Refs #5