[css-text-decor] No way to set the underline width/thickness #239

Open
teo1978 opened this Issue Jun 25, 2016 · 27 comments

Projects

None yet
@teo1978
teo1978 commented Jun 25, 2016 edited

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
Member
upsuper commented Jun 27, 2016

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

@teo1978
teo1978 commented Jun 27, 2016

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
teo1978 commented Jun 27, 2016

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
Member
upsuper commented Jun 27, 2016

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
teo1978 commented Jun 27, 2016

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
teo1978 commented Jun 27, 2016

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
Contributor

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
Contributor
frivoal commented Jun 27, 2016

@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
Contributor
frivoal commented Jun 27, 2016 edited

@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
Crissov commented Nov 17, 2016

#459 is basically a duplicate or continuation of this issue.

@litherum

(Migrated from #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 #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
Crissov commented Nov 29, 2016

@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
Contributor
LeaVerou commented Dec 7, 2016

@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
litherum commented Dec 7, 2016

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
Contributor
LeaVerou commented Dec 7, 2016

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
Crissov commented Dec 7, 2016

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

@LeaVerou
Contributor
LeaVerou commented Dec 8, 2016

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
xfq commented Dec 9, 2016

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.

PS: I might be missing something, but as I understand it, em (or <length-percentage>[1]) is not a font-specific unit.

[1] https://drafts.csswg.org/css-values-4/#typedef-length-percentage

@Crissov
Crissov commented Dec 9, 2016

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

@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
Contributor

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

@fantasai fantasai changed the title from No way to set the underline width/thickness to [css-text-decor] No way to set the underline width/thickness Dec 27, 2016
@astearns astearns removed the Agenda+ F2F label Jan 11, 2017
@litherum
litherum commented Jan 11, 2017 edited

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment