[css-fonts] font-weight: bolder and lighter are counter-intuitive

[Wes1262]

I'm not sure if it will be possible with future calc() improvements, but it would be great if it was possible to write:

strong {
    font-weight: calc(inherit + 100); /*
    font-weight: calc(inherit + 200);
    font-weight: calc(inherit + 300);
    font-weight: calc(inherit + 400);
    font-weight: calc(inherit + 500);
    font-weight: calc(inherit + 600);
    font-weight: calc(inherit + 700);
    font-weight: calc(inherit + 800); */    
}

As opposed to bolder and lighter that are really hard to use and that never do what the designer wants.

Thanks in advance.

[upsuper]

Allowing inherit in calc is probably a major CSS syntax change which may relate to CSS Syntax and probably CSS Cascading.

[tabatkins]

There's nothing wrong with it Syntax-wise (global keywords aren't handled at that level). Handling global keywords in the middle of other properties isn't problematic either - you can already do that in font-family. (font-family: foo inherit; is fine, it refers to a font named "foo inherit".)

It's just putting keywords into calc() that's problematic right now. But grabbing the inherited value of a property via a function or something shouldn't be problematic.

[Wes1262]

Actually, maybe it's better to have a special value like "bolder" and "lighter" that instead selects the immediately larger or lighter weights available for the current font.

In other words, font-weight: calc(inherit + 100) will have no effect if inherit is 300 and there is no 400 font-weight for the current font.

[upsuper]

But grabbing the inherited value of a property via a function or something shouldn't be problematic.

I moderately disagree with this. It may not be a problem for font-weight especially given that it doesn't seem likely that we are going to extend it to a multi-value property. But it could happen that a property which currently only accepts a single numeric value can be extended to support non-numeric (computed) value, multiple values, or even be converted into shorthand. In those cases, we may have trouble to continue supporting this mechanism in those properties.

(Actually it's not even clear to me whether font-weight is going to be stuck in its current form. For example, could there be some new kind of font variation axis which supports adjusting vertical and horizontal direction weight differently, and its request becomes common so that we want to have font-weight support it directly?)

[WebMechanic]

came here via #2764 (reference)
so.. bump!

The above problem could be fixed if the bolder and lighter keywords would actually do what their name suggests; at least for variable fonts. No need for keyword handling in calc() then.

Maybe some variation of current() or inherited() could do the trick if nesting functions in calc() is supposedly easier. But that's a different story to than using an unknown variable set of bolder/lighter fonts.

Variable Fonts are a thing now!

Unfortunately neither "bolder" nor "lighter" move to the next weight variation within a variable font, but act binary as "bold" or "un-bold" aka "normal". That was fine when most ordinary fonts typically featured a binary state for normal/bold as well.

Also going bolder or lighter (font wise) within nested elements does not imply moving in steps of 100 only. A variable font could contain just three presets for its the "wght" axis using 200, 400, 600 or any other set of arbitrary numbers between 1 and 1000.
The same is true for an equivalent set of carefully crafted @font-face declarations using classic single font files.

With a fallback list of different variable fonts such as font-family: "Bahnschrift", "League Spartan Variable", "Source Sans Pro" one could build a working ramp of the proper font-weights of such fonts whilst being ignorant about what "wght" values actually exist.

Using "bolder" or "lighter" could (should) continiously select the next available weight variation.

Here each letter of the words "Fonts" and "Mood" is a set of nested <b> elements that might progressively get bolder from whatever weight <p> currently has set and eventually reaches whatever weight ("wght") the font's upper limit would be.

b {font-weight:bolder} /* life could be easy ... */

<!-- crudo ma bello -->
<p>Variable <b>F<b>o<b>n<b>t<b>s</b></b></b></b></b> R <strong>côôl</strong></p>
<p>G<b>o<b>o<b>o<b>o<b>o<b>d</b> Morning</b></b></b></b></b></p>

Although the markup is ugly, the CSS remains fairly simple and intuitive.

Today I can do the same thing but with much more effort and have to use an explicit amount of nested B selectors - unlike the oneliner above. I also need to keep the ramp values at a specific start/end point or the result could look choppy when used in a possibly different context.
If <p> happens to be set elsewhere to the usual normal (400), the effect would not look as intended.

/* ... but it's not ... */
p {font: 200 2rem/1 "League Spartan","Bahnschrift","Source Sans Pro",sans-serif;}
p > b { font-weight: 300 }
p > b > b { font-weight: 400 }
p > b > b > b { font-weight: 500 }
p > b > b > b > b { font-weight: 600 }
p > b > b > b > b > b { font-weight: 700 }
p > b > b > b > b > b > b, strong { font-weight: 800 }

Using CSS properties the CSS can become simpler ...

p {--w:1 }
p b { font-weight: calc(var(--w) * 200) }

but the HTML gets even worse:

<p>G<b style="--w:1">o<b style="--w:2">o<b style="--w:3">o<b style="--w:4">o<b style="--w:5">d</b> Morning!</b></b></b></b></p>

Cheers.

[svgeesus]

Unfortunately neither "bolder" nor "lighter" move to the next weight variation within a variable font, but act binary as "bold" or "un-bold" aka "normal". That was fine when most ordinary fonts typically featured a binary state for normal/bold as well.

And tat is the crux of the issue. bolder and lighter date from a time when:

• CSS was vastly simpler and less used than now
• there were no WebFonts
• there were no variable fonts
• CSS was seen as a set of "hints" to affect presentation, not a completer visual design system

Looking at the definition (bolder means _bolder, if available, or the same weight, but at least not lighter _) which is as close to meaningless as can be while still being somewhat testable, I would class the bolder and lighter keywords as legacy compat features only.

Achieving the desired effect using calc, though, seems like a much better approach.