Intent to Ship: text-decoration-skip: ink objects; as default

[Dominik Röttsches]

Contact emails

dr...@chromium.org, ko...@chromium.org

Spec

https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-property

https://html.spec.whatwg.org/multipage/rendering.html#the-page

No tag review filed, since it's not introducing any new API or CSS properties, rather about changing a default.

Summary

In Chrome 57 we shipped support for text-decoration-skip: ink; which allows skipping descenders in underlines (illustration). We initially suggested making it the default in the intent process but dropped this part for shipping because we had assumed a spec change was required.

Feedback by fantasai@ in the CSS working group spec process has been that UA's may choose to define such default behavior and such a change would not require changing the CSS initial value in the specification.

Feedback in a thread on the Blink API Owners discussion group said that in fact such UA stylesheet changes should be specced, but also that vendor coordination about UA style sheet standardization has room for improvement.

Koji and I would like to add a new text-decoration-skip value to the body style rule:

body {

…

   text-decoration-skip: ink objects;

}

We believe we gain better typography on the web with this change.

Link to “Intent to Implement” blink-dev discussion

Previous Intent to Ship for text-decoration-skip, without changing the default..

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://drott.github.io/underline.mp4

Debuggability

As other CSS text-decoration properties through DevTools.

Risks

Interoperability and Compatibility

We see a low compatibility risk. 

Safari has been shipping their own version of this change since 2014 and made underlines skip descenders by default. It's possible to disable this through -webkit-text-decoration-skip: none, or the 'objects' value. In Blink, it's possible to disable descender skipping by using text-decoration-skip: objects CSS.

In terms of interoperability: The text-decoration and text-decoration-skip feature itself has good interoperability. Safari has moved forward on their own with setting 'auto' as a default value. Changing the default in Blink would result in a visual change for the default underlines (an improvement, we believe). Text metrics or layout would not change and in that sense, it would not break any existing text. A change in the computed style for text-decoration-skip would be observable.

As for standardization, Domenic Denicola suggested to file a pull request against the HTML spec's UA style sheet section and/or a pull request in web-platform-tests for testing against the default UA computed style value.

Edge: No signals, still on uservoice

Firefox: Public support, bug

Safari: Safari enabled underline descender skipping in Safari 8 in 2014. Shipped as -webkit prefixed version since 2014 with keyword: auto, which is now unspec'ed. Safari supports values 'objects' and 'ink'. It parses 'none', too, but this values behaves like 'objects'.

Web developers: Positive, Link to Blog Post by Marcin Wichary, a Medium Designer

Is this feature fully tested by web-platform-tests?

• We have own extensive tests for text-decoration and text-decoration skip in 
• LayoutTests/fast/css3-text/css3-text-decoration/ which are mostly pixel/visual tests, since it's hard to ref-test the mostly visual results of this feature.

Issue 769629 tracks moving them to wpt.

Entry on the feature dashboard

Chromestatus entry for text-decoration-skip - we're not creating a separate feature dashboard entry for changing the default.

[zco...@gmail.com]

I think the selector should be *|*:root -- i.e., it should apply to the root in any namespace, not just HTML body. This would make it apply also in e.g. SVG images.

cheers,

[Anne van Kesteren]

On Thu, Sep 28, 2017 at 10:12 AM, Dominik Röttsches <dr...@chromium.org> wrote:
> Feedback in a thread on the Blink API Owners discussion group said that in fact such UA stylesheet changes should be specced, but also that vendor coordination about UA style sheet standardization has room for improvement.

It's standardized in the HTML Standard. And can be tested through
getComputedStyle() and friends. What can be further improved?


--
https://annevankesteren.nl/

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of Anne van Kesteren

> It's standardized in the HTML Standard. And can be tested through getComputedStyle() and friends. What can be further improved?

The issue is that historically there hasn't been great correspondence between the standard/tests and implementations on the UA style sheet. So, we can improve that by being better going forward, which it appears this intent plans to do :).

Looking forward to the HTML Standard and web platform tests PRs, Dominik/Koji!

[Philip Jägenstedt]

Some discussion ended up off-list by accident. To summarize:

Dominik sent https://github.com/whatwg/html/pull/3102 and https://github.com/w3c/web-platform-tests/pull/7605 for a spec + test change.

Then, discussion moved on to https://github.com/w3c/csswg-drafts/issues/727.

Dominik's suggestions look reasonable to me and I'd be fine moving ahead with that on the assumption that the spec will come to agree, but Domenic and Koji think perhaps we should try to move the CSS WG issue along.

Dominik, what do you think we should do?

[Dominik Röttsches]

We can await the progress of the WG for this week. If the subject continues to move slowly after that, I would suggest we do change the initial value to objects ink and update our implementation later should the discussion take a different direction in the WG, which I don't expect. WDYT, Koji?

[Koji Ishii]

Sounds good plan to me.

The initial value of this property is designed to change as the spec evolves, so I'm not too worried about it being the source of interoperability problems. L4 added 2 new values, and both values were included in the initial value of L4. WG may change this property to a shorthand, and add several longhands to allow setting individual values independently, but it doesn't change the situation where the initial value of the shorthand varying as spec evolves.

fantasai and I plan to discuss sometime this week, I'll get back to you if we can get something soon, though, formalizing it is likely to take long.

[Dominik Röttsches]

After more spec discussion, this Intent to Ship is superseded by a new one for a property with a changed name:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/47BHtmz0jVY/itAC_xpwBgAJ

[PhistucK]

The new default looks kind of hideous (to me?)...

Is this the intended look, or is this a buggy implementation?

Note - font smoothing and ClearType are intentionally disabled on my Windows (even though it is not always honored, that is a known bug in the Developer Tools).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c064a3b-f9fb-4d63-8178-fbb7e74c9bc6%40chromium.org.