[3.0] Theme split (wave 2, part 5) — Move the quote and code block values into variables.css - #9354
Merged
Sesquipedalian merged 5 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>
This was referenced Aug 3, 2026
Merged
Closed
Collaborator
Author
Sesquipedalian
approved these changes
Aug 3, 2026
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 5. Stacked on #9350, #9351, #9352 and #9353, in that merge order.
What BBC produces inside a post:
blockquote--quote-border-*,--quote-font-sizeblockquote cite--quote-cite-border-*,--quote-cite-font-size.bbc_standard_quote,.bbc_alternate_quote--quote-bg,--quote-alternate-bg.bbc_code--code-bg,--code-border-*,--code-font-size,--code-height.bbc_link,.bbc_link:hover--bbc-link-border-*Every value is the one the rule already had. Nothing changes on screen.
On the borders again
Unlike the rules in #9352 and #9353,
blockquoteand.bbc_codedo carry a border on every side — they just use different widths and colours per side:So here the triple is the right shape and reproduces the shorthands exactly.
.bbc_codelikewise becomes2px 1px 3pxin#bbb #dfdfdf #aaa— which happens to be the same shape #7933's--code-border-widthuses. The genuinely single-sided borders, onblockquote citeand.bbc_link, keep their shorthand.One value left hard-coded
.codeheaderand.quoteheadershare one rule and one set of values. Tokenising it means deciding whether it belongs to the code vocabulary or the quote one — #7933 has both, with identical values. Same situation as the title bar and sub bar headings in #9352, and left the same way, for whoever changes the palette.Testing
Fresh install on MySQL, Docker environment. The same two passes:
:root. No mismatches..bbc_tt— across 23 properties, every border side read separately. 253 comparisons, no differences.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