[css-text-decor] Rename `text-decoration-thickness` to `text-decoration-weight`?

[jensimmons]

I discovered this week that there was still a bit of confusion about the name of the new CSS property for adjusting the width/thickness of an underline. (Mozilla had implemented the older name & just updated to the new one..) Because I was poking around, trying to figure this out, a new name occurred to me.

For background: Currently, see draft spec, the name for this new property is text-decoration-thickness. It was originally called text-decoration-width. The name was changed last October. Best I can tell, along the way, some folks argued "width" better matched some of the other CSS properties, like border-width. While some argued width is confusing, because it's not going to adjust the length in the inline-direction. (I agree with this, width sounds like adjusting the length of the underline, not the thickness). Some folks also argued that the word "thickness" is not great for an international audience, the 'th' might be especially hard for non-English speakers. I don't think that any other names were debated (from a cursory skim of the issues).

Yesterday, I was chatting with a journalist/editor in NYC about CSS and recent CSSWG debates, and he said in his world of newspaper typesetting, that dimension is called weight. They talk about the weight of an underline. Which struck me as perhaps a really good solution.

text-decoration-weight

This better matches existing CSS — font-weight also adjusts the thickness of typographic lines (the one inside the characters themselves). It's not a word that's as hard for an international audience. And it will not be confusing for Authors.

Thoughts?

It's annoying to have to change existing implementations (shipped in Safari, on it's way in Firefox). But perhaps this is worth it?

@litherum @fantasai ?

[AmeliaBR]

The values for underline thickness aren't consistent with the values for font-weight, though. So that could provide another aspect of confusion.

[SebastianZ]

I'm torn between the two. "thickness" and "weight" both have their pros and cons.

As a non-English speaker I do not have problems understanding it's meaning. As far as I know, 'th' only causes pronunciation problems for some people but they don't have problems when writing it.

Anyway, pros for "thickness" are that it's generally understandable in this context and there are already implementations using it, cons are that it's a bit long and doesn't relate to any other property name.

Pros for "weight" are that it relates to font-weight and it's short, cons are that it's rather hard to spell because of the "gh", its meaning may not immediately be clear without knowledge of typography, and that implementations would have to be changed (again).

Sebastian

[litherum]

Are we really going to rename something after there are two implementations of it?

[dholbert]

I'm not entirely opposed to changing Firefox's implementation -- ours hasn't been preffed on by default yet, and we spun up & landed a rename patch for "-thickness" in a matter of hours last week. :) But I do agree there should be a high-ish bar for performing another rename.

I do share @AmeliaBR's concern that font-weight has an entirely different category of values, which makes the analogy/muscle-memory more confusing, IMO. And to me, "weight" sounds like a fuzzy "suggestion", and less like a pixel-precise measurement (perhaps because I'm used to font-weight where that's basically what it is).

[fantasai]

I agree with not renaming to -weight based on @AmeliaBR's argument that its values are not related to font-weight.

I'm still disappointed that we renamed from -width to -thickness, given every other line thickness in CSS is labelled as -width and having this be different is arbitrary from an i18n and learning perspective.

[Crissov]

stroke-width and ::marker could have been a model.

::lines {stroke: gray}
::underline {stroke-width: 2px} 

[jensimmons]

Are we really going to rename something after there are two implementations of it?

I definitely understand this concern.

[jfkthame]

Agree with the comments that -weight is not appropriate because the values bear no relation to font-weight; I think that would be confusing.

I'm on the fence regarding -thickness vs -width; could live with either, I think. It does seem a little odd for something that ends up as a two-dimensional shape on the page to use width for the dimension that is normally its height. It makes sense (IMO) if we think of the decoration as a line described by its length and width (which would be independent of the line's orientation), rather than as a rectangle (normally a very slim one!) that CSS would describe by width and height. But we don't expose its length because that is automatic, at which point the width sounds like it should be associated with a height like other CSS widths.

The -thickness name avoids the (false) implication that this is a horizontal measurement, but does perhaps seem less natural as a way to describe a line. Another possible name could be text-decoration-breadth, but I doubt anyone will like that; it sounds clumsy to me, even though it's a couple of characters shorter.

[fantasai]

@jfkthame Particularly from an i18n perspective, given all other line weights in CSS (literally all of them, including from SVG) are in properties called -width, I think CSS would be easier to learn if this one also was named -width. If we were starting from scratch, maybe calling them all -thickness or -weight or -breadth or whatever would be better to avoid confusion with the sizing properties, but given where we are now...

[jensimmons]

I put this on the CSSWG call agenda, but can't make today's meeting. Please do discuss this without me (we need these to be resolved so work in Gecko is not slowed down).

Personally, I prefer -thickness to -width. And I prefer -weight over both of them.

I believe text-decoration-weight is best because that is actually what is is called in print typography. And we should use terms that have been used for hundreds of years when we can. Especially since this one does make a lot of sense. It's clear what it is.

I do not think it's a problem that text-decoration-weight would have different values to font-weight. People can learn this. It makes sense.

I also understand if the CSSWG decides that this has already been litigated, and wants to stick to -thickness. I just thought -weight might be a prefer solution, and wanted to bring it up, since I don't believe the idea occurred to us in the past. And THAT'S THE WORD FOR IT IN TYPOGRAPHY.

Wherever the discussion leads, I do want to see this resolved quickly. We on working on this in Gecko, and I want us to be able to ship as soon as we are ready.

(BTW, Chrome/Edge?? Any movement?)

[faceless2]

weight: consistent with print typography.
width: consistent with the rest of CSS.
thickness: er...

[bradkemper]

Forgive my plain speaking, but please let it be -width. It is a burden on authors new and old to have to remember inconsistent naming for similar concepts. We should not have to try to recall which properties use -thickness, which use -weight, which use -width, and which use whatever we come up next year for the next property needing to describe the stroke width of a line.

In case I miss a meeting where we discuss this again, please recall my urging for -width (text-decoration-width and for all future values measuring the thickness of lines). It is too late to go back and change border-width and outline-width and border-image-width to something else, and consistency is important.

[Crissov]

text-decoration-width has a disadvantage (besides lacking a -height counterpart): We might want to add a property to control the (possibly negative) amount a decorative line protrudes beyond its text, which could be called text-decoration-width as well, although -length, -extent and -protrusion would also be available.

Normal Underline
----------------

  Elongated Underline  
-----------------------

Shortened Underline
  ---------------

Shortened Underline with Skips
  -----     -----    --   ---