[css-fonts] Allow percentages in font-weight

[Crissov]

CSS Fonts 4 should update the font-weight (<wght>), font-stretch (<wdth>), font-style (<ital>, <slnt>) and font-size (<opsz>) properties, maybe also font-family (STAT), to support arbitrary values in Opentype Variable Fonts (Medium article by @tiroj) (fvar/gvar and CFF2 tables). There may also be a use case to access arbitrary (possibly named) axes, e.g. with a new property font-axis or font-variable.

I have no concrete proposal, but note that …

Members of the Edge team are working with industry partners on a formal proposal for support of variable fonts in Cascading Style Sheets (CSS) for the Web.

[litherum]

You can watch progress here.

This is on the agenda for discussion at TPAC.

[Crissov]

Okay then. I’d prefer percentages over numbers though.

[litherum]

What would the percentage represent? The fraction of the specified value within the range available from the font? If so, fallback glyphs would get broken values since the range in the fallback font wouldn't match the range in the primary font. Maybe I misunderstand you?

[Crissov]

In css-color, <alpha> used to be a number between 0.0 and 1.0 only. That’s basically a percentage 0%…100% and, accordingly, percentages are now possible for all kinds of transparency/opacity (partial) values. The 9-step pseudo-numeric font-weight values 100…900 are another case of percentages in disguise (10%…90%), even though 0 and 1000 or any integer steps between the n-hundreds are not defined yet. This is the right time to change that. I wouldn’t even introduce the unit-less legacy numbers to font-stretch etc.

[litherum]

Now that variation fonts exist, it's totally reasonable for a font to support a weight of 1200. Percentages where 0% is meaningless and 100% is meaningless are not valuable.

The webfonts community has already standardized on the current font weight scale. Keeping the scale is much more valuable than migrating to percentages.

[tabatkins]

Agree with @litherum. As far as I can understand the variable-fonts spec, the numbers have arbitrary meaning, and so we can't assign any automatic 0%/100% points to the ranges. I suspect we can/should allow the page author to do this kind of assignation, so they can assign meaning to percentages and then use them consistently in a page, tho.

[litherum]

The numbers are expected to be semantically consistent from font to font (meaning: weight 265 in one font should "match" weight 265 in another font, for some definition of "match"). Therefore, the numbers have meaning in their own right. But you are right: there is no concept of a widely-accepted maximum or 100% for an an axis which is standard between fonts.

Also, the range extents that a given font supports are arbitrary.

CSS is not currently in the business of letting web authors make up their own grammar for existing properties. I believe this is one of the pursuits of the Houdini WG, but that work isn't ready for primetime yet.

[tabatkins]

Uh, setting where the % points are isn't exactly "making up their own grammar". It's perfectly in CSS's wheelhouse if we decide to do it. It's nothing to do with Houdini, as you don't need to invoke arbitrary extensibility to do this.

[svgeesus]

Weights should be a number between 1 and 999. This is the intent of the OT 1.8 spec (and was also the original intent of the weight in the OS/2 table, which later got downgraded to a 100, 200 etc enumeration). That should be a float, not an integer (I'm at ATypI, and asked a clarifying question when OT 1.8 was announced there).

[litherum]

My previous comment about maxima is incorrect.

The OpenType spec lists that weight "Values must be in the range 1 to 1000." I think this is a problem in the OpenType spec since super-duper-heavy fonts should be allowed (but this is not the right forum to discuss that).

However, regarding percentages, my comment about the typographic community still stands. In addition, since a weight of 1000 has no semantic meaning other than "the largest value the OpenType spec supports," it seems reasonable that this threshold may be increased or even eliminated in the future. Similarly, one of the most important tenants of the Web is that it is not beholden to any single vendor, so adopting this maximum directly from OpenType would be unfortunate and because the TrueType spec does not list such a maximum.

Would you mind if I retitled this issue to mark it as regarding percentages in font-weight, font-stretch, and font-style?

[Crissov]

A weight of 100% or 1000 – at least to me – unambiguously means that all counters are gone because the strokes have gotten so thick as to fill them. Likewise, a 0% or 0 font would be almost invisible with the stroke width at the minimum supported, i.e. showing just the skeleton of the glyphs.

[litherum]

Given that the counters of different glyphs are of different sizes (for example, "s" and "u"), this is still not well-defined.

[litherum]

On a related note, presumably this discussion is only about font-weight because "wdth" does not list a maximum and "slnt" values should be between -90 and 90 (and I'm assuming nobody wants negative percentages nor "0%" to mean "all the way horizontally").

[Crissov]

Shouldn’t <slnt> use <angle> then, so authors could use the angular unit of their choice? Restricting, normalizing or clipping of values outside the allowed range would still be possible.

PS: I was using “counter” in the narrow sense where it only applies to commonly enclosed areas, as usually in a, b, d, e, g, o, p, q, A, B, D, O, P, Q, R. They should all disappear for maximum possible font weight.

[litherum]

Yes, slnt should use <angle>.

I still disagree, and have a counterargument, but let's not continue down this path.

For the proposal of using percentages in font-weight, it sounds like there is a fair amount of dissent. It looks that this proposal should not include percentages, but we can revisit this issue later.

For the proposal of having font-weight have a maximum value of 999, I'll merge this into the proposal. I'm pursuing getting this changed in the OpenType spec, so we can revisit this issue if I'm successful there.

[Crissov]

I’m not sure why this was closed already. #498 is now a (more active) duplicate of this issue.

[svgeesus]

I think it was because of

Would you mind if I retitled this issue to mark it as regarding percentages in font-weight, font-stretch, and font-style?

and that particular issue was resolved.

[litherum]

I thought I renamed it, but maybe I didn't. I'll rename it now.

@svgeesus is correct.