[css-text-decor] Text underlines' positions cannot be fine-tuned

[litherum]

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

In addition, two new values should be added to text-underline-position, thereby making the syntax:
text-underline-position: auto | [ under || [ left | right ] ] | <length> | file

With this syntax, it is impossible to specify both a <length> as well as under, which is on purpose. The <length> only applies to regular underlines, not to overlines, under-underlines, nor strikethroughs.

In addition, because of the semantic meaning of text decorations, browsers should be able to clamp these values to implementation-dependent sane ranges.

[litherum]

Perhaps percentages should be allowed, resolved against the font-size of the element.

Also, because font-family is inherited, text-decoration-thickness should be inherited too.

[upsuper]

text-underline-position is for the position of underline. As a side effect, it affects where overline is, but I don't see why making it impossible to specify both <length> and under makes any sense. Actually I don't see how putting thickness into text-underline-position makes any sense at all.

Text decoration line properties generally doesn't inherit, because they control the decoration line across an inline box as a while. I know WebKit and Blink mis-implemented those properties as inherited, but I believe that is undesired. Unless there is a good reason, I don't think text-decoration-thickness should be inherited (assuming we would agree to add it, which I have no strong opinion on).

[litherum]

I think you're misunderstanding this proposal. This proposal has two pieces (which keep position and thickness separate):

1. Add a new property: text-decoration-thickness
2. Add values <length> and file to the existing property text-underline-position

text-underline-position already exists and is inherited. In addition, the existing property does not affect overline (it isn't "text-decoration-position" but is instead "text-underline-position")

[upsuper]

Hmm, okay, yeah I probably misunderstood the proposal. So the <length> is about shifting the position of the underline, not controling thickness. That part probably makes sense, although I wonder where would the offset starts. Assuming the baseline? FWIW, text-underline-position should affect position of overline to ensure they are always on the opposite side (in case of left and right), but yeah, specifying offset shouldn't affect overline.

[litherum]

Yes, the offset should start at the baseline. Positive values should be "farther away from the text."

I'd like to amend the proposal to use a unitless number which would scale with font-size instead of <length>. It should be "A value of '1' represents 1px at font-size: 16px, and scales linearly with font-size." That way, when it's inherited, this value would react correctly to different fonts.

[fantasai]

Myles reminded me to comment here: text-underline-position should not be reused for this feature, because it's intended to inherit differently from stylistic considerations like color and line-style in order to align itself with language changes.

Might also be worth trawling www-style for past discussions on these, in case there are some good ideas. Certainly these requests have come up, but were deferred from L3.

[kojiishi]

+1 to add a new property for offset.

[kojiishi]

the offset should start at the baseline

and probably for CJK (or when text-underline-position: under|left|right), the offset should start at the edge of the em box. This tweet (sorry in Japanese but I hope the picture tells something) explains how to set the underline position to the bottom of em box in InDesign.

@r12a: now I wonder, since Latin and CJK want different point to start the offset from, if there were any other requirements in other writing systems?

[Crissov]

Instead of file, wouldn’t a new font-dependent unit, e.g. sw for ‘stroke width’, make more sense? It could also be useful with border-width for instance.

At least for serif (or broken/blackletter) faces, it may even make sense to introduce two units, one for the stem / base stroke (downstroke, \ in x) and another for the hair stroke (upstroke, / in x), i.e. bs and hs or ds and us. I assume most typefaces have an underline thickness around 1hs.

Seeing that ex is implemented as fixed 0.5em almost everywhere, a similar fallback value would be defined for the stroke unit(s) as well, maybe depending on the value of font-weight.

[aaaxx]

I really like this idea. If stroke width is possible to implement as a unit, I think it would also make for a much better way of selecting font weight in the new variable fonts, instead of the current numbers, which force you to take a stab in the dark.

[Crissov]

There was #487 for percentages in font-weight. Defining these as stroke-width divided by font-size (i.e. calc(1sw / 1em) or, possibly more useful, calc(1sw / 1ex)) would lead to different values than I’d expect (which would be a similar but formalized alternative to arbitrary 3-digit unit-less numbers), but could be reasonable.

stroke-width could also be a new font descriptor in @font-face, taking a mandatory (sw = bs) and an optional value (hs ≠ bs) as <length> | <percentage>.

[aaaxx]

Just to confirm I'm reading this right:

1. You're thinking about declaring font-weight by setting the base stroke's width to some percentage of em or x-height?
2. Abbreviations mean:
   • sw is stroke width
   • bs is base stroke (i.e. the thicker stroke)
   • hs is hair stroke (i.e. the thinnest stroke, obviously)
3. The hypothetical stroke-width would be an alternative way of setting weight, by giving either base- or hair stroke a certain width? (Isn't base stroke here redundant if I understood point no. 1 correctly? Or do you mean leaving font-weight as currently specified and using stroke widths for manipulating weight just in this new descriptor?)

[r12a]

now I wonder, since Latin and CJK want different point to start the offset from, if there were any other requirements in other writing systems?

I'm not clear exactly how this works, but baselines are different not only for CJK fonts but also for indic fonts (at least nominally), which have a hanging baseline, ie. at the location of the horizontal bar in

अंतर्राष्ट्रीयकरण गतिविधि

So i'm not clear whether the starting point for the offset, if it was measured from the baseline, would need to be adjusted for each type of script in the document. If so, things would become particularly problematic where you have a combination of scripts with different baselines on a line. Not only would you need to markup up text so that each part gets its own correct offset, but you'd also have to figure out how to have a single underline at the same location under a mixed script phrase, eg.

अंतर्राष्ट्रीयकरण गतिविधि, W3C or 国際化活動 W3C

Hopefully i'm missing something and this won't be an issue?