Repository navigation
List the language Home in the front page solution menu and fix the Rust icon on a light page - #250
Merged
Merged
Conversation
why: Choosing a language on the front page opens a "Choose a solution" menu that listed Core Library, MCP and Workspace Manager but not the language's Home. The documentation picker on a port page lists Home first, so a reader who picked Rust on the front page had no way to the Rust landing page from that menu. The front page filtered Home out of the surfaces it passed down, and the picker drew a Home row only outside the solution menu. what: - Pass the launcher the surfaces getDocumentationSurfaces returns, Home included, and filter Home out only where the intro draws product cards. - Draw the Home row in solution menus as a destination with its arrow, using the home icon and "Home" label of the port-page row, in a compact height since it has no description. The port-page row keeps its markup, current mark and aria-current. - Keep the count to products, as on port pages. - Each language already owns a panel in the launcher, and the script only shows the panel of the selected language, so Home follows the language on first paint, without JavaScript and after a switch; no script needed a change. - Add home-launcher.test.ts, which renders the front page with the real launcher, picker and intro and checks, for every port, that Home leads, opens the language page the intro already offers, uses the documentation picker's icon, and stays out of the count and the cards. - Make the launcher browser check read Home first, its destination and the count, count product destinations without it, and fail on a Home that points at another language or no longer leads. verification: home-launcher.test.ts fails 34 of 34 on the parent commit (the first row is Core Library) and passes 34 of 34 here. The neighbouring picker, navigation, landing and home suites pass (313 tests). `check-dev.mjs --home-launcher` exits 0 on a dev server, including both Home controls.
why: With the site on Light and a phone in dark mode, the Rust icon in the language picker was white on a light page. rust-lang.org's SVG, vendored as it was downloaded, carries a prefers-color-scheme rule that turns the mark white. An SVG loaded through <img> evaluates that rule against the device or against the embedding page's color-scheme, depending on the browser. Desktop Chromium uses the page's, which the site sets from its Light, Dark or System choice, so the fault never showed on a desktop; the Android Chrome report shows the device deciding. No other file under public/brand has such a rule. what: - Remove the media block from the Rust icon so it is one dark mark; the rest of the file is byte-identical. Record the removal and both digests in rs/provenance.json, and in the language artwork notice, since CC BY 4.0 asks for changes to be indicated. - Lighten the mark with a filter in PagePortSwitcher, the only component that renders the language icons, when the page's resolved theme is dark. The owned shell resolves its theme into html[data-theme-mode], where data-theme names the brand, so the rule keys on data-theme-mode and, until the theme script runs, on the device preference, as brand.css does. - Drop the color-scheme rules on .home-language-icon from the head stylesheet; they steered the removed rule on the homepage only. - Add brand-svg-color-scheme.test.ts, which fails when any SVG under public/brand carries prefers-color-scheme, and a case that plants a rule to show the scan finds it. - Add check-language-icon-scheme.mjs, run with the homepage launcher check and with --home-controls. It reads the rendered mark in every pairing of device and site scheme on the homepage picker and a Rust page, with images resolving against the page or against the device (page color-scheme reset), and without JavaScript. Two controls must fail it: the old file's own rule under a dark device, and the filter removed on a dark theme. verification: brand-svg-color-scheme.test.ts fails on the parent commit naming languages/rs/icon.svg and passes here. On the parent commit the browser check fails when images resolve against the device, with the device light and the page dark, where the old file leaves a dark mark on a dark page; it passes with images resolving against the page, as desktop Chromium does. It passes here in every pairing, and --home-launcher and --status-badges exit 0 on a dev server. Not run on a phone: the device-resolved case stands in for Android Chrome.
tony
force-pushed
the
fix/front-page-home-row-20261103
branch
from
November 4, 2026 09:39
8601b2a to
5786716
Compare
tony
changed the base branch from
fix/ruby-core-showcase-refresh-20261103
to
main
November 4, 2026 09:39
tony
force-pushed
the
fix/front-page-home-row-20261103
branch
2 times, most recently
from
November 4, 2026 23:52
5786716 to
0b84b6e
Compare
why: Forced colors repaint the page from the system palette, which neither the site's theme nor the device scheme predicts. Firefox can paint a dark theme white, which put the inverted Rust mark white on white, and Chromium paints a light theme black for a dark device, which left the dark mark on black. The icon check ran in Chromium only, though engines differ in which scheme an image's own rules follow. The scan for those rules read public/brand only, while every SVG under public/ can be shown through <img>. The comment, the notice and the provenance said an image cannot follow the site's setting, which holds in some engines and not others. what: - Under forced colors the Rust mark drops its filter, which would invert the plate too, and sits on its own light plate, with forced-color-adjust: none so the palette leaves the plate alone. - check-language-icon-scheme.mjs reads every device and site pairing again under forced colors and expects the dark mark on its plate. It reads the plate and the mark inside the screenshot's edges, because an image at a fractional position puts a column of the page into its screenshot. A dark plate must fail the check in every engine, and in Chromium so must the mark without a plate. - --home-controls reads the icon in Chromium, Firefox and WebKit, after its other checks, and CONTRIBUTING.md names it beside --api-sticky. CI installs only Chromium, where the homepage launcher check keeps the Chromium pass. - brand-svg-color-scheme.test.ts scans every SVG under public/, and its planted case puts a rule in a registry icon and the root favicon as well as the brand artwork, since any of them can be shown through <img>. - The script header, the comment, the notice and the provenance say a browser does not reliably apply the rule to the site's setting when the file is shown as an image. verification: check-dev.mjs --home-controls passes in Chromium, Firefox and WebKit, with the controls failing as planted. With the forced-colors rule removed it fails in Chromium, the device light and the site dark, where the mark goes white on a white page. A probe of the plate under forced colors set the mark apart in each engine for every device and site scheme; without the plate the mark was lost in Chromium and Firefox. brand-svg-color-scheme.test.ts passes, and oxlint reports nothing on the changed scripts.
tony
force-pushed
the
fix/front-page-home-row-20261103
branch
from
November 5, 2026 00:04
0b84b6e to
eb29c8d
Compare
tony
marked this pull request as ready for review
November 5, 2026 03:05
tony
added a commit
that referenced
this pull request
Nov 5, 2026
why: Each port's MCP worked example drew only what its calls returned. Most calls that change tmux return an id and no layout, so after split_window the Go preview listed "Panes, sizes not read yet" and drew the split only at the next list_panes, captioned as leaving tmux unchanged. Every port had the same gap. Three Ruby example programs were also held off the Ruby API pages: workspace_apply.rb needed a file beside it, and the two control programs need tmux 3.7 while the pages said 3.3a. what: - The recorder reads its own sandbox tmux before the first call and after each one (sessions, windows with tmux's window_layout, panes with command, rectangle and active flag) and stores it on the step. It reads until two reads agree and every pane runs the expected shell, and treats a missing or exiting server as an empty tmux. - Checks the recorder, --check and the page share: parts refer to each other, one active window and pane, a layout names exactly its panes, a call names only ids that existed before it, a result returns only ids that exist after it, and a read-only tool leaves tmux unchanged. - The preview draws frame i from the state after call i, captioned "tmux after <tool>"; a recording without state keeps drawing from its results, and one whose state does not hold shows requests only. - Ten ports are recorded again (py, ruby, ts, rs, go, java, dotnet, cxx, swift, julia), and Julia's MCP page gains its first recording. The host-path scan and rewrite also catch escaped and encoded paths, which the committed Swift recording leaked. - Ruby's model pin moves from libtmux-ruby 20744401e to 0bf78344f, which takes libtmux-ruby #90, #91 and #93. #93 has workspace_apply.rb parse a document it writes itself and gives the example manifest (version 2) the capabilities of the two control programs. The Ruby reader states each program's tmux release from the export, so the three programs are shown and the control pages say tmux 3.7; an export without tmux releases keeps the old holds. This changes Ruby's pages only. Merged into main at 9e4bc21 (#250) from a branch based on 747f719.
This branch was successfully deployed
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
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.
Two fixes from the live site, on
mainafter #247.The front page solution menu lacked the language Home
Choosing a language on the front page opens a "Choose a solution" menu. It listed Core Library, MCP and Workspace Manager but not the language's Home, which the documentation picker on a port page lists first with a home icon.
index.astrofiltered Home out of the surfaces it passed to the launcher, andSurfacePicker.astrodrew a Home row only outside the solution menu.The launcher now receives the surfaces
getDocumentationSurfacesreturns, Home included, and the intro filters Home out where it draws product cards. In the solution menu the Home row is a destination with its arrow, using the port page's home icon and "Home" label, in a compact height because it has no description. The count still counts products only, and the port-page row keeps its markup, current mark andaria-current.The launcher renders one panel per language and its script only shows the panel of the selected language; it never rebuilds or retargets the solution links. Home therefore follows the language on first paint, without JavaScript and after a switch, and the script needed no change.
The Rust icon was white on a light page
With the site set to Light and the phone in dark mode, the Rust icon in the language picker was white on a white page. The vendored
rust-lang.orgSVG carried aprefers-color-scheme: darkrule, and an SVG loaded through<img>evaluates that rule against the device or against the embedding page'scolor-scheme, depending on the browser. Desktop Chromium uses the page's, which the site sets from its Light, Dark or System choice, so the fault never showed on a desktop; the Android Chrome report shows the device deciding. No other file underpublic/brandhas such a rule.The rule is removed from
rs/icon.svg, so the icon is one dark mark and the rest of the file is byte-identical.rs/provenance.jsonand the language artwork notice record the change, the upstream digest and the new digest, since CC BY 4.0 asks for modifications to be indicated. The page lightens the mark with a filter when the resolved theme is dark. The owned shell resolves its theme intohtml[data-theme-mode](itsdata-themenames the brand), so the rule keys on that attribute and, before the theme script runs, on the device preference, the waybrand.cssdoes. Thecolor-schemerules that the head stylesheet set on.home-language-iconexisted to steer the removed rule on the homepage and are gone.PagePortSwitcher.astrois the only component that renders the language icons, on port pages, native pages and the homepage picker.Under forced colors the system palette repaints the page, whatever the theme or the device prefers: Firefox can paint a dark theme white and Chromium paints a light theme black for a dark device. There the mark drops its filter and keeps its own light plate, with
forced-color-adjust: none.Verification
home-launcher.test.tsrenders the real front page, launcher, picker and intro. It fails 34 of 34 on the parent commit, where the first row is Core Library, and passes 34 of 34 here.brand-svg-color-scheme.test.tsscans every SVG underpublic/and fails when one carriesprefers-color-scheme; it fails on the parent commit naminglanguages/rs/icon.svg, and a planted case shows the scan finds a rule in the brand artwork, a registry icon and the root favicon.check-dev.mjs --home-launcherpasses on a dev server, including a Home that points at another language and a Home that no longer leads, both of which the check rejects.check-language-icon-scheme.mjsreads the rendered Rust mark for every pairing of device and site scheme, on the homepage picker and a Rust page, with images following the page or the device, and without JavaScript. On the parent commit it fails only when images resolve against the device, with the device light and the page dark, where the old file leaves a dark mark on a dark page. Two controls fail it on purpose: the old file's own rule under a dark device, and the filter removed on a dark theme.check-dev.mjs --home-controlsruns it in Chromium, Firefox and WebKit and passes in all three; with the forced-colors rule removed it fails in Chromium. CI installs only Chromium.check-dev.mjs --status-badgespasses with the Home row in the solution menu.