Csswg-drafts: [css-text-decor] No way to set the underline width/thickness

[teo1978]

https://drafts.csswg.org/css-text-decor-3/

There's no way to set the thickness of the line underlining text in a text-decoration: underline?? You must be kidding me.

[upsuper]

The thickness of text decoration lines are controlled by fonts in general.

[teo1978]

I know, so what?

What if you want a thicker line without increasing the font size, or viceversa?

Also, different browsers render lines of different thickness even with the same font size (and yes, they are actually using the same font), because no standard tells them how thick the line must be; so, you may want to set an explicit value for consistency across browsers.

[teo1978]

The color of the decoration line by default is controlled by the text color. Does that mean the property text-decoration-color is not needed?

[upsuper]

There are use cases for different color for decoration lines. Thickness is, hmmmm, I have no idea.

As far as I can see, normal word processors includeing Microsoft Word and Apple Pages do not provide option for thickness of decoration lines, either, which may indicate that this isn't something with high demand. Microsoft and Apple must be kidding you as well :)

For implementation, it doesn't seem to be something very hard to add if the spec is clear, so I'm not strongly against this, anyway.

[teo1978]

If this is w3c's way of reasoning, well, that explains a few things.

There are use cases for different color for decoration lines. Thickness is, hmmmm, I have no idea

What about this use case: "i want a thicker line". How is that less obvious than "i want a line of a different color" or "i want a dashed line"?

normal word processors includeing Microsoft Word and Apple Pages

_Now_ you really must be kidding me. Is that what inspires css specifications? But that again would explain a few things.

(btw i don't use word processors but yes, Microsoft and Apple do do idiotic things and their products often do have ridiculous bugs or lack obvious functionalities, so i don't see why that should be a surprise)

For implementation, it doesn't seem to be something very hard to add if the spec is clear,

That's kind of an understatement. It seems totally trivial, especially if compared to other stuff that already is in the specs.

so I'm not strongly against this, anyway.

How someone could be even _mildly_ against something like this is beyond me.

[teo1978]

And if you still doubt there's demand for this feature (btw, a spec body should anticipate demand for features, not be driven by it, let alone even question how high it is) just Google for "underline thickness css" and the like and look at the number of questions in Stack Overflow (the usual answer being "use border-bottom", because as Einstein said...)

[SebastianZ]

Note that this topic already came up several times on the mailing list. E.g. @LeaVerou started a thread about this in 2014 and Lutz Issler in 2012.

Sebastian

[frivoal]

@teo1978 Your aggressive tone is unlikely to get you any friend. You have a valid point to discuss, no need to be angry about it. Attacking the first person who finds your point interesting enough to consider, even if they don't agree with you won't get you very far.

If this is w3c's way of reasoning, well, that explains a few things.

The w3c isn't one person, and it doesn't have one way of reasoning. Different people have different reasons for supporting or opposing things, and you need to convince enough people that your suggestion is useful to make something happen. You seem to have fairly good arguments. I would be a pity if people dismissed you as a troll and stopped listening (Just to be clear, this is not a threat).

MS Word and Apple Page are not taken as models to follow or as a source of inspiration. But they are an OK way to evaluate if something is commonly used / needed. Your answer that people ask for it all over stack overflow is a good counterpoint, but Microsoft or Apple bashing will get you nowhere.

[frivoal]

@teo1978

How someone could be even mildly against something like this is beyond me.

Simple things that look sort of useful, but are requested by few people still take time to argue about (syntax, specific semantics, corner cases...), document, write test cases for, implement in multiple browsers, verify that everybody does it the same way. Doesn't mean it can't be done, but even simple things have a cost when you want to make them into a standard, and all implementors already have a gigantic backlog of things they think are important and want to do. So if you want this, it's on you to convince them they should devote time away from whatever it is they are currently doing to take care of this. Proof that lots of people want it help. Proof that it cannot (easily) be done by some other way help. Proposing a syntax helps.

[bradkemper]

Note that this topic already came up several times on the mailing list. E.g. @LeaVerou started a thread about this in 2014 and Lutz Issler in 2012

Here is one from 2011:

https://lists.w3.org/Archives/Public/www-style/2011Mar/0593.html

[Crissov]

459 is basically a duplicate or continuation of this issue.

[litherum]

(Migrated from https://github.com/w3c/csswg-drafts/issues/459)

Being able to control thickness of underline is something that we have often seen web authors request.

Designers often want to control the thickness and position of underlines. Typographically, these underlines often are the thickness of certain particular strokes inside glyphs, which browsers / text libraries have no concept of. Therefore, information required for higher quality sizing / placement must come from somewhere else.

Naively, this additional information could come from the "post" table inside font files. However, because this information is often unused, many font files have garbage data in these fields. (As an aside, I committed a patch to WebKit to use these fields, but had to revert it 7 hours later because of the low-quality data.)

Therefore, this information should come from page authors. There should be a new property:
text-decoration-thickness: auto | <number> | file

The auto value is the default, and represents browsers' current behavior. The file keyword means to use the values from the primary font file itself (where "primary" means "the same font file which determines the horizontal and vertical text metrics for the element"). If a font file format is used which does not include these values, then file behaves like auto.

For the "number" value, a value of '1' represents 1px at font-size: 16px, and scales linearly with font-size.

---

There was some discussion in https://github.com/w3c/csswg-drafts/issues/459 about creating CSS units which refer to the stroke width(s) of a font. However, that idea is separate from this one because, even with CSS units, this property is still required so that the units can be specified. In the proposal above, there is no value accepted, but if new units are created, this property can be extended to accept a new value. For now, though, this proposal doesn't include that piece.

[nicksherman]

For the "number" value, a value of '1' represents 1px at font-size: 16px, and scales linearly with font-size.

This seems confusing … Why not just allow the same kinds of length values that are allowed for most other size properties? That way if someone wants the line weight to correspond to the font-size, they can specify it as an em-based value.

[Crissov]

@nicksherman is right. A magic numeric value is not very CSSish, just use a length and provide at least one useful new unit for it. A certain unit may default to 0.0625em = calc(1em/16).

[litherum]

A length is bad because it doesn't scale with font-size.

[nicksherman]

@litherum The main benefit of lengths specified in em units is that they do indeed scale with the font size.

[LeaVerou]

@litherum A length specified in em, ch does scale with the font size, but authors also have the choice of units that don't scale with the font size. Flexibility is good!

[litherum]

Sure. We should probably add a note mentioning that the font-specific units should be used.

[nicksherman]

@litherum I think “should be used” is even a little too strong. I can easily imagine designers wanting underline thickness to be the same for small body text and larger headlines. As @LeaVerou said, flexibility is good! Maybe instead add a note that font-specific units can be used.

[LeaVerou]

I don't see why such a note is needed at all. Specs are primarily read by implementors, not authors. Also, authors are pretty familiar with em units by now, so I think it's a but superfluous. We don't have such a note in line-height, text-indent or letter-spacing, which benefit from em units just as much.

[Crissov]

Specs are (hopefully) also read by tutorial writers and other educators.

[LeaVerou]

Specs are (hopefully) also read by tutorial writers and other educators.

Only the few really good ones. Most of them just read other second-hand info (other tutorials and MDN or similar).

[xfq]

A little bit off-topic, but in CSS2§1.2:

This specification has been written with two types of readers in mind: CSS authors and CSS implementors.

As for this issue, I think the details of the spec text (e.g., whether a note is needed) can be discussed after discussing the proposed syntax (i.e., property & values).

[Crissov]

I prefer established widthover thickness and also, as in my comments on #459, new length units.

~css
@font-face {
font-family: Example; src: url(example.woff);
stroke-width: 0.05em /* base-stroke / 0.05ex / hair-stroke /; / auto would trust metadata /
}
.example {
font: 16px Example; font-size-adjust: 0.6 / 1ex = 9.6px /;
text-decoration-width: 1bs; / = 0.8px or actual stroke width or default 1em/16 = 1px /
font-weight: 120%; / = 1.2 × 1bs / (1em/16) – different definitions possible */
}
~

[fantasai]

This feature has been on the to-do list for CSS Text Decoration Level 4 since its inception, fwiw. Just been waiting on Level 3 to stabilize more and garner further implementation before continuing work on L4.

Since I've just completed the DoC for L3's second CR stage, I took the liberty of drafting up a proposal in the L4 unofficial draft, which you can find here: https://drafts.csswg.org/css-text-decor-4/#text-decoration-width-property

Comments welcome.

I anticipate that the WG will approve the addition in principle since, as mentioned, this has been requested multiple times and it is a relatively straightforward feature. That said, I'd like to have the revision of L3 prepared, approved, and published so we can fold it into the L4 draft before publishing FPWD, so there does remain a bit of work on L3 before this gets 100% on track. L4 is currently a bit sketchy with most of its text missing. ^_^

+1 to everything Florian said, btw. It's not that we don't care, it's that there's a million things to do and limited time and resources with which to do them...

[litherum]

@fantasai Thanks for the em note.

I'm not sure that floor should be specified. In particular, if text is rotated 45deg, browsers should be free to not round at all (and ours doesn't in this situation).

We do, however, probably want some prose describing whether underlines grow down or up. It seems to me that underlines should always grow away from the baseline.

[litherum]

It's probably too early to bike shed, but "width" usually means "horizontal width" which is inaccurate in this case. "Thickness" seems more accurate.

[LeaVerou]

It's probably too early to bike shed, but "width" usually means "horizontal width" which is inaccurate in this case. "Thickness" seems more accurate.

True, but I'd value internal consistency (consistency with the rest of CSS) more than external consistency. We tend to use width for things like that (border-width, outline-width, stroke-width etc).

[svgeesus]

The term "stroke-width" is pretty universal in graphic arts. and two of the four borders are vertical; no-one seems to find border-width confusing.

[kojiishi]

Are we never going to add a property to control the width (the horizontal length) of underlines? If there were any possibilities, we may regret to have used the term for the thickness.

[kojiishi]

@svgeesus agree, text-decoration-stroke-width is clear, but text-decoration-width isn't. If we were going to the former, please disregard my comment above.

[bradkemper]

@kojiishi I would personally call that text-decoration-length (referring to the length of the line). I think line thickness should always use -width to be consistent with borders, etc.

[bradkemper]

The em note is a good tip for getting widths relative to font-size, but I wouldn't want "strongly encouraged". 'ch' and 'ex' would also be good choices there. Some authors want type-relative thicknesses, others (like me) think that looks weird, and would never want more than 2px or less than 1px. I also wouldn't want fractions of a device pixel (which might be rendered as less than full opacity).

[bradkemper]

The L4 text should maybe say that the 'auto' value is generally expected to be the same thickness as an underscore character, or something, and might also be derived from PostScript/OpenType tables. UAs can also set lengths in their UA style sheet, if they want something different from that, such as 1px or calc(1em / 16).

[bradkemper]

s/set lengths/set widths

[fantasai]

The CSSWG resolved to add text-decoration-width on January 12th:
https://lists.w3.org/Archives/Public/www-style/2017Feb/0055.html
You can see the text in the Editor's Draft here:
https://drafts.csswg.org/css-text-decor-4/

If there are problems with specific details of how it's specced, please file new issues.

Thanks!