[3.0] Theme split (wave 6, part 2) — reach the last colours the colour mode could not - #9548
Open
albertlast wants to merge 2 commits into
Open
Conversation
index.css carried a "profile section" of about three hundred lines that every
page in the forum downloaded. This moves the part of it that only the profile
draws into a profile.css, loaded from SMF\Actions\Profile\Main beside the
profile.js it already loads there.
Only part of it moved, and which part is the whole question. That section is not
profile-scoped despite its heading: the post list it holds is the same one the
moderation centre, personal messages, recent posts and search all render, the
board picker is shared with search, and the paid subscription, theme picker and
theme settings blocks belong to the admin centre. It also opens with a bare
`dl { overflow: auto; }`, which is a global rule that happens to sit under the
heading. Moving the section wholesale would have unstyled all of those.
So every selector was resolved against the templates that actually emit it,
matching class and id attributes rather than bare words, and a rule moved only
when the leftmost element of every one of its branches is something no template
but the profile emits. Thirty-five rules moved on that test and thirty stayed.
Two rules went out entirely rather than moving: .sizefix and .topic .mod_icons
name classes that nothing in Themes/ or Sources/ emits at all.
Verified against a running forum: the computed colours, box metrics, display,
float, margins, padding, font size and alignment of every element on
twenty-two pages - all eleven profile areas, plus the five that share those
selectors, the two admin pages that own the blocks left behind, the reminder,
the memberlist, the stats and the board index - before and after. 7260
elements, no differences.
Signed-off-by: Mathias Alberts <mathiaspapealbert@hotmail.com>
Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
Two kinds of value were still out of the dark mode's reach, and neither was visible to the sweep that tokenised the rest of the theme. The first is a border written as a shorthand. That sweep matched `border` and `border-*-color`, so a `border-bottom: 1px solid #bbb` went straight past it. Seventeen of those were left, across index.css, attachments.css, responsive.css, profile.css and the two right-to-left sheets: the hairline under the header, the one above a post list, the dotted rule between attachment previews, the drop zone's hover outline, the mobile notification list, and the week grid separators. Each is now a token holding the literal it replaced. The second is subtler. atwho.css writes every one of its nineteen custom properties with a fallback - `var(--mentions-bg, #fff)` - so the mentions list has never looked wrong and nothing flagged it. But a token that is never declared cannot be overridden either, which is exactly what kept that list white in dark mode. Declaring them, each from the fallback it is written with, is the whole fix; atwho.css itself is untouched, so it keeps working if a theme drops variables.css. The one literal deliberately left is the diagonal stripe over a progress bar's fill, which is a translucent white texture rather than a colour. Light mode is unchanged: computed colours, border widths and styles, shadows, sizes, weights and radii for every element over fourteen pages, before and after - 4473 elements, no differences. In dark mode the same properties now resolve against the scale rather than staying at their light values. Signed-off-by: Mathias Alberts <mathiaspapealbert@hotmail.com> Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
Closed
Member
|
Will review this after part 1 merges and we rebase this to show the actual changes. |
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
2 participants
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.
Description
Two kinds of value were still out of the dark mode's reach, and neither was visible to the sweep that tokenised the rest of the theme.
A border written as a shorthand
That sweep matched
borderandborder-*-color, so aborder-bottom: 1px solid #bbbwent straight past it. Seventeen were left, acrossindex.css,attachments.css,responsive.css,profile.cssand the two right-to-left sheets:#inner_wrap.list_posts#post_draft_options.errorfile_table td.current#postAttachment#attachment_upload.dz-drag-hover#mobile_action .notify_dropdown a.up_contain .lastpost.buttonrow,table.weeklistEach is now a token holding the literal it replaced.
A token that was never declared
This one is subtler.
atwho.csswrites every one of its nineteen custom properties with a fallback —var(--mentions-bg, #fff)— so the mentions list has never looked wrong and nothing flagged it. But a token that is never declared cannot be overridden either, which is exactly what kept that list white in dark mode.Declaring them, each from the fallback it is written with, is the whole fix.
atwho.cssitself is untouched, so it still works if a theme dropsvariables.css— the fallbacks stay as the safety net they were written to be.The one literal deliberately left anywhere is the diagonal stripe over a progress bar's fill, which is a translucent white texture rather than a colour. Excluding
variables.cssanddark.css, which are where literals belong, and the standalone installer/maintenance/report pages and the editor iframe sheet, which no colour mode reaches, the theme's stylesheets now hold exactly one literal colour between them.Verification
Computed colours, border widths and styles, shadows, sizes, weights and radii for every element over fourteen pages, before and after:
And the same properties now actually move in dark mode rather than staying light:
#inner_wrapbottom borderrgb(187, 187, 187)rgb(58, 67, 74)#detailedinfo dlbottom borderrgb(204, 204, 204)rgb(58, 67, 74)--mentions-bg#fffhsl(207, 14%, 19%)--mentions-item-colorhsl(0, 0%, 20%)hsl(207, 10%, 84%)Stacked on #9547 (wave 6, part 1), because
profile.cssis one of the files it corrects.Part 2 of wave 6 of the #7933 split.
Issues References (Fixes|Related|Closes)
Related #7933