I don't think you can get this to work in the general case anyway; afaik there's no rule that says "weight 800 has the same thickness as 400 at twice the size"... Nor does 50% of the parent's font weight necessarily mean half its stroke thickness. The numbers are just an arbitrary per-font scale.

(Also for small-caps, there's no rule for what size the synthesized small caps should be wrt full caps, so that's not even possible cross-platform.)

Why doesn’t font-weight: bolder or font-weight: lighter work? https://drafts.csswg.org/css-fonts-4/#font-weight-prop

@litherum I think @LeaVerou (and myself) wants a way to automatically match "stroke" width for a font-weight computed value when scaling up and down font-size. Based off the a cascade/parents font-size?

Would an implementation of this have to do path analysis or render the same character multiple times in order to determine what font parameters to use?

I don't think you can get this to work in the general case anyway; afaik there's no rule that says "weight 800 has the same thickness as 400 at twice the size"... Nor does 50% of the parent's font weight necessarily mean half its stroke thickness. The numbers are just an arbitrary per-font scale.

(Also for small-caps, there's no rule for what size the synthesized small caps should be wrt full caps, so that's not even possible cross-platform.)

Obviously this would need to be tweaked on a per-font basis, but at least once you figure out the scale for a given font, that's it, whereas right now you have to tweak it individually for each font size and weight!!

Would an implementation of this have to do path analysis or render the same character multiple times in order to determine what font parameters to use?

Why would it do that? The relative weight would be specified by the author, not the browser. It's exactly the same as relative font-sizes. The author figures out the relationship, the browser just applies the number.

Would an implementation of this have to do path analysis or render the same character multiple times in order to determine what font parameters to use?

No, not at all. It is just doing calc(0.9 * inherited-value)

Why doesn’t font-weight: bolder or font-weight: lighter work?

Those two are for the case of "I don't care what actual weight you use, just make it noticeably bolder". While this issue is the opposite "I really care what weight you use and want it to be this much times the weight of the parent element".

Better synthesized small caps without the small caps having lighter strokes than the full height caps.
Better synthesized superscripts/subscripts.

I think that optical sizing in variable fonts can also help with better synthesized super/sub, and maybe with smallcaps also.

🤔 If the main use case for this is to either select a certain explicit stroke thickness or to match up two implicit lengths, maybe itʼs better to be able to specify the stroke thickness as a <length>, although I donʼt see how this could be put in a different or child property.
Kind of relevant then: I once proposed a relative length unit (or two) that would hold the (parent) stroke thickness, with the main use case being text-underline-width. #838

Intuitively, I would assume font-weight: 100% meant that the strokes are so thick that all glyph counters are completely filled. Higher values would make no sense.

I just stumbled upon this again (well, the lack thereof) and I actually think I buried the lede here with the equalizing strokes use case. A far more common use case is when we want a bolder or lighter stroke than the surrounding text, in a way that's agnostic to the weight of the surrounding text.
There is bolder and lighter indeed, but these are defined in very crude terms, since they precede variable fonts: https://drafts.csswg.org/css-fonts/#relative-weights
In fact, I think percentages should be allowed in all font properties that correspond to registered axes, for the same reason.

percentages should be allowed in all font properties that correspond to registered axes

Presumably not font-optical-sizing: auto nor font-style: italic, as those values are boolean, and don't use a sliding scale. But I understand the desire to treat font-stretch the same as font-weight and font-style: oblique in this issue.

@jonjohnjohnson

I think @LeaVerou (and myself) wants a way to automatically match "stroke" width for a font-weight computed value when scaling up and down font-size. Based off the a cascade/parents font-size?

I'm assuming you don't need to be able to do this across different families (hence my question about the browser having to measure the apparent width of characters in order to find a matching weight in a different family).

Is the idea is to be able to say something like

--multiplier: 0.7;
font-size: calc(100% * var(--multipler));
font-weight: calc(100% / var(--multipler));

... to make the weight scale up in proportion to the font's scale down, so the apparent weight stays the same?

On the face of it, this sounds like a very natural addition to font-weight, because this design is already present for font-size.

I wonder if this proposal actually would actually allow for images like the one posted above. In this example, I would expect the three lines to be sibling elements rather than descendants of each other.

I guess there's one other comment: I would expect the resolution of this percentage value to be done before the font matching algorithm is run. So, if the parent element has font-weight: 1000 and the child element has font-weight: 75% then that is exactly identical to if the child element had font-weight: 750 specified.

I would also expect it to inherit the same way that font-size percentages inherit, not the way that line-height percentages inherit.

One problem: font-stretch already accepts a percentage.

For some of these, it seems like a desired behavior might be to add or subtract a specific adjustment rather than multiplying by a percentage. For that, perhaps syntax like:

  font-weight: lighter(100);
  font-weight: bolder(300);
  font-stretch: more-condensed(25%); /* better name wanted! */
  font-stretch: more-expanded(12.5%); /* same! */

might be desirable?

@dbaron If 100% corresponds to the inherited font-weight (stretch, etc), calc() can take care of other adjustments without new special syntax.