[css-fonts-4] font-stretch is unfortunately named

[litherum]

Most designers' intuition seems to be that this property affects (the typographical sin of) geometrical scaling. We should make an alias which has a better name.

[litherum]

One possibility: font-width. This is in accordance with the TrueType and OpenType spec.

[svgeesus]

I agree that this name has, in practice, caused confusion. In a world where fake bold and fake italic (obliquing) are common, people often assume that font-stretch geometrically stretches or shrinks the glyph outlines. Also, to date there were not so many WebFonts deployed with condensed or expanded versions, so this property and associated descriptor were not much used.

I agree that now is the right time to deploy an alias, before variable fonts make condensed and expanded forms far more common. font-width seems much better. In general, aligning closely with OpenType is better.

Also, mea culpa. I came up with the name font-stretch, didn't much like it, asked for better names and none were suggested so we stuck with it.

[liamquin]

On Thu, 2016-09-29 at 12:09 -0700, Chris Lilley wrote:

I agree that this name has, in practice, caused confusion. In a world
where fake bold and fake italic (obliquing) are common, people often
assume that font-stretch geometrically stretches or shrinks the glyph
outlines.

Which in at least on implementation I use, it does. And it's a useful
feature at times - e.g. if you use it with the stroked (not filled)
version of Courier, the result can be very acceptable.

Maybe access to the font transformation matrix should be added at the
same time this is clarified? Or maybe it's not worth-while, given that
you can open the font in a font editor and adjust it.

Liam

Liam R. E. Quin liam@w3.org
The World Wide Web Consortium (W3C)

[LeaVerou]

Totally agree, font-width would be a much better name.
Given that it's only used on 3% of websites, perhaps we could deprecate it without serious backwards compat issues?

[jpamental]

If we wanted to make font-width the 'real' name but can also create an alias, couldn't we rename the property to font-width and add an alias for font-stretch and eventually deprecate that?

[Crissov]

font-width sounds as if you could switch between fixed/monospaced and variable/proportional/dynamic with it. It’s also easily associated with half-width sinograms etc. as in font-variant-east-asian: <east-asian-width-values> (OTF fwid and pwid, not hwid, twid or qwid) and text-transform: full-width.

[jpamental]

@Crissov I think the challenge is being mindful of terminology from type design and typography while still being accurate. In this case, font-width is the term that resonates most and aligns more closely with existing terminology from the design world, whereas font-stretch sounds more like something you're generally not supposed to do with type (stretch it artificially).

I'm not sure that this is a clear-cut recommendation one way or the other, but in balance I've heard from a whole bunch of type designers/typographers that they feel font-width is preferable, so I definitely lean much more in that direction. (Not that it's up to me, but I'm doing my best to ensure the design community is 'in the conversation', so to speak)

[Crissov]

There are lots of unfortunate naming choices in CSS (e.g. border-radius instead of corner-radius or hyphen-less currentcolor). As far as I know, none of them have been improved (or deprecated) unless the new alternative also added new features (e.g. comma-less rgb() with “alpha” opacity). Would font-width do more than font-stretch does already?

Similar changes I could imagine:

• font-height as an extended superset of font-size, font-size-adjust and line-height, also dealing with optical sizes and sizing by cap-height vs. x-height vs. dp-height vs. Å-height vs. CJK-height etc.
• font-slope or font-slant to deal with oblique (vs. upright) and arbitrary/variable angles, whereas font-style became a shorthand for this and other sub-properties for italic vs. roman (vs. swash vs. cursive/continuous/connected) or serifs, in a way that encompassed at least Arabic and East-Asian hands as well.

[litherum]

There are lots of unfortunate naming choices in CSS (e.g. border-radius instead of corner-radius or hyphen-less currentcolor). As far as I know, none of them have been improved (or deprecated) unless the new alternative also added new features

You hit the nail on the head. Closing.

[nicksherman]

unless the new alternative also added new features

If the idea of font-width is expanded to include support for the registered wdth axis from the new OpenType variations spec, you could indeed say that new features are being added – not only making the name imply additional capabilities, but also tying it more solidly (and intuitively) to the thing it affects.

[nicksherman]

Another thought on @Crissov’s comments …

As far as I know, none of them have been improved (or deprecated) unless the new alternative also added new features

The main difference with most of the other unfortunate naming choices is that font-stretch support still hasn't been widely implemented (if at all).

Between this and the expansion of functionality with variable fonts I mentioned before, I really hope this is enough to convince @litherum to open this issue up again. It seems much more logical to improve the naming for a thing that still hasn't been implemented than it would be to have to explain to confused developers and designers for the rest of time that font-stretch isn't actually doing what the name implies.

[liamquin]

On Tue, 2016-12-06 at 14:05 -0800, Nick Sherman wrote:   The main difference with most of the other unfortunate naming choices is that `font-stretch` support still hasn't been widely implemented (if at all).

AntennaHouse Formatter implements it, synthesizing a font of the appropriate width if necessary. I think YesLogic's PrinceXML also implements it, but does not seem to synthesize a font if needed. The CSS font model doesn't seem to let you say, "I want _this_ font with _this_ transformation done to it" except for very limited cases - the renderer will synthesize a font that renders in blue if needed, or that has underlines, or is slanted, but you can't take the slanted font and unslant it, or the condensed font and expand it. Nor I think can you choose the first font family from a list where roman, italic, roman small caps, discretionary ligatures and historical ligatures are all present. I still sometimes see Times Roman "fi" ligatures on a page using Helvetica. But the fix isn't to rename font-stretch. It might be to add an @font- family or something, I'm not sure.

[mediumjones]

MDN has updated the opening paragraph of their summary of font-stretch to what it is not, due to this issue.

[cjdunn]

I agree that this is a confusing term and that font-width would be a much more accurate term. Especially as OT 1.8 Variable Font support increases, a logical name will be crucial for understanding what this property actually does. It refers to the width of a font and does not refer to mechanically stretching a font, therefore font-width is much more accurate. Please change the name to font-width.

[chrisarmstrong]

Font-width would definitely be more appropriate, as well as being more in keeping with other CSS terms, e.g. border-width (increasing border width & font-width would have a similar visual effect)

[denmch]

I think font-width is the best possible name and shouldn't cause confusion with a distiinction between variable width and monospace fonts since that's a difference between font families and not normally a property within a font family. 'Width' is the normal term covering normal, condensed, and expanded forms within a font family.

[liamquin]

On Mon, 2017-02-27 at 14:55 -0800, CJ Dunn wrote: [...] It refers to the width of a font and does not refer to mechanically stretching a font,

I do know of at least one implementation that synthesizes a font of the given "stretch" if needed. But then, this also happens for bold and italic or oblique.

[cjdunn]

@liamquin Hmm. I'm referring to what Mozilla says about this property:

This property does not change the geometry of an arbitrary font by stretching or shrinking it. Like font-feature-settings or font-variant, it is merely a means to choose the most appropriate face of the font, if this one offers several of them.

[cjdunn]

@chrisarmstrong No. An example of weight would be Light, Bold, Black. An example of Width would be Extra Compressed, Condensed, Wide.

Specific font examples:
–Benton Sans Extra Compressed Bold (Width = Extra Compressed, Weight = Bold)
–Benton Sans Wide Light (Width = Wide, Weight = Light)

See:

https://fontbureau.typenetwork.com/news/article/new-benton-sans-wide

[chrisarmstrong]

@cjdunn yep I meant this bit can also refer to font-weight:

it is merely a means to choose the most appropriate face of the font, if this one offers several of them.

Either way my question doesn't add much to the discussion so I'll remove it, however your answer should be useful to others :)

[colinmford]

I think I would prefer pretty much anything over font-stretch, and while font-width can cause a little bit of confusion, width is a standard term that many font vendors use. I also second @nicksherman's point about it being more closely related to the standard variable fonts wdth axis.

[sairuspatel]

Yes to font-width for several of the reasons mentioned in this thread, but mostly because it closely aligns with OpenType’s OS/2.usWidthClass field and wdth axis. OT font variations are a super opportunity for CSS to make this kind of adjustment.

[dauwhe]

I wonder if we need a more flexible model to account for complex font families. The Adobe Kepler family has 168 members, with a facet of optical weight (subhead | display | caption | regular) in addition to font-weight, font-stretch, and font-style. Knockout has nine weights ranging from "flyweight" to "sumo", and four widths, with naming utterly unrelated to existing CSS values.

[denmch]

I don't think a more flexible model is necessary. Optical weight is more about use cases (i.e., is it being used for an h1 and so very large, etc.) and so is natural to set as a separate family. And you can specify weight numerically (100–900), which already covers the 9 weights of the Knockout example. But font-width is a perfect addition to add robustness.

[alyssamichelle]

I think font-width makes more sense than font-stretch. I think @jpamental said it perfectly. font-stretch makes me think of something you are not supposed to do with your type.

[jpamental]

With regard to @denmch 's comment - It's worth noting that optical weight already has another named axis of variation within the variable font world that is more about x-height proportion that 'visual weight' per se. I'm glad there's more discussion regarding font-width vs font-stretch though - it's well worth talking this through and trying to get it as 'right' as we can!

[litherum]

Every browser other than WebKit has already shipped font-stretch, so it isn't going away (and I'm currently in the middle of implementing it in WebKit).

Everyone agrees that font-stretch is a poorly chosen name. However, it's what we have, it's been widely implemented, and is already in use on the web. We can't get rid of it.

The variations piece of font-stretch should not be pulled into its own property. It's more important to extend an already-existing property for variations, rather than introduce a new property to correct a naming mistake.

Are there any other proposals of how to handle this unfortunate naming choice?

[svgeesus]

@drott any comments on the proposal given that the majority of existing font-stretch usage is from Google Fonts (setting the property to the initial value)?

[drott]

While I agree that the mismatch between name and axis in variable axis is unfortunate, I don't think it's a good use of time and energy to work on a deprecation only for the purpose of a rename with no functional change for a feature that's actively in popular use. If no full deprecation is planned, long term, I don't think we're helped much with an alias.

With regards to the axis mismatch, I don't see this as a major problem. It's by the way perhaps worse for font-style and the ital, slnt axis - and in that area we do have some actual problems to solve for which we have strong developer signal, which may be a better use of time in comparison.

I agree with your own argument, @svgeesus that it clutters the CSS OM and introduces a bit of confusion and requires additional rules how to resolve alias vs. underlying property.

No objections to

2) Add a more visible note to explain the bad name

adding extra explanations to the wording being sub-optimal and historical.

[svgeesus]

As @rviscomi pointed out, 99.6% of usage is, redundantly, setting it to the initial value. So it isn't actively in popular use to actually do something.

[liamquin]

I'd say that it's quite widely used in print stylesheets, e.g. with AntennaHouseFormatter, which DOES use font-stretch to stretch the font - more precisely i think as with font style, and weight, it chooses a matching font if there is one and synthesizes one if there isn't. I don't really see why you want font-stretch to behave differently in that regard. And it's actually technically easier than synthesizing small caps, italics, bold.

When i tried in PrinceXML, i found that the software behaved as if it had stretched the font, but font selection then failed in the resulting PDF. I don't recall testing in Weasyprint or PDFReactor.

You aren't going to be able to measure the prevalence of something in off-web stylesheets by looking at Web statistics, unfortunately.

[scottkellum]

@liamquin I may not be reading that correctly so correct me if I’m wrong here: Do these tools synthesize stretched styles? If so that behavior does not adhere to the font-stretch spec.

User agents must not synthesize stretched faces for font families which lack actual stretched faces.

This proposal will not take away the font-stretch property, it will create a more accurate name. “Stretching” implies a scale transformation of the outlines. That is not what the font-stretch property does. This property selects a font width that has been defined by the designer of the font without stretching or distortion of outlines. This is extremely confusing as the name used implies behavior that is explicitly disallowed in the spec. For backwards compatibility the font-stretch property will still work alongside the more accurate font-width property.

[liamquin]

@scottkellum yes, there are implementations that can synthesize font-stretch (or could when i checked some time in the past 5 years), just as they could synthesize bold and italic. I'm aware it doesn't meet the spec. I don't imagine that renaming it to font-width will change this; you can do font-style: italic, and get a fake italic, so it's pretty absurd that setting font-width when the requested width isn't available can't make a faux condensed (regardless of how ugly it might look). I agree it's not what the spec says. When the spec differs from what implementations do, and from what users expect, there's always the possibility of changing the spec to conform to expectations and to implementations.

This confusion in CSS between font creation/distortion and font selection has always been a problem.

[Crissov]

PrinceXML:

… the property font-stretch might be used, but note that it does not change the geometry of any arbitrary font by stretching or shrinking it - instead, it merely instructs Prince to choose the most appropriate face of the font, if the selected font offers several ones.
Also note that this property is not supported for system fonts on Windows.

Kozea/WeasyPrint#7

https://www.pdfreactor.com/product/doc_html/#font-stretch

[Crissov]

What about changing font-stretch to become a shorthand property that explicitly supports asking for synthesized stretched fonts when no pre-designed ones are available, while a new font-width sub-property only supports the current feature set?

[jfkthame]

I don't think we should be changing the behavior of the existing property. That would have potentially unexpected effects on existing content.

What we could consider, I think, is introducing a new font-synthesis-width property to explicitly enable the use of synthetic width (stretch) variants of fonts when no suitable pre-designed width variant is available. Typographic purists will presumably complain, but given that we have synthesis for other attributes, I don't think there's a strong argument to resist supporting it for width as well. Designers who care about typographic excellence don't have to use it!

[css-meeting-bot]

The CSS Working Group just discussed [css-fonts-4] font-stretch is unfortunately named, and agreed to the following:

• RESOLVED: Add font-width property and descriptor and make font-stretch a legacy alias

The full IRC log of that discussion

<frances> Alan: Next issue is on the name of font stretch
<frances> font-stretch*
<frances> Johnathan: font-stretch should be font-width, would be a better name. Has been this way for a long time, possibly alias the property and use something they understand better.
<florian> q+
<frances> Alan: You mention font-synthesis-width?
<astearns> ack florian
<jensimmons> q+
<frances> Johnathan: Would be different to synthesize, might need to control the behavior. Something suggested to change, but need to alias because would not be backwards compatable
<astearns> ack jensimmons
<frances> Florian: There are different ways to do aliasing, such as legacy aliasing, we should go.
<fantasai> https://www.w3.org/TR/css-cascade/#aliasing
<frances> Jen: I also support this, not something we typically do, can't keep making different changes. Words are meaningful and in adjoining industries, it should just be font-width
<florian> s/such as legacy aliasing, we should go./and the relevant one here is "legacy name aliasing", as defined in css-cascade
<frances> Alan: Add font-width, and make font-stretch a legacy alias for the font description. Issue of expecting what font-stretch should do for another issue
<frances> fantasai: Pretty close to what you are supposed to do.
<fantasai> s/to do/to do for properties per spec/
<frances> PROPOSAL: Add font-width property and descriptor and make font-stretch a legacy alias of those
<frances> Alan: Any objections? Resolved.
<frances> RESOLVED: Add font-width property and descriptor and make font-stretch a legacy alias

[nt1m]

WPT coverage:

• name alias: https://github.com/web-platform-tests/wpt/blob/855859bf3f61ab1a6532a6b98fd92137baf2fabc/css/css-fonts/parsing/font-stretch-alias.html
• animations: https://github.com/web-platform-tests/wpt/blob/855859bf3f61ab1a6532a6b98fd92137baf2fabc/web-animations/animation-model/animation-types/property-list.js#L591-L594

[svgeesus]

Good; but also these three need to be copied, renamed and edited to test font-width:

• font-stretch-computed.html
• font-stretch-invalid.html
• font-stretch-valid.html

[svgeesus]

web-platform-tests/wpt#51775