[3.0] Theme

[live627]

This is the new theme started by @TwitchisMental

I still need to convert several form grids to use CSS grids instead of floats. Also the grids abuse definition list markup, something tat has always annoyed me from the very beginning.

Submitting as a draft now to get early feedback.

[jdarwood007]

If we do this for the avatar image, shouldn't we use a alt text for the name?

[DiegoAndresCortes]

Should use href or url then.
Or should 'image' provide it by default? It would be good in case an external avatar is missing in other parts of the forum.

[jdarwood007]

I think either is valid. I believe it just needs something to be valid for screen readers. Since its a link to the users profile and we removed the name, the alt should have it.

[DiegoAndresCortes]

Then I think 'image' should provide the alt text by default. An external avatar could suddenly not load or disappear, would be good to have it.

[live627]

I notice that a few forms would disable textareas on submit, such as the posting form. I've changed this to do all forms by using the new HTML property to make the entire form inert.

[dragomano]

Icons in the admin area are not indented enough:

Unable to load the '' template at Forum Maintenance - Routine:

SCEditor doesn't have a dark theme?

Instead of "X Posts" and "Y Topics", maybe it would still be better to keep "Posts: X" and "Topics: Y" as it is now?

[DiegoAndresCortes]

Icons in the admin area are not indented enough:

I’m working on this

SCEditor doesn't have a dark theme?

Can be fixed later too, but also requires some tweaks.
Check this topic: https://www.simplemachines.org/community/index.php?topic=586626.0

Instead of "X Posts" and "Y Topics", maybe it would still be better to keep "Posts: X" and "Topics: Y" as it is now?

I don’t have a preference, we might discuss it later for sure.

[jdarwood007]

@live627 Can you rebase this or merge and fix conflicts?

[DiegoAndresCortes]

We have this pending
live627#44

Will start sending more in upcoming weeks, but it could be merged, rest of changes are more focused so can be in separated PR's

[live627]

Once I can get around to testing and merging that, I'll rebase this branch again

[dragomano]

checkeiv => checked?

[dragomano]

<label>...</div> => <label>...</label>?

[live627]

@jdarwood007 I moved some of the login javascript to its own file but don't know how to test cors requests.

[jdarwood007]

When this is closer to ready I can check it. You need to run 2 domains (or 2 subdomains) and have the forum on one and the script on another. A simple SSI page where you can open the user area popup is good enough for most things. Sending credentials such as on the login form may also need to be tested, but when you can open the user area, the CORS request works.

[albertlast]

Wave 4, day two — parts 11 to 33, and the thing that is now actually in the way

Picking up from the status a day ago. Wave 4 has gone from ten parts to thirty-three, and half the areas are now closed out rather than merely started.

Theme parts since the last update

Area	Parts
Posting form	#9428 (merged)
Poll editor, login ajax, search board picker	#9429 #9430 #9432
Profile scripts	#9436 #9437 #9438 #9441
calendar.css tokens	#9443
Long tail	#9445
Admin centre	#9447 #9448
Board index / message index	#9451
Editor leftovers	#9457
index.css tokens, nine slices	#9467 #9468 #9469 #9470 #9471 #9472 #9473 #9474 #9475

55 theme PRs in total, 33 merged, 22 open.

The nine index.css slices need a word, because they are not what wave 2 did. I measured the two versions of that file properly before starting: release-3.0 has 954 top-level selectors and this branch has 776, of which only 470 are shared — and of those, only 305 are byte-identical once the tokens are resolved back to literals. This branch's index.css also uses 1192 distinct custom properties, 962 of which variables.css does not define, because it mints roughly one token per property per component (--autosuggest-item-cursor, --border_width). Porting that wholesale would be a single PR adding a thousand tokens, which is the least reviewable thing in this branch.

So the slices take this branch's structure and naming and release-3.0's values: 120 of the 188 remaining literals in index.css become var(--…), and nothing on screen moves. The acceptance test for each is mechanical — parse every rule out of the raw stylesheet text, apply each to a probe element, read a fixed list of 57 longhands, and diff against the same capture taken on release-3.0. That is 965 rules and 55,005 computed values per slice, all nine at zero differences. (Three traps in doing that, in case anyone repeats it: the CSSOM cannot round-trip a border shorthand containing a var(), so reading longhands off CSSRule.style invents confident, entirely fake differences; minimize_files has to be 0, because the minifier rewrites literal transparent to rgba(255,255,255,0) and cannot do so inside a var(); and the page you measure on has to be one that returns 200 on the base branch — see below for why that is a smaller set than you would expect.)

The bug count, again — and why I think it is now the real bottleneck

Since the split started on 1 August: 70 non-theme bug PRs, 17 merged, 53 still open. Yesterday that number was 23. Today alone it went up by about twenty.

I am not raising this as a complaint about review speed. I am raising it because the open queue has started to block the split itself, in a specific and repeatable way:

• A topic display is a 500 on plain release-3.0. That is [3.0] Let SMF\Time do arithmetic with an SMF\TimeInterval #9405, still open. Every page in the largest remaining area is unreachable until it merges.
• Every attachment upload is a database error. That is [3.0] Keep the messages join Attachment::load() selects from #9459, still open — Attachment::load() lost the messages join it selects five columns from.

To sweep the topic display at all today I had to build a scratch branch of release-3.0 + #9405 + #9459 before a single page rendered. The same is true in miniature elsewhere: #9432 blocks the shared board picker, and the profile markup renames cannot land until profile.css and its tokens do.

There is also a self-inflicted lesson in here that is worth stating publicly, because it nearly cost me: I measured six of the CSS slices on ?topic=1.0 without noticing it was the #9405 fatal. The measurements happened to survive — an error page still loads variables.css, and base and branch were captured in the same state — but that was luck, not method, and the same mistake produced one false bug report on #9469 that I have since retracted. Every capture now records the URL and whether the page is a fatal, and the comparer refuses to run on a mismatch.

Areas now closed out

Five of the ten areas from the plan are done, in the sense that everything portable has been taken and everything left has a written reason. (Profile and the admin centre are done apart from one CSS-coupled bundle each; those are in the table further down.)

• Posting — nothing portable in the diff at all; Post.php and Post.template.php are newer here than on the branch. Four PRs, all from running the pages.
• Long tail — Search, Stats, Memberlist, Recent, Help, Errors, ModerationCenter, MoveTopic all triaged out with reasons; two PRs, [3.0] Keep the dead close link out of the help overlay #9444 and [3.0] Theme split (wave 4, part 20) — read out the page links before the buttons beside them #9445.
• Personal messages — same shape: seven PRs, not one theme part. Two are severe and invisible from any page — Received::save() updates pm_recipients WHERE id_pm alone while also setting id_member, so saving any PM with two recipients is a duplicate-key error ([3.0] Save one recipient's copy of a personal message, not everybody's #9460); and Received::loadByPm() keys its result by PM alone, collapsing a PM's recipients to whichever row the database returned last ([3.0] Keep every recipient of a personal message, not just the last one #9461).
• Calendar — one part ([3.0] Theme split (wave 4, part 19) — point calendar.css at the design tokens #9443). Everything else is a revert of newer code, and what remains of calendar.css is a grid restyle entangled with markup this branch no longer has.
• Topic display + postbit — swept today, and it produced five bug PRs and no theme parts: [3.0] Load the SplitTopics template for the page that needs it #9476 [3.0] Save the notification preference the member asked for #9477 [3.0] Give each post one quick-moderation checkbox, and no empty submit #9478 [3.0] Name the icons in the message icon picker #9479 [3.0] Stop logging a warning for every attachment that is not a JPEG #9480. Two whole features turn out to be dead end-to-end on release-3.0, each in three layers:
  • Split Topic — TopicSplit::execute() has its template ternary inverted, so every HTML request loads Xml and the button under a post answers "Unable to load the ask sub-template". Behind that: PageIndex's typed int parameters reject COUNT(*) (a string from the database) and defaultMaxMessages (a string from modSettings); and $split2_first_msg is never initialised, so a resubmitted split reaches getMsgMemberID(null) — precisely the case the sanity check three lines below it was written to catch.
  • Topic and board notification — changePref() hands Db::insert() a single row where it wants a list, and sa=off maps to MODE_NO_ALERT, which setAlertPref() has no case for. The second one means the unsubscribe link at the foot of every notification email is a fatal error. 2.1's -1 is what 3.0 renamed MODE_NO_EMAIL when it split the constant in two, without updating the mapping.

A pattern worth naming, since it accounts for most of today's finds: 3.0's type declarations turn survivable 2.1 bugs into 500s. A string from COUNT(*), a null left by a loop that never ran, a typed property with no default reached through a switch with no default — all of these ran fine untyped. Anything in 3.0 that reaches a typed signature from the database, from $_GET, or from a loop that may not execute is worth a second look, and the guard clause that was meant to catch it is often placed after the call that now throws.

Worth recording against yesterday's estimate table, which put topic display at 4–6 theme parts: it produced none. That is the third area running where the honest answer was "the diff is reverts, here is what running the pages found instead", and I now expect it to be the normal outcome for the remaining template areas rather than the exception. git diff release-3.0 theme-ref --stat reads 145 files today, up from 131, for the reasons given last time — release-3.0 keeps gaining files this branch does not have, several of them because of this split. Per-area is still the only honest way to read progress.

What is still open in this PR

Two areas, plus the CSS-coupled bundles that cut across them:

Left to do	Why it has not been done
Login / Register / Reminder — the data-autov rework	Coupled to register.js. The Login half needs rewriting rather than porting: this branch's Login.template.php calls new smf_Login when the class is SMF_Login, passes sCors and bIsFromAjax unquoted, and drops the error handler; its login.js omits the X-Requested-With header that Login2::checkAjax requires.
Profile — profile.css + --basicinfo-* tokens + the dependent renames	Must land as one PR. profile.css does not exist on release-3.0 and the tokens are not in variables.css, so porting the renames first would delete the styling.
Admin centre — template_admin() tiles + template_show_settings() → .settings-grid	Neither works without the admin.css restyle, and show_settings touches every admin settings page.
Board index — the markup restyle	Still the Font Awesome blocker: .board_icon a::before draws its glyphs from a font whose @font-face rules the shipped fontawesome.min.css does not contain. Its own issue, not a slice of this.
Message index — extracting template_list_topics()	Removes no duplication on its own and has no user-visible effect; it only makes sense travelling with the index.css slice, and would collide with #9454.
index.css remainder	The gradient block near the file tail, the profile and stats rules, and the register/error-file forms.
attachments.css slice	Carries the #au-template fix — a <label for="attached_BBC_width"> over an input with no id, which cannot be given one because dropzone clones the template once per file. The only correct fix wraps the input, which moves the column, which makes it a restyle.
Wave 2 leftovers	dark.css and icons.css content, RTL to logical properties.
Editor / SCEditor remainder	Deferred from wave 1.

Also recorded rather than shipped, so they are not lost: .approvebg2 is emitted nowhere in the codebase (belongs with the index.css slice); QuickModifyTopic — inline subject editing on the message index — is dead three separate ways and needs its ajax round trip verified rather than half-fixed inside a markup PR; and a whole-theme audit of floats inside flex bars is owed after #9390, which a text search cannot do because the float comes from the stylesheet, not a class.

Next session

Login / Register / Reminder, which is the last unstarted area, then the CSS-coupled bundles in the order Profile → Admin → index.css remainder, since each of those is one PR that cannot be subdivided further without breaking the page it belongs to.

The single most useful thing anyone else could do is #9405 and #9459. Both are small, both make an entire area of the forum work again, and both are currently on the critical path for the rest of this split.

Attribution unchanged: this is @live627's work, with @TwitchisMental, @DiegoAndresCortes, @sbulen and @jdarwood007 on the branch. The split is only a delivery mechanism for it.

[albertlast]

Wave 4 complete — per-area template groups

Wave 4 covered the second of the three groupings asked for on this PR: template changes
grouped by area. All ten areas have now been taken to exhaustion, which here means every
remaining hunk in each one is either shipped as a part or written down with the reason it
was refused.

34 parts, #9382 through #9487. Parts 1–11 are merged; 12–34 are open.

The parts, by area

Area	Parts
Calendar	#9382, #9443
Board index and message index	#9385, #9403, #9451, #9475
Admin centre	#9386, #9388, #9404, #9447, #9448
Shared chrome carried in from wave 3	#9390, #9391, #9392, #9393
Posting	#9428, #9429, #9457
Search	#9432
Profile	#9436, #9437, #9438, #9441
Long tail	#9445
Login, registration and reminders	#9430, #9487
index.css token slices	#9467 – #9475

What the wave turned up

Most of what is left in the snapshot is older than release-3.0. The usual reason for
refusing a hunk stopped being "this is hard to separate" and became "this is a revert". Whole
files in the snapshot predate work that has since landed here: the calendar sources predate
both the clock rework and the fatalLang(…, status) signature, several templates undo the
shared confirmation handler and the auto-submit fix, and one moderation template introduces
copy-paste bugs that release-3.0 does not have. Each of those is recorded with its specific
evidence rather than skipped quietly, because "this hunk is a revert, here is the proof" is a
result and not a shortfall.

The raw diff has stopped being a progress measure. git diff release-3.0 <snapshot>
currently reads 145 files, which is more than the 110 this started at — the snapshot is 161
commits behind, so release-3.0's own new work counts as difference. Split directionally it
is 101 files the snapshot itself changed and which still differ, and 44 that differ only
because release-3.0 moved on.

The end condition needs restating too. That diff will never reach zero. Roughly forty
hunks have now been refused with a reason and will sit in it permanently. This PR is finished
when every remaining hunk is either shipped or recorded as rejected — not when the diff is
empty.

Two blockers surfaced, both outside the split. The bundled Font Awesome cannot render:
Themes/default/webfonts/ holds only index.php, and fontawesome.min.css carries no
@font-face, so fontawesome_source = local loads 57 KB of stylesheet backed by no font
files. That is what the board index markup and the personal message popup header are waiting
on, and fixing it is new work rather than a slice of this PR. Separately, dark.css cannot be
ported: the snapshot's copy is pure token repointing, but only 78 of its 197 custom properties
exist in release-3.0's variables.css, and 198 of release-3.0's 276 tokens are not
repointed at all, 87 of them colour-bearing. Taken as-is it would give a dark mode with 87
holes still showing their light values.

The areas whose diff yielded nothing still produced work. Posting and personal messages
had no portable hunk between them — everything was either newer here or a revert — but running
those pages and operating the widgets on them found faults that no diff would have shown.
Those went out as ordinary bug fixes rather than as parts of this split, which is why the part
numbers do not account for the wave's whole output.

Wave 5

What remains of this PR is, by construction, the visual restyle: everything that could land
without a visible change has now been taken. So wave 5 inverts the review criterion. Waves 2
and 4 could be reviewed as "prove nothing moved"; wave 5 has to be "here is what changes, and
why", one area at a time.

Planned for it:

• The CSS-coupled bundles, one PR per area, with the template, its stylesheet slice and
  its tokens together — none of them renders correctly apart. That is profile, the admin
  centre (where template_show_settings() becoming a settings grid touches every admin
  settings page), and login/registration/reminders.
• A working local Font Awesome, which unblocks the board index and the PM popup header.
• Dark mode written against release-3.0's own token set, rather than ported.
• The index.css remainder — the gradient block near the file tail, the profile and stats
  rules, and the register and error-file forms.
• The attachments.css and postbit.css slices, which carry two fixes deliberately left
  out of a markup PR because each needs a layout change to do properly.

One note on sequencing. Wave 5's bundles edit the same files as wave 4's open parts, so
starting it before those land would mean rebasing every one of them. Wave 5 begins once wave 4
has merged, and its scope will be remeasured against release-3.0 at that point rather than
against today's snapshot.

[albertlast]

Wave 5 complete — the visual restyle begins, and dark mode lands

Wave 5 was the first wave whose review criterion is "here is what changes, and why" rather
than "prove nothing moved". It ran to three parts, #9496 – #9498, all open.

Part
1	#9496	The last hard-coded colours in index.css get a token
2	#9497	A dark mode for the default theme
3	#9498	The colour mode reaches the post editor

They are stacked in that order, because each one is what makes the next possible.

One rule the wave established

A change that must prove nothing moved and a change that must show what moved do not belong
in the same pull request. Dark mode started as a single branch; the first screenshot of it
had a white frame around the whole page and headings rendering dark-on-dark, because 55
declarations in index.css still held literal colours that no override could reach. Folding
that fix into the dark-mode branch would have left no usable criterion for either half. So
part 1 is the tokenising, verified as a strict no-op, and part 2 is the mode, verified by
looking at it.

Dark mode was broken in four places, not one

The plumbing has been in 3.0 since Alpha and none of it had ever run. Turning the flag on was
not enough. Each of these was found by using the feature, not by reading it:

• Theme::loadMode() had no callers at all. It is the method that resolves the mode and
  loads dark.css, so data-mode was never emitted and the stylesheet never requested.
• system mode had lost the thing that makes it system. That mode works by loading
  dark.css with a (prefers-color-scheme: dark) media attribute, but attributes are only
  printed for files served on their own, and loadCSSFile() minimizes by default — folded
  into the bundle, the attribute disappeared. The browser was never asked, so system would
  have meant always dark.
• Saving the chosen mode to a member's profile was fatal. Db::insert() wants a list of
  rows and was handed a single flat one, which outside backward-compatibility mode is a
  critical error. The first time a logged-in member picked a mode, the page died.
• dark.css was the placeholder.

loadVariant() carries the identical Db::insert() defect three lines below the one fixed
here. It is deliberately untouched: that branch neither enables nor exercises variants, and
shipping an unverified fix is worse than recording a known one.

The stylesheet is written, not ported

The snapshot's dark.css could not be used, and the gap had widened since wave 4 added its
tokens: of its 197 overrides only 84 name a token that exists here, while 213
colour-bearing tokens here have no value in it. Taken as-is it would have produced a dark mode
with most of the forum still at its light values.

What is there instead overrides 243 tokens, restates no rules, and is written against
twelve values declared at the top of the file — five surfaces, two hairline weights, three
text weights, two link colours. Agreeing those twelve is most of the review. The colour ramps
are deliberately untouched, so a theme still re-tints by moving --primary-color-hue and dark
mode moves with it.

How it was checked

• Light mode is unchanged, three times over: the computed colour, background, background
  image, four border colours, box shadow, outline, text shadow — and for part 3 also filter
  and fill — of every element across twelve pages, before and after. 0 differences, each
  time.
• Eighteen pages swept in both modes for text landing on a background too close to it.
  Dark mode has 19 elements below the AA contrast ratio against light mode's 136; by
  that measure the new mode reads better than the shipped one. Both dark causes sit outside
  the theme: the bundled coloris colour picker, which carries no tokens at all, and the
  Administrator group's online_color, which is data rather than styling.
• No errors logged during any of it.

One methodological trap worth passing on: a computed-style comparison is sensitive to forum
state, not only to CSS. One run reported 4132 differences that were entirely false — an
alert badge count had changed between two captures taken hours apart, shifting every element
index. The tell is a changed element count and misaligned tags. Capture both sides back to
back.

The editor, and where the mode stops

Part 3 found the last light island: the editor's own stylesheet had never been tokenised, so
the toolbar sat in the middle of a dark page in light grey. Twenty-four literals, now none.

One of its tokens is not a colour. Every toolbar icon is cut from a single raster sprite, so
no rule can recolour them, and in dark mode the near-black line art all but vanished. A filter
is the only lever a colour mode has over a raster, so the sprite gets one — none in light,
an inversion paired with a hue rotation in dark. The rotation is required because the sprite
is mixed: the greys have no hue and simply invert, while the icons that carry their own colour
come back near where they started.

The mode stops at the iframe. The surface you type on is a separate document, and
Editor.php hands it one stylesheet with no tokens in scope. Tokenising that file would leave
every var() unresolved and break the light theme too, so feeding the iframe its tokens is
a change to how the editor is given stylesheets and belongs on its own. It is narrower than it
sounds: the rich surface needs a per-member option that is off by default, so what everyone
meets first is the source view — an ordinary textarea on the page, which follows the mode
correctly.

Things that turned out not to be true

Two items this PR has carried for a while do not survive contact:

• Font Awesome is not blocking anything today. There are zero fa- classes anywhere
  in Themes/ or Sources/. It is loaded on every page and used by nothing. The local
  option is still broken — no @font-face, and webfonts/ holds only an index.php — but
  that gates future ports, not anything that renders now. Anyone fixing it should know the
  snapshot's bundled webfonts are 6.3.0 while its stylesheet is 7.1.0, so they cannot
  simply be lifted across.
• "Non-image attachments show the width and height fields" is not reproducible. Tested
  with a text file: the block is present but hidden, because the stylesheet hides it by
  default and only the image branch reveals it.

While testing that, something else surfaced that is worth flagging on its own: every
attachment upload on release-3.0 fails, with Unknown column 'm.id_topic' in 'field list'
from Sources/Attachment.php:537. That is #9459, still open. Any attachments.css or
postbit.css work needs it in place first, or the success path never runs at all.

---

Wave 6 — profile

The profile area is the next wave on its own, because it is bigger than it looks and the
groundwork is a trap rather than a formality.

The obvious first move — lift the profile rules out of index.css into a profile.css — is
not the safe no-op it appears to be:

• That block opens with a global rule, a bare dl { overflow: auto; } sitting under the
  section header. Moving the block changes every page in the forum that has a dl.
• The selectors under that header are not profile-scoped. .list_posts is used by the
  moderation centre, personal messages, posting, recent posts and search; #tracking by the
  topic display, the editor controls, personal messages and Who's Online; #creator by the
  password reminder.

And the snapshot's own profile.css cannot be ported. It is loaded only from
Sources/Actions/Profile/Main.php, yet it claims #paid_subscription, which the admin
paid-subscriptions template emits, and #creator, which the password reminder page emits.
Both pages would lose those rules outright. It does correctly leave .list_posts behind — so
this is a per-selector problem, not a blanket one, which is exactly why it needs per-rule
triage instead of a block move.

So wave 6 re-derives the file from release-3.0, checking every selector against the
templates that actually emit it before moving it, and only then takes the template renames
that depend on it — the post and list-item classes, and the counter — which cannot land before
the stylesheet exists without deleting their own styling.

Wave 7 — what is left after that

Named now so the shape is visible, not scheduled:

• The admin centre settings grid. dl.settings is not the small conversion it looks like
  either: it appears in more than twenty templates rather than only in
  template_show_settings(), it is float-based, and it tolerates mismatched term and
  definition counts in a way a grid does not. Doing it in CSS alone on the existing class
  would avoid renaming it across every one of those templates and avoid breaking mods that
  target it — but it still has to be checked on every admin settings page.
• Login, registration and reminders. The forms move onto a grid class release-3.0 does
  not define at all, so the templates and the stylesheet slice have to land together. The
  snapshot's own login template needs rewriting rather than porting; the specifics were
  catalogued during wave 4.
• The attachments.css and postbit.css slices, once [3.0] Keep the messages join Attachment::load() selects from #9459 makes uploads work again.
• Tokens for the editor's iframe, which is the one place the colour mode still cannot
  reach.

The standing note from wave 4 applies unchanged: what remains of this pull request is the
visual restyle, and the raw diff stopped being a progress measure some time ago. This closes
when every remaining hunk is either shipped or recorded as rejected with its reason — not when
the diff is empty.