Csswg-drafts: [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 [email protected]
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