[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?

[jpamental]

@litherum I thought early on it was mentioned that aliasing was a possibility? If so, could we sort of swap it 'under-the-hood' so that the 'real' property is font-width and font-stretch is aliased to it, so it could then be deprecated over time? (maybe wishful thinking?)

[litherum]

Yes, aliasing has been proposed, and shown to be ineffective (best summarized in https://github.com/w3c/csswg-drafts/issues/551#issuecomment-253339556 )

[thundernixon]

Just to chime in, even though font-stretch isn't the only unfortunately-named CSS property, it is specifically named as something that many designers are trained is a formally terrible thing to do. "Stretching" is reserved for novices or for deliberately rule-breaking design, whereas "font-width" is the vernacular name for a feature of typographic control that will see more and more use with upcoming variable font technology. As the web becomes a richer and richer typographic tool, it seems like a good opportunity to also embrace a few pieces of mainstream type terminology.

Finally, I do see that font-stretch has momentum, but if WebKit were to do it better, wouldn't that take care of a large percentage of browser users from the get-go, and help prove whether such a concept has value? I might be misunderstanding the coverage of this piece of development, but even if this is Safari-only, positive change has to start somewhere.

[liamquin]

On Tue, 2017-02-28 at 13:15 -0800, thundernixon wrote:

Just to chime in, even though font-stretch isn't the only unfortunately-name property, it is specifically named as something that many designers are trained is a formally terrible thing to do.

"Anyone who would letterspace lower case [blackletter] would steal sheep, said Fred Goudy. There are actually uses for changing the font transformation matrix / "stretching", "skewing", "shearing" in the hands of experts - although, as you point out, this property doesn't actually take a font and "stretch" it with isotropic scaling, but rather selects a font with the given set width (or, possibly, and this clearly needs to be clarified as implementations differ, synthesizes it from an OpenType variation axis or by scaling an existing font).

I can imagine introducing a font-width property that only selects and never synthesizes, and clarifying that font-stretch can synthesize.

I can also imagine introducing a font-transform property and clarifying that font-stretch does not synthesize, but that may break some existing content (or the change not be implemented) - e.g. AntennaHouse Formatter synthesizes.

An example of wanting to transform fonts happens when you're applying a 2d transform but want the individual glyphs to be unaffected, and don't want to (or can't) add additional markup.

[nicksherman]

@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).

These implementations are very new though, correct? And as @thundernixon mentioned, your implementation in WebKit would immediately address a large percentage of browser coverage when it goes out.

it's been widely implemented, and is already in use on the web

Do you have any reference or stats on this? I would be very surprised if there were any more than a few dozen websites in existence that make use of the font-stretch property. And any of them that have made use of that property surely understand that it is not a reliable thing without WebKit support.

Yes, aliasing has been proposed, and shown to be ineffective

The argument that aliasing didn’t work in other different situations (situations that may have been further along in implementation and time beforehand) seems to be a very broad generalization of the potential effectiveness of such an idea. Is there any harm in deploying an alias as @svgeesus, @jpamental, and the earlier version of yourself suggested?

[LeaVerou]

it's been widely implemented, and is already in use on the web

Not much, only 3.16% of websites: https://www.chromestatus.com/metrics/css/popularity#font-stretch

[nicksherman]

4 years later, I'd like to re-ask @litherum the question that wasn't answered here back in 2017: Is there any harm in deploying an alias as @svgeesus, @jpamental, and the earlier version of yourself suggested?

[murtaugh]

Thumbs up for revisiting this issue. In my mind, as someone who has been building websites since before CSS existed, "it's not the only bad name" isn't a good enough reason to not alias font-stretch. CSS will be more welcoming to designers and people trained in the proper use of type if the terminology in CSS matches their expectations.

[svgeesus]

@nicksherman wrote:

I would be very surprised if there were any more than a few dozen websites in existence that make use of the font-stretch property.

@leaverou wrote:

Not much, only 3.16% of websites: https://www.chromestatus.com/metrics/css/popularity#font-stretch

Latest data from the HTTP Archive 2020 Almanac shows usage at half a million websites, or 9% of all sites surveyed.

[piperhaywood]

Would still love love love to see a font-width alias for font-stretch! It seems like a pretty darn good compromise and would bring so much clarity to discussion and education around the use of this property.

I know that @litherum mentioned that aliasing has be shown to be ineffective, but to me, the comment they referred to only demonstrates that the introduction of an alias wouldn’t conform to the reasons for previous aliases, not that its actual effectiveness is diminished.

By waiting to introduce an alias, the percentage of websites using font-stretch just continues to go up. The percentage of Chrome page loads using font-stretch is now at 13%, probably largely a result of Google Fonts introducing variable fonts.

If there’s a really strong reason why an alias shouldn’t be introduced then that makes sense. But I’m not sure that the argument against it thus far outweighs the benefit.

[svgeesus]

(2017) Not much, only 3.16% of websites:

(2020) Latest data from the HTTP Archive 2020 Almanac shows usage at half a million websites, or 9% of all sites surveyed.

(2022) The percentage of Chrome page loads using font-stretch is now at 13%

The 2022 Almanac shows font-stretch at 28%

[svgeesus]

Re-opening due to the volume of comments since it was closed.

[nicksherman]

Yes, at this point (6 years later!) with Webkit's implementation of font-stretch now shipping, and especially with Google Fonts now making use of it, we are probably past the point where outright replacement of the name would be practical. But there is still a very strong case for establishing an alias of font-width for all the reasons discussed before.

[litherum]

Is there any harm in deploying an alias

Yes: maintenance cost. It’s yet one more thing added to the web platform, one more thing whose effects have to be tested. If you set one, does the other one’s computed style change? Do they appear distinct in the CSSOM? Do we use the shorthand mechanism to alias them?

And the new name wouldn’t let authors accomplish anything that they couldn’t already accomplish today. It would take the same grammar and the same values; it’s not reformulating the functionality like grid-template-columns; and there is no new functionality here.

The case for font-width would be easier to make if there were new features here, similar to the relationship between tables and CSS grid. But it seems like we’re just talking about a pure alias here.

[scottkellum]

Thank you for re-opening this @svgeesus!

Some thoughts to echo what has been said before:

Font-width is what I always slip up and say while font-stretch makes me feel like I’m doing bad typography. Distorting fonts is generally considered bad typographic practice and when I hear “stretch” I always assume it means geometrically distort outlines. In no circumstances would I ever use the word “stretch” to describe font widths.

font-stretch is confusing and I’m sure we will see wider adoption and less confusion if this is aliased.

[ashleykolodziej]

This is wild - from an outside perspective, I genuinely thought this was a deprecated property. The thought process that led to that was something like:

• Yikes, who stretches type?
• Oh, we made all kinds of inadvisable design choices in the 90s.
• Ahh, yeah that’s probably it. Must just be a leftover of that era, moving on.

Width is more intuitive to me for sure, not just because of the OpenType naming convention, but because it is more consistent with my mental model of how the units for this property work. I’m used to thinking of something having a width of 50%, and having that be half the width of the default state. I’m not used to stretching an item to 50%, because stretching implies that things get longer or wider, not more compressed.

I really appreciate this discussion, as well as the concern with technical debt and testing regarding adding an alias. I’ll learn either way, but I thought it was interesting that this conflicted so much with what I was taught to do as a designer that my brain invented an origin story to make it stop.

[litherum]

(I do agree the property should have been named font-width back when it was originally invented. I guess we can add this to the list of CSS Mistakes.)

[liamquin]

I'm aware of at least one fairly widely used commercial implementation that does indeed stretch a font along the inline axis when font-stretch is applied. I think it's synthesizing the width if a font isn't available, which is maybe not unreasonable.

[rutherfordcraze]

I don’t have much to add here except agreement with the recent comments. In all other contexts, I’ve only ever understood ‘stretch’ to be something you’re explicitly not supposed to do with type. font-width would be more accurate, and significantly less confusing for existing type users learning CSS.

(And even as a long-time CSS user, I still find myself falling back to font-variation-settings or setting font-synthesis: none unnecessarily, because subconsciously I worry font-stretch will distort the type if other widths aren’t available.)

[svgeesus]

A Twitter poll found that most people don't know what font-stretch property does and had never used it. Those who hazarded a guess slightly favored the (incorrect) "it stretches the glyphs" interpretation (which the spec currently forbids) over the correct, "it selects a width variant" option.

The same poll on Mastodon reversed the slight lead among those guessing what it does (perhaps due to promotion on type.social) but again most respondents had not used it.

[svgeesus]

I'm aware of at least one fairly widely used commercial implementation that does indeed stretch a font along the inline axis when font-stretch is applied. I think it's synthesizing the width if a font isn't available, which is maybe not unreasonable.

The spec specifically forbids this:

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

[alyssamichelle]

As suggested by @turtleguyy, a suitable substitute for font-stretch could also be font-chonkiness.

[svgeesus]

If you set one, does the other one’s computed style change? Do they appear distinct in the CSSOM? Do we use the shorthand mechanism to alias them?

I would propose:

• defining the property name as font-width
• declaring that "for historical reasons" a deprecated alias is accepted, font-stretch
• setting font-stretch actually sets font-width, they are not two separate properties
• getting either font-stretch or font-width gives you the computed value of font-width
• removing all uses of "stretch" in the property description