[css-text-decor] Please implement text-strikethrough-position key

[ryanbugden]

In submitting bug reports to various browsers, and how they are inaccurately rendering from-font values for text decoration (with this test page by @nicksherman), it started to become clear, that within the dichotomy of underline and strikethroughs (the two linear decorations that font files contain metadata for), there seems to be no way to invoke the font metadata which covers the strikethrough’s y-position.

On the CSS level, how we invoke the values from the font:

✅ Underline thickness: Taken care of by text-decoration-thickness: from-font;
✅ Strikethrough thickness: Also taken care of by text-decoration-thickness: from-font;
✅ Underline position: Taken care of by text-underline-position: from-font;
❌ Strikethrough position

On the font level, these are the values in the font:

Underline: post table

• underlineThickness
• underlinePosition

Strikethrough: OS2 table

• yStrikeoutSize
• yStrikeoutPosition

Suggestion:

• Implement a text-strikethrough-position key, for which there is a possible (and hopefully default) from-font value.
• For this position, look at OS2 > yStrikeoutPosition, and interpret it as the y-position of the top of the stroke.

The position of the top of the strikeout stroke relative to the baseline in font design units.

Thanks for your consideration!

[cdoublev]

I wonder why text-decoration-position and text-decoration-offset do not exist to apply for any value of text-decoration-line.

[ryanbugden]

See issues filed with browsers below, which may or may not be able to addressed without this CSS key:

• Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1459479#c2
• WebKit: https://bugs.webkit.org/show_bug.cgi?id=258857
• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1841570

[fantasai]

If the main idea is to get UAs to use font information, well, they should just do it! The spec encourages that explicitly, e.g. https://www.w3.org/TR/css-text-decor-4/#line-auto-offset

The only problem I'm concerned about here is if the fonts contain bogus information. If we're unable to detect those cases and they end up creating widespread problems, then we might need an explicit opt-in.

So I think the right thing to do is file issues against the UAs, as you've done here, and if they push back and say they can't do it without an opt-in switch, then we can revisit and do something about that.

[ryanbugden]

Good points @fantasai . It looks like the Mozilla team is able to do on-the-fly testing for bogus values. If browsers can see whether a strikethrough is outside of the font bounds, maybe they can just (default to honoring the font but) choose their own hard-coded value if so.

[ryanbugden]

cc @drott

[schenney-chromium]

Repeating @drott's question from the bug report ...

Is there an opentype field for strike-through position?

[jfkthame]

https://learn.microsoft.com/en-gb/typography/opentype/spec/os2#ystrikeoutposition