[3.0] Theme split (wave 2, part 9) — Add the dark.css and icons.css placeholders the theme already loads

[albertlast]

Description

Part of the #7933 split, wave 2 part 9 — the last of wave 2. Not stacked on anything; wave 2 parts 1-8 (#9350 through #9357) are already merged.

This is the two placeholder stylesheets @Sesquipedalian asked for in #7933 (comment), so the content can be filled in by later pull requests without those pull requests also having to introduce the file and wire it up.

Both files have been named in Theme.php for as long as variables.css was, and have never existed. loadCSSFile() drops a stylesheet that is not there without complaining, so both calls have been silent no-ops since 3.0 Alpha.

icons.css is loaded unconditionally, at order_pos -200:

self::loadCSSFile('icons.css', ['minimize' => true, 'order_pos' => -200], 'smf_icons');

So this file starts being fetched as of this pull request. It contains only a header comment, which the minifier strips, so it contributes nothing to the bundle. -200 puts it ahead of variables.css at -2 and index.css at 1, which is the right way round — icon rules should be overridable by both.

dark.css is loaded only inside the if (!empty($this->settings['has_dark_mode'])) branch, and index.template.php still sets has_dark_mode = false. So this one is not fetched at all yet, and nothing changes until the file has content worth switching to.

I have deliberately not flipped has_dark_mode here. Flipping it would put a colour mode selector in every user's profile and in the admin panel, and every option would do the same nothing, because the stylesheet behind it is empty. That flag belongs in the pull request that fills the file in.

Two things from the discussion, recorded so they are not lost

I was wrong about :root[data-mode="system"]. I had said the branch's selector makes "system" mean "always dark". @Sesquipedalian corrected this and @live627 confirmed the correction: when the colour mode is system, Theme.php attaches a (prefers-color-scheme: dark) media attribute to the stylesheet itself, so the media query decides whether the rules apply at all and the attribute selector is never reached with the query false. Nothing needs fixing. The reasoning is written into the header of dark.css so whoever fills it in does not have to re-derive it.

Variants need no change. @live627: theme variants must behave as they do in 2.1, which means the bundled theme ships none, and dark mode is a separate toggle. index.template.php already sets theme_variants = [], so that is already the required behaviour and there is nothing to port. I have dropped that item from the wave.

Testing

Fresh install on MySQL in the Docker environment.

The point of this pull request is that it changes nothing that is served, so the test is on the delivered bytes rather than on computed styles. Both minified bundles were regenerated from a cleared cache on this branch and on plain release-3.0, and compared:

	baseline	this branch
main bundle	99282 b	99282 b
second bundle	109 b	109 b
sha256 (main)	052e75b2…9f1aff6	052e75b2…9f1aff6

Byte-identical, both bundles. The bundle filename hash does change, from d913bca9… to 42cf6c38…, because it is derived from the list of source files and icons.css has joined that list. The contents behind it are the same, so the only visible effect is one cache-busting filename change on upgrade.

Ten pages loaded on both branches — board index, a board, a topic, posting, search, stats, memberlist, help, admin and profile. Identical status on every one, including a pre-existing 403 on ?action=post as a guest, which is a posting permission and is the same on release-3.0.

Error log clean. The unit suite does not reach CSS, so there is no test to add.

Still open, not in this pull request

The 38 undefined custom properties. @Sesquipedalian set out what to do if @live627 does not get to it first, and that window has not closed yet, so I have not acted on it. One note for when it is done: the example uses // to comment out the token line, and // is not a comment in CSS — it makes the declaration a parse error, which happens to hide it but is invalid and will not survive a linter. It needs to be /* */.

Those 38 are also all on the #7933 branch rather than here — nothing in release-3.0 currently references an undefined token — so the fix belongs either on that branch or in the waves that bring those areas across. I will apply @Sesquipedalian's pattern as each area comes through rather than porting a var() that resolves to nothing.

Issues References (Fixes|Related|Closes)

Related to #7933