This is something we’ve wanted to do, and have gradually worked towards in bits and pieces, but it isn’t something that can happen all at once. Every change we make causes potential theme regressions across thousands of sites (and we have to fix a lot of these for our customers), so it takes a long time to make small changes.
We have also been undergoing Ember modernization work for a while now, which also requires fixing regressions and refactoring existing themes. This is still underway and will also take time to get everything updated (replacing our widget system, for example, could easily take 6 more months). There are a lot of priorities to balance.
There’s no envisioned direction outside of more consistency. We’ve considered decoupling our base styles so the default “unthemed” Discourse has a lot less CSS (which might make it easier to maintain themes)… but that’s just an idea at the moment.
I think these were added “as needed,” so we haven’t had a need for additional secondary/quaternary scales. We don’t have any plan to remove the named versions, so either can be used for the foreseeable future.
The smallest/smaller/larger/largest sizes are for the text size user setting. Most of the time these won’t need to be changed.
The em scale is roughly based on a classic typographic scale (The typographic scale, for example). A more evenly spaced scale like 13-15-17-19 doesn’t create a lot of contrast and everything stays kind of small unless you have many steps. On a classic scale the gaps between the scale increase along with the size to create more contrast.
The idea behind the em-based scale is that everything in the app can scale proportionately, and individual sections of the app can be scaled proportionately. So I could do something like
.sidebar-wrapper {
font-size: 20px;
}
and everything within would scale up proportionately without having to alter every individual font-size and all the related spacing.
Internally the feedback is similar to your own, in that developers want to know exactly what font size they’re getting regardless of context, which is a downside of the system. Ideally we wouldn’t be worrying about exact sizes and could just say “this should go up a step because I want it to be larger” but that mental model does not seem to come naturally.
There’s some desire to move to a rem-based system instead, but as mentioned earlier… this would likely take a long time to change because it would affect so many existing sites. I’d also prefer the browser-default base of 16px rather than our 15px, but similar story (it used to be 14px! so we’ve made one step at least).
The rem scale is used for headings in cooked post content, because nesting heading tags using ems meant individuals could infinitely scale up text and cause layout problems.
Yeah, it’s come up a couple times… (I’m sounding like a broken record but…) it would have to be a very gradual change to avoid regressions in existing sites. At the moment we’ve been adding shared variables within specific areas as we update them, which is a step in the right direction.
The speed at which this stuff happens is understandably a little frustrating, but for most of Discourse’s history there was no full-time designer on staff at all. The design team has grown to 7 over the past couple of years (including dedicated designers to work on customer projects, which mostly happen out of public view) so hopefully we’ll be moving towards more consistency faster now.