18 CSS Settings Pages

The sidebar itself is pure CSS — the nav column is position: sticky with a top offset so it stays in view while the settings content scrolls past it. The active highlight is the part that needs care. Clicking a nav link jumps to a section via its id, and you can style the landing target with :target for a pure-CSS highlight. But :target only updates on click, not as you scroll. For a true scroll-spy that re-highlights while the reader scrolls, add a small IntersectionObserver that toggles an aria-current attribute on the matching link — roughly fifteen lines, no library. Keep the sticky column shorter than the viewport, or position: sticky silently stops sticking because there is no room left to offset into, which is the single most common reason a sticky nav 'doesn't work'.

Each chip is a radio input in one named group, and the visible chip is its <label>. The container reads the checked radio with :has() and hides non-matching rows — something like .table:has(#filter-failed:checked) .row:not(.failed) { display: none; }. Because the radios share a name, only one is active at a time, so the filters are mutually exclusive for free. The common bug: people place the radios after the rows and expect a sibling selector to reach backward — it can't. With :has() the radios can live anywhere inside the scoped container, since :has() evaluates from the ancestor downward. But keep the hidden radios as real, focusable inputs — visually hidden, never display: none — so keyboard users can still tab between chips and screen readers announce the active filter.

Yes — demo 14 drives it with three radio inputs (Light, Dark, System) and :has(). The panel declares light custom properties by default and overrides them with .panel:has(#dark:checked). The trap is the System option: it has to follow the OS, so you wrap the OS-driven values in @media (prefers-color-scheme: dark) scoped to :has(#system:checked). The bug that bites everyone is the one-way toggle — on a visitor whose OS is already dark, the manual Dark rule and the System rule resolve to identical values, so clicking Dark produces no visible change. The fix is a mirror flip-back: inside @media (prefers-color-scheme: dark) you must also restore the light values for :has(#light:checked), and restore every custom property the theme sets, not just the background colour, or half the palette stays stale.

The matrices in demos 08 and 12 are grids of checkboxes where area or event rows meet role or category columns. Build the grid as a real <table> with <th> headers on both the top row and the leading cell of each body row, and give column headers scope="col" and row headers scope="row". Then a checkbox cell is announced as 'Billing, Admin, checked' instead of a bare, contextless checkbox. Every <input> still needs a programmatic name — pair it with a visually hidden <label> or an aria-label that repeats the row and column, because sighted users infer context from position but a screen reader lands on the control with none. Don't rebuild the grid from <div> elements with role attributes; a native table gives you header association and arrow-key cell reading for free, and it survives being pasted into a project that strips your JS.

Yes. Masking the secret is pure CSS — the key renders as dots via -webkit-text-security: disc, revealed by a :has(:checked) toggle — but reading a value and writing it to the clipboard is a privileged action no CSS selector can perform. Demo 09 uses navigator.clipboard.writeText() inside a click handler, which the browser only honours during a genuine user gesture, so wire it to the button's click event, never a timer or page-load hook. Give the button an aria-label like 'Copy API key' because it is icon-only, and after a successful copy flip that label or an aria-live region to 'Copied' so screen-reader users get the same confirmation the visual checkmark gives everyone else. Never pre-select or auto-copy the key on load — it fails silently outside a user gesture and leaks the secret into focus unexpectedly.

Demo 18 separates destructive actions visually, but visual separation is not a safeguard. For irreversible actions — delete account, archive workspace — gate the button behind a typed confirmation: keep it disabled until the user types the exact workspace name into an <input>, which you can enforce roughly with :has() against a pattern or, more reliably, in a few lines of JS. Keep the confirm control a real <button> with type="button" so it never submits a surrounding form by accident. Give the destructive styling meaning beyond colour — an icon plus the literal word 'Delete' — so it still reads for colour-blind users. When not to use an inline danger zone at all: if the action cascades to other members' data, move it into a modal that restates the blast radius, because an inline button is far too easy to hit while scrolling the page.

The ring in demo 03 is a single element with a conic-gradient background — the accent colour sweeps from zero to the used percentage, a track colour fills the remainder, and a smaller circle (a pseudo-element or a radial-gradient mask) punches the centre so it reads as a ring, not a pie. Drive the sweep from one custom property: background: conic-gradient(var(--accent) calc(var(--pct) * 1%), var(--track) 0). To animate it smoothly you must register that property with @property and declare syntax: "<percentage>", because the browser cannot interpolate an unregistered custom property — without it the ring jumps straight to the final value instead of sweeping. Wrap the transition in @media (prefers-reduced-motion: reduce) so users who ask for less motion get the final state with no animation.

The filtering, tab-switching, theme, and card-flip demos are genuinely pure CSS, built on :has(), :checked, and :target — paste them as-is with no script. The ones that touch the outside world need JS: copy-to-clipboard on the API keys page, the live card preview that mirrors typed input in demo 05, paste-and-validate email parsing in the invite flow, and any real scroll-spy on the account nav. A useful rule: if the state lives entirely in the DOM — which chip is active, which row is selected — CSS can hold it; if you must read a value, write to the clipboard, call an API, or react to scroll position, that is JavaScript. And don't push a :has() state machine to do something stateful across reloads — it resets on refresh, so persisting a chosen theme or a saved preference still needs a line of script plus localStorage.