Soften the tab label hover colour so it is not the active colour - #303
Open
dchaudhari7177 wants to merge 1 commit into
Open
Soften the tab label hover colour so it is not the active colour#303dchaudhari7177 wants to merge 1 commit into
dchaudhari7177 wants to merge 1 commit into
Conversation
style/design.toml gave --sd-color-tabs-label-hover the identical literal to --sd-color-tabs-label-active, while the hover underline was already softened (--sd-color-tabs-underline-hover, 0.62 alpha). tabs.css:28 applies the hover token to input:not(:checked) + label:hover, so hovering an unselected tab rendered its label in exactly the selected tab's colour and underline saturation became the only cue to which tab was open. On a site theming these tokens with a strong brand colour that reads as two active tabs. The issue suggests reusing the underline's 0.62 ratio on the label. Measured, that does not work: hsla(231,99%,66%,0.62) composites over white to rgb(148,164,254), 2.33:1, which is indistinguishable from --sd-color-tabs-label-inactive at 2.38:1 (1.02:1 between them). It would trade one collision for the opposite one and lose the hover affordance entirely. Alpha also composites against whatever sits behind the label, so it behaves differently on a dark background. Used a solid lighter form of the active hue instead, hsla(231, 99%, 72%, 1), which lands between the two neighbours it has to stay distinct from - contrast against white: label-inactive hsl(0, 0%, 66%) 2.38:1 label-hover hsla(231,99%,72%,1) 3.21:1 (1.35:1 vs inactive, 1.33:1 vs active) label-active hsla(231,99%,66%,1) 4.26:1 Near-equidistant from both, so hover is clearly an affordance and clearly not selected. Regenerated sphinx-design.min.css with tools/generate_css.py; the generated diff is a single character-level change, '66' -> '72' in the tabs-label-hover value. Full suite: 173 passed, 100 skipped. Closes executablebooks#301
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.
Closes #301.
Confirmed at
4f66f32style/design.tomllines 29-30 carried the same literal:and
style/tabs.css:28applies the hover token to the unselected label:So a hovered unselected tab rendered in exactly the selected tab's colour, leaving underline saturation as the only remaining cue — which is the "two active tabs" reading described in the issue.
The suggested 0.62 ratio does not transfer to the label
The issue proposes muting the label with the same ratio the hover underline uses. I measured it before adopting it, and it inverts the problem:
label-inactivehsl(0, 0%, 66%)hsla(231,99%,66%,0.62)→rgb(148,164,254)Those are the same colour to the eye — 1.02:1 between them. It would swap the collision with active for a collision with inactive, and lose the hover affordance completely. Alpha also composites against whatever is behind the label, so it behaves differently on a dark background, whereas the underline can afford that because it sits on a known surface.
What this uses instead
A solid lighter form of the active hue,
hsla(231, 99%, 72%, 1), positioned between the two neighbours it must stay distinct from:--sd-color-tabs-label-inactivehsl(0, 0%, 66%)--sd-color-tabs-label-hoverhsla(231, 99%, 72%, 1)--sd-color-tabs-label-activehsla(231, 99%, 66%, 1)It is near-equidistant from both (1.35:1 against inactive, 1.33:1 against active), so hover is unmistakably an affordance and unmistakably not selected.
Generated CSS
Regenerated with
python tools/generate_css.py. The diff insphinx-design.min.cssis a single character-level change —66→72in thetabs-label-hovervalue — which I verified with adifflib.SequenceMatcheropcode dump rather than eyeballing the minified line.Full suite: 173 passed, 100 skipped. (
tests/test_snippets.pyneedspytest-regressions; without it those cases error on a missingfile_regressionfixture on a clean tree too.)One thing worth your call
design.tomlis a flat name/value list, so this is a static literal. The semantic colours already have a nicer story — the generator emits acolor-mix(in srgb, black 15%, var(--sd-color-<name>))line after the static value so downstream overrides propagate to the hover shade. A theme that overrides--sd-color-tabs-label-activewith its brand colour will not get a matching hover here; it still has to override-label-hovertoo, exactly as today.Deriving it as
color-mix(in srgb, var(--sd-color-tabs-label-active) ~70%, var(--sd-color-tabs-label-inactive))would fix that class of problem for every theme at once, but it needs the generator to emit a second declaration for a non-[[colors]]token, which felt like a bigger change than this bug warrants. Happy to do it in this PR if you'd prefer that shape.