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