[3.0] Theme split (wave 2, part 8) — Use logical properties for the settings lists - #9357
Merged
Sesquipedalian merged 8 commits intoAug 3, 2026
Conversation
Theme::loadCss() has been asking for variables.css since 3.0 Alpha, at order_pos -2 so it lands ahead of index.css, but the default theme never shipped the file. The request is quietly dropped, so nothing breaks and nothing happens either. This adds it. The first group of tokens covers what index.css sets before it gets to any particular part of the forum: the html and body backgrounds, the body font and colour, the selection colours, form controls in their normal, hover, focus and disabled states, fieldsets and their legends, strong, headings, and the horizontal rule. Every value is the one that rule already had, so this changes no pixels. That is the point: it puts the vocabulary in place, with the names the new theme uses, so the parts that follow can convert their own section of index.css without also arguing about what the value ought to be. Changing what the forum looks like is a separate job from giving its values names. Verified by comparing computed styles across eight pages - board index, board, topic, posting form, search, profile, admin and help - for the eighteen selectors these rules reach and the fourteen properties they set. 1316 comparisons, no differences. Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
Second group of tokens: the .button family, which the quickbuttons and the inline moderation checkbox share the same rules with. Normal, hover, focus and active states, plus the border, radius, shadow, cursor, font size, text transform and the text shadow the active button carries. As with the first group, every value is the one the rule already had, so nothing changes on screen. The two hard-coded values left in these rules are deliberate: .pagesection .button uses the body link colour rather than a button colour, and the SimpleMachines#222 in the shared hover rule only ever reaches the quickbuttons, because the very next rule overrides it for .button. Neither has an honest name in this vocabulary yet. Verified two ways. Each of the nineteen tokens resolves to exactly the literal it replaced, read back from :root in the browser. Then computed styles for eleven button variants - plain, active, quickbutton, inline mod check, first and last in a buttonrow, inside a cat_bar, smalltext, and the three of those that can hold focus - across twenty properties. 220 comparisons, no differences. Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
Third group: the containers every page is built out of. The cat bar and its heading, the title bar, the sub bar, the roundframe, the information box, and the windowbg together with the backgrounds it takes when a topic is locked, sticky, both, or waiting for approval. Same rule as the earlier groups - every value is the one that rule already had, and nothing changes on screen. One thing worth knowing for the parts that follow. Three of these rules set a border on a single side: div.cat_bar and .sub_bar have a border-bottom, and .information has all four minus the top. Rewriting those as the border-color / border-style / border-width triple looks equivalent and is not: it leaves style and colour set on the sides whose width is zero, so a later rule that gives one of those sides a width would paint a border that could not have appeared before. The single-side shorthand is kept. Two values are left hard-coded. The shared rule for h3.titlebg and h3.subbg sets one colour and one font family for both bars, so tokenising it means choosing which of the two names it belongs to; that is a decision for whoever changes the palette. And what the theme calls the even row is this theme's odd one, so #fdfdfd is --window-odd-bg here rather than borrowing a name that would then mean the opposite. Verified the same two ways as the earlier parts. All 48 tokens resolve to the literal they replaced, and computed styles for 22 container variants across 23 properties, including all four border widths and colours and each corner radius separately: 506 comparisons, no differences. The border point above is not theoretical - the first attempt at these rules produced 14 of them, which is how it was found. Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
Fourth group: the boxes SMF talks to people through - error, notice, info and desc - and the two bars, the generic one used for stats and the progress bar with its four colours. Every value is the one the rule already had, so nothing changes on screen. The error, notice and info boxes each carry a border on the top and bottom only, so they keep their two single-side shorthands for the reason the previous part ran into: writing them as border-color, border-style and border-width would leave a style and a colour on the left and right sides, where today there is none. .errorbox sets no colour of its own, so there is no --errorbox-color to add yet; it inherits, and that is worth keeping visible rather than inventing a value for it. Verified as before. All 40 tokens resolve to the literal they replaced, and computed styles for 23 elements - each box, the error box heading, its alert paragraph and its span, both bars, their inner bar, the vertical variant and the four progress colours - across 27 properties, with every border side read separately. 621 comparisons, no differences. Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
Fifth group: what BBC produces inside a post. Blockquote and its cite, the standard and alternate quote backgrounds, the code block, and the underline on a BBC link in both its states. Every value is the one the rule already had, so nothing changes on screen. Two of these rules do carry a border on every side, unlike the ones in the previous parts, so the border-color, border-style and border-width triple is the right shape for them and reproduces what the shorthands were doing: blockquote is 1px 2px in #d6dfe2 #aaa, and .bbc_code is 2px 1px 3px in #bbb #dfdfdf #aaa. The single-side borders on blockquote cite and .bbc_link keep their shorthand. .codeheader and .quoteheader share one rule and one set of values, so tokenising it means choosing whether it belongs to the code vocabulary or the quote one - the same situation as the title bar and sub bar headings in the third part, and left the same way, for whoever changes the palette. Verified as before. All 21 tokens resolve to the literal they replaced, and computed styles for 11 elements across 23 properties, every border side read separately: 253 comparisons, no differences. Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
Sixth group: the things that sit on top of a page rather than inside it. The AJAX notification bar and its link, the popup container, window, heading and content, the search result highlight, and the moderation link. Every value is the one the rule already had, so nothing changes on screen. One value is deliberately not a token. .highlight has background-color: inherit, and a custom property cannot hold that: inherit is a CSS-wide keyword, so --searchhighlight-bg: inherit on :root asks to inherit from an element that has no parent, resolves to the guaranteed-invalid value, and every var() reading it falls back to transparent. Close enough to invisible in most places to pass a screenshot, and wrong wherever the highlight sits inside something coloured. It stays a literal, with a comment saying why. Verified as before, plus one extra check for that case: a .highlight inside a parent painted rgb(1, 2, 3) still computes to rgb(1, 2, 3) rather than transparent. All 24 remaining tokens resolve to the literal they replaced, and computed styles for nine elements across 26 properties: 234 comparisons, no differences. Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
First of the RTL parts. .floatright, .floatleft, .clear_left, .clear_right, .righttext, .lefttext and .bbc_list say inline-start and inline-end rather than left and right, so they follow the writing direction on their own and rtl.css no longer has to flip them. Seven overrides go with them. Left to right is untouched: twelve geometry probes, no differences. Right to left changes in one place, and it is a fix. .righttext and .lefttext set an auto margin as well as a text alignment, and rtl.css only ever flipped the alignment. So in an RTL forum a .righttext block has been hugging the right edge - the start side - while its own text aligned left. Measured in a 400px container, the box sat 300px from the left before and sits at 0 now, which is the end side, where its text already was. The alignment itself does not move: the same probe measuring where the text lands inside the block reports no change in either direction. Verified with lang_rtl set on en_US, before and after, on both branches. Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
dl.settings is the two column label and value layout that most of the admin and profile screens are built from. Its clear, the floats on dt, dt.windowbg and dd, and the gap after an image in a dt are all direction dependent, and all five had an override in rtl.css. Saying inline-start and inline-end instead removes the need for them, and the block of five overrides goes. rtl.css is down to 646 lines from the 686 it started this wave with. Nothing moves in either direction: seven geometry probes covering the list itself, both kinds of dt, both dd, the image inside a dt and a list clearing a float beside it, measured with lang_rtl off and on, no differences. Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
Collaborator
Author
Sesquipedalian
approved these changes
Aug 3, 2026
This was referenced Aug 4, 2026
Closed
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
3 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
Part of the #7933 split, wave 2 part 8 — the second RTL part. Stacked on #9350 through #9356, in that merge order.
dl.settingsis the two-column label-and-value layout most of the admin and profile screens are built from. Itsclear, the floats ondt,dt.windowbganddd, and the gap after an image in adtare all direction-dependent, and every one of them had an override inrtl.css:Saying
inline-startandinline-endremoves the need for all five.rtl.cssis down to 646 lines, from the 686 it started this wave with.The image margin becomes
margin-block: 0; margin-inline: 0 10px, which is the same declaration in both directions rather than two that have to be kept in step.Testing
Fresh install on MySQL, Docker environment, with
lang_rtltoggled onen_US. Geometry rather than computed styles, for the reason given in #9356:getComputedStylereturns logical keywords as authored and cannot tell you where anything actually landed.Seven probes — the list itself, a
dt, adt.windowbg, bothdds, the image inside adt, and a list clearing a float sitting beside it — each recording distance from both edges of a fixed 400px parent, vertical offset, width and height.Nothing moves in either direction. Unlike #9356, this part has no behaviour change to report — the overrides it removes were complete, so the logical version reproduces them exactly.
Error log clean. The unit suite does not reach CSS, so there is no test to add here.
Issues References (Fixes|Related|Closes)
Related to #7933, #9350, #9351, #9352, #9353, #9354, #9355, #9356