[css-text-decor-4] Add use-font keyword for text-decoration-width & text-decoration-offset

[drott]

In the WG minutes from February 2017 and the discussion in issue 459 there were references to adding a keyword to text-decoration-width and text-decoration-offset. @fantasai suggested to use use-font as the keyword name.

Quite possibly I missed earlier discussions on this, that's why I am asking to clarify:

Can we add such a keyword and specifying is as adhering to the definitions of underlinePosition and underlineThickness in the post table of the OpenType specification?

[drott]

PS: Since currently browser do various things for auto, like applying a fixed scaled underline depending on font-size, etc. or maintain whitelists/blacklists for what fonts have sane values, I think having use-font would be a good way to transition away from this magic and explicitly select what the font designer had in mind.

[fantasai]

Agenda+ to get an official WG resolution on adding this, and to ask if there's preference on what keyword to use. I think use-font and from-font were suggested.

[litherum]

If we do this, we need language to give browsers enough freedom to perform platform-dependent "fixup" to these font values. For example, CoreText performs its own fixup before WebKit even calls into it to get these values.

[litherum]

Also we need to specify which font in the font-family cascade list is used for gathering these metrics.

[svgeesus]

Also we need to specify which font in the font-family cascade list is used for gathering these metrics.

Perhaps the same criterion as we use elsewhere: the first font to have a glyph for 0x20 space.

[drott]

If we do this, we need language to give browsers enough freedom to perform platform-dependent "fixup" to these font values. For example, CoreText performs its own fixup before WebKit even calls into it to get these values.

Would it be sufficient if this fixup would only be applied in the auto case, whereas use-font would use information straight from the font? Can you explain more what sort of fixup this is?

[fantasai]

@litherum We use the “first available font”, as always.

[litherum]

Can you explain more what sort of fixup this is?

CoreText uses a heuristic to guess when a font has bad data, and if it detects bad data, it synthesizes new values and exposes those.

If WebKit wanted to use literally what the font file says, it would have to parse the font file tables itself. This would be unfortunate because the CoreText synthesized data will be of higher quality than the font file itself (that's the whole point of the synthesis).

[svgeesus]

We use the “first available font”, as always.

@fantasai So if the first available font does not have a space glyph, the underline position will be taken from a different font than the rest of the font metrics? That seems odd.

[fantasai]

@svgeesus We use the “first available font” for a variety of operations that are relevant: the sizes of font-relative units, the height and baseline position of the line, etc. We should consistently use it for every operation for which we need a single set of font metrics. And the position and thickness of an underline for a given element is a single set of metrics.

If you have a problem with how the “first available font” is found, file an issue against that. Also if we for some reason have multiple concepts of “first available font”, we should consolidate them into one. There should only be one “first available font” per element, regardless of operation.

[drott]

Can you explain more what sort of fixup this is?

CoreText uses a heuristic to guess when a font has bad data, and if it detects bad data, it synthesizes new values and exposes those.

If WebKit wanted to use literally what the font file says, it would have to parse the font file tables itself. This would be unfortunate because the CoreText synthesized data will be of higher quality than the font file itself (that's the whole point of the synthesis).

I see there are cases when what's in the post table for underlinePosition and underlineThickness cannot be used to draw anything. I wouldn't totally object to stating that the browser can switch to auto / do something suitable if the values are totally invalid, but I would slightly prefer if we can avoid undocumented magic.

Can we perhaps dig in and describe the criteria for when use-font would ignore what's in the font? For example: fall back to auto when underlinePosition is 0x0000, or say larger than the ascent? What would be reasonable criteria? If can't come to a conclusion about such cut-offs, I am okay with leaving this up to implementations.

[litherum]

I would prefer not to specify CoreText implementation details.