Intent to Ship: text-decoration-skip-ink: auto; / Intent To Deprecate and Remove: text-decoration-skip:

1,891 views
Skip to first unread message

Dominik Röttsches

unread,
Oct 24, 2017, 4:38:36 AM10/24/17
to blink-dev, Philip Jägenstedt, Koji Ishii, Emil A Eklund

This supersedes the previous Intent to Ship for text-decoration-skip with values objects, ink as default.


Contact emails

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


Spec

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


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.


We would now like to enable ink skipping by default.


The feedback on the previous intent to ship had been to seek for standardization of an initial value that allows us to do ink skipping by default.


After several rounds of discussions in the CSS WG, I believe we have a viable way forward:


The discussion in https://lists.w3.org/Archives/Public/www-style/2017Feb/0069.html concluded with

  RESOLVED: Use text-decoration-skip-ink with at least values of
            auto and none and have it cascade separate from
            shorthand. We will have some normative text describe how
            auto works, but we'll figure the details out in the
            future. Do this in L4.

This was now incorporated into CSS Text Decorations Level 4:

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

With the 'auto' value as initial.


This is a new property. While we were talking about 

   text-decoration-skip: ink objects;

before, we now propose to rename the property to

   text-decoration-skip-ink: with value auto and none;

('ink' moves to the property name)


Hence, we also propose to deprecate the old property text-decoration-skip.


As before, 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.


Interoperability and Compatibility Risks


We see a low compatibility risk. 


With regards to deprecation of the old and moving to a new name of the property: While adoption of the old text-decoration-skip property has been rising from April to October from close to 0 to 0.12, we believe it is almost only used for activating the feature. Here, we propose here to activate the feature by default. So while we rename the property, we would not introduce any functional change for these cases where pages used the old property to activate the feature.


Data from Microsoft crawler based usage stats shows  a majority of usages setting it to "ink", nobody setting it to "none", and some cases setting it to "initial".


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


With regards to interoperability: We're following the recommendation and CSS WG's resolution for the new property name text-decoration-skip-ink: auto. With that we would be the first UA to adopt this newly specced property. Safari has moved forward on their own with setting 'auto' as a default value on the non-standard -webkit-text-decoration-skip.


Changing the default in Blink would result in a visual change for the default underlines (an improvement, we believe). 


In any event, text metrics or layout would not change. There would only be a visual difference for underlines. It would not break readability or layout of any existing text.


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?

Issue 769629 tracks moving them to wpt. Issue 777428 tracks the rename of the property should this Intent be LGTM'ed.


Entry on the feature dashboard


Chromestatus entry for text-decoration-skip-ink

Dimitri Glazkov

unread,
Oct 24, 2017, 11:29:22 AM10/24/17
to Dominik Röttsches, blink-dev, Philip Jägenstedt, Koji Ishii, Emil A Eklund
LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBsxfst%3Dnz8oN65MDk08PypHHuDc%2Bob8iQWJ%2BdCOOTgXsg%40mail.gmail.com.

Chris Harrelson

unread,
Oct 24, 2017, 12:01:46 PM10/24/17
to Dimitri Glazkov, Dominik Röttsches, blink-dev, Philip Jägenstedt, Koji Ishii, Emil A Eklund
LGTM2

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/CAOtFfx5xgHZ3eOKuoXRPH9QEHO_QDUOjWvSFts-js9qnV7oGnw%40mail.gmail.com.

Philip Jägenstedt

unread,
Oct 24, 2017, 3:29:54 PM10/24/17
to Chris Harrelson, Dimitri Glazkov, Dominik Röttsches, blink-dev, Koji Ishii, Emil A Eklund
LGTM3

Thanks for the detailed interop & compat analysis. Microsoft crawler based usage stats is pretty cool, I hadn't seen that before, I've added it to https://sites.google.com/a/chromium.org/dev/blink/platform-predictability/compat-tools.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

klima...@gmail.com

unread,
Nov 8, 2017, 4:33:19 PM11/8/17
to blink-dev, foo...@chromium.org, ko...@chromium.org, e...@chromium.org
Does that mean https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration-skip page is outdated and will be removed?

jj

unread,
Nov 8, 2017, 6:12:01 PM11/8/17
to blink-dev, foo...@chromium.org, ko...@chromium.org, e...@chromium.org, klima...@gmail.com


Am Mittwoch, 8. November 2017 22:33:19 UTC+1 schrieb klima...@gmail.com:
Does that mean https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration-skip page is outdated and will be removed?

This means this page needs an update at least. Removal may be, but not yet I'd say.

David Issel

unread,
Jan 31, 2018, 4:40:37 PM1/31/18
to blink-dev, foo...@chromium.org, ko...@chromium.org, e...@chromium.org
Don't take this the wrong way, but I find the "skip ink underlining" to be ugly.  How do you turn this feature off (browser level)?

Stephen Chenney

unread,
Feb 5, 2018, 11:23:34 AM2/5/18
to David Issel, blink-dev, Philip Jägenstedt, ko...@chromium.org, Emil A Eklund
We're getting a lot of bug reports for bad underlines with this change. Basically skipping way to much.

I would like to revert it until the bugs are fixed.

Stephen.

On Wed, Jan 31, 2018 at 4:40 PM, David Issel <bolt...@gmail.com> wrote:
Don't take this the wrong way, but I find the "skip ink underlining" to be ugly.  How do you turn this feature off (browser level)?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Paul Klimashkin

unread,
Feb 5, 2018, 1:55:41 PM2/5/18
to blink-dev, bolt...@gmail.com, foo...@chromium.org, ko...@chromium.org, e...@chromium.org
Stephen , could you share an example of bad styling?

Stephen Chenney

unread,
Feb 5, 2018, 2:39:03 PM2/5/18
to Paul Klimashkin, blink-dev, David Issel, Philip Jägenstedt, Koji Ishii, Emil A Eklund
On Mon, Feb 5, 2018 at 1:55 PM, Paul Klimashkin <klima...@gmail.com> wrote:
Stephen , could you share an example of bad styling?

[Re-posting from right address, sorry for duplicates]

Yes, sorry I did not do this initially.

https://bugs.chromium.org/p/chromium/issues/detail?id=808603text-decoration-skip-ink + underline dotted = spurious skips
https://bugs.chromium.org/p/chromium/issues/detail?id=807343 Dotted underline broken on Chrome due to `text-decoration-skip-ink`
https://bugs.chromium.org/p/chromium/issues/detail?id=806553, squiggly red underline that appears under misspelled words should not overlap lower case q,y,p,g and j (Note comment #4, which may or may not indicate users reporting issues)
https://bugs.chromium.org/p/chromium/issues/detail?id=796381, Letters with descenders break URL underline on mobile (Not a bug, but unexpected behavior that has appeared in other bugs)
https://bugs.chromium.org/p/chromium/issues/detail?id=793762, For Hangul, Underlines drawn with 'text-decoration: underline solid' are broken at some font sizes or under some characters (Fixed, but some comments are complaining about residual issues)
https://bugs.chromium.org/p/chromium/issues/detail?id=784493, underscores in links are broken with text-decoration-skip-ink: auto
https://bugs.chromium.org/p/chromium/issues/detail?id=782561, Underline breaks while typing letters like 'y','q','j','p' in "Gmail" app. (Our own test team didn't know about the change)
https://bugs.chromium.org/p/chromium/issues/detail?id=782131, Regression: Underline is not seen proper for 'play' thumbnail (Not broken, expected, but for a word like "Play" our implementation is sub-optimal, confusing a little bit of underline after the "y" for a period.)

Looking at this, my primary complaint is that it was enabled by default while the implementation had a lot of user-facing issues. There were no tests for dotted or dashed underlines that I can see from the code review, nor significant testing across fonts. I understand that this is essentially impossible to test comprehensively, but all the more reason to roll out slowly.

My opinion is that a change with this many issues should be reverted in M-64 to give time to fix the problems before too many users see it. But that ship might have sailed.

Even better may have been launching it as experimental to flush out issues.

Stephen.
 

Dominik Röttsches

unread,
Feb 6, 2018, 10:32:38 AM2/6/18
to Stephen Chenney, Paul Klimashkin, blink-dev, David Issel, Philip Jägenstedt, Koji Ishii, Emil A Eklund
Hi Stephen,

thank you for the feedback and summarising the situation by pointing out the set of issues on this topic.

Looking at this, my primary complaint is that it was enabled by default while the implementation had a lot of user-facing issues. There were no tests for dotted or dashed underlines that I can see from the code review, nor significant testing across fonts. 
I understand that this is essentially impossible to test comprehensively, but all the more reason to roll out slowly.
My opinion is that a change with this many issues should be reverted in M-64 to give time to fix the problems before too many users see it. But that ship might have sailed.
Even better may have been launching it as experimental to flush out issues.

From my point of view, we have been rolling this out with care and attention to detail. As Koji pointed out on separate thread, the implementation has been shipping since M57 - not as a default, but as an optional feature using the text-decoration-skip: ink; syntax. Between M57 and the end of the M63 beta period, I believe this amounts to significant exposure. 

In the initial CL from October 2016, a comprehensive test for ink-skipping was added, testing all underline styles, including dotted and dashed, for horizontal and vertical layout using the Ahem font. As you point out, beyond that, testing against a wide selection of fonts is difficult, especially since our layout testing infrastructure is difficult and prone flakiness when using more than a minimal set out of the available system fonts.

What we see after shipping it as a default: A lot of positive signals from users and the typographic community, and a set of positive reactions from colleagues to this change.

But what we also see learned after shipping as a default: Particularly with the default monospace and sans-serif font on Linux, as many of us experience when using crbug.com or Chromium code review, underlines for URLs or code are less than optimal with the new default (784493): 
We're addressing this in this CL by exempting slash, backslash and underscore from ink-skipping, as we do for CJK. Since this is not an intrusive change, we can consider merging this to 65 beta or 64 stable. I agree it's unfortunate that this was captured late in the process. We will strongly consider a staged rollout or using an experiment for a change of this significance next time.

Searching the Chrome forums for "underline", I find this thread about the same URL/links issue, but otherwise no strongly negative reactions on the new ink-skipping default. 

Communication to downstream teams (782561, 782131) affected by this change could have also gone better. This is a learning for myself and I'll pay more attention to this in changes like this in the future.

Additional comments on the bugs you listed:
  • Dotted underlines skipping (808603, 807343) on fonts extending slightly below the baseline with "Times", I agree this is an issue. We should continue to improve our underline offsets and thicknesses and perhaps consider using subpixel drawing for dotted underlines. However, I don't think this is a major issue in itself, as usage for dotted underlines is comparably low.
  • Issues with "squiggly red" underlines (806553) used in spell-checking not following ink-skipping defaults of CSS underlines: This is an issue that slipped unfortunately since the spell-checking underlines are unfortunately a very different code path, and to my knowledge cannot be styled with CSS.
  • Hangul (793762) is fixed, with the remaining comments as I read them mentioning URLs/links, as above.

Dominik



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/CAObCcUqz4Mv4nX%2BARRVqiL0bUE_8yxaKV6gVpLZy6LmDo1o_bQ%40mail.gmail.com.

Christian Kulenkampff

unread,
Feb 11, 2018, 4:54:09 PM2/11/18
to blink-dev, bolt...@gmail.com, foo...@chromium.org, ko...@chromium.org, e...@chromium.org


Sorry, just found this discussion and wanted to provide an example: 
Making "skip ink = auto" the default breaks the readability of the most important element in the internet. Billions of links become ambiguous and irritating. This feature looks good on certain underlined headers, but as any automatic feature that mimics artistic proficiency it cannot be applied in a general fashion. No sane designer would underline in this way.

I don't know how the new default affects other type systems, but it must be applied to the Latin alphabet with human attention!

Stephen Chenney

unread,
Feb 12, 2018, 9:33:58 AM2/12/18
to Christian Kulenkampff, blink-dev, David Issel, Philip Jägenstedt, Koji Ishii, Emil A Eklund
I honestly have no good sense for how to underline "mining plot" such that the "plot" appears to be part of the same phrase as "mining". Can anyone suggest a well-rendered underline for this case? Abstractly, it's the case of two words where the last letter of the first word and the first letter of the second word both have descenders.

Cheers,
Stephen.

Christian Kulenkampff

unread,
Feb 12, 2018, 5:07:14 PM2/12/18
to blink-dev, cku...@gmail.com, bolt...@gmail.com, foo...@chromium.org, ko...@chromium.org, e...@chromium.org
I think there are many cases where there is simply no good automatic way to underline. For the Latin alphabet I guess thin underlines without "ink skipping" and the offset from the font itself is the best default. At least it should work in most cases. Sometimes it's not that visually pleasing, but still readable without irritation. Underlines are used to style links on many pages, so finding a default that always works is better than a default that looks good in some cases, bad or unreadable in others. The biggest problem are probably diacritical marks, but thinner underlines with a bigger offset will help in this regard. I think this comment might provide interesting information - also the comment beneath:
Note that both Chrome and WebKit (Safari) don’t use underline position from the font, they calculates it on their own somehow (didn’t look in the code to see how exactly it is calculated, though). Firefox uses the underline position from the font, but clips it to the font descender.

How the underlining looks depends on the type face, weight, offset and what characters cross it. Using skip ink as default will not solve the problem, I think it might even add to it.

For example, I don't know the Arabic type system, but looking at the example in the beginning of this thread and at this issue [W3C Arabic Layout Task Force] #86 I have the strong suspicion that skipping ink together with the thick underlines in Chrome makes it more unreadable. The diacritical points just don't work well with the underlines in Chrome. See here: 





I think making the underlines thinner is a good start that might even work with the new default for "skip ink". I don't know how good the default position and thickness for fonts are set in unicode fonts, but maybe using those values will provide the best experience.

I really like the idea of this intent, but I fear its execution is much harder than it might seem on the first sight.

Have a nice week,
Christian

Stephen Chenney

unread,
Feb 13, 2018, 8:51:34 AM2/13/18
to Christian Kulenkampff, blink-dev, David Issel, Philip Jägenstedt, Koji Ishii, Emil A Eklund
Thanks very much Christian for the thoughtful response. It very helpful. I believe our underlines are a fixed thickness and we can make improvements there. I'll also talk to the font folks about extracting the underline height.

Cheers,
Stephen.

Christian Kulenkampff

unread,
Feb 13, 2018, 12:16:27 PM2/13/18
to blink-dev, cku...@gmail.com, bolt...@gmail.com, foo...@chromium.org, ko...@chromium.org, e...@chromium.org
Well actually I was posting, because I was annoyed by the ink skipping. So as an end user I hope I didn't bother you too much and that I didn't overlook a disclaimer regarding the usage of this group.

After reading through the W3C issues again, I think my concerns might be better placed elsewhere. These discussions all seem to have happened already. And despite my suspicion the W3C Arabic Layout Task Force seems to prefer the new behavior:
In any case, if the underline/overline collides with ink, the prefferred default behavior would be to skip the ink.

Cheers,
Christian

Eric Arnol-Martin

unread,
Feb 21, 2018, 12:50:22 PM2/21/18
to blink-dev, cku...@gmail.com, bolt...@gmail.com, foo...@chromium.org, ko...@chromium.org, e...@chromium.org
Looks like this change is experimental.

https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration-skip

You should not change the default underline behavior that has been the way it has been for 30+ years on computers.  I'm sorry, but this change is unnecessary and implemented incorrectly in the latest version of chrome. 

text-decoration-skip-ink: none; should be the default if no style is specified.

PhistucK

unread,
Feb 21, 2018, 12:54:26 PM2/21/18
to Eric Arnol-Martin, blink-dev, cku...@gmail.com, bolt...@gmail.com, Philip Jägenstedt, Koji Ishii, eae
Eric - note that Safari already changed the default (at least according to one of the intents, unless I am mistaken).


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.

Eric Arnol-Martin

unread,
Feb 21, 2018, 4:31:55 PM2/21/18
to blink-dev, earnol...@gmail.com, cku...@gmail.com, bolt...@gmail.com, foo...@chromium.org, ko...@chromium.org, e...@chromium.org
Yes, the change has been made, but I think it's wrong.  I am currently arguing against it in the www-style w3 org mailing list.  I originally filed a bug in Chrome for this as well (though it has since been labeled as "Won't Fix"):

https://bugs.chromium.org/p/chromium/issues/detail?id=813256

Jack who built the house

unread,
Feb 22, 2018, 3:56:13 PM2/22/18
to blink-dev, foo...@chromium.org, ko...@chromium.org, e...@chromium.org
Hi! Take a look at this issue with Cyrillic "д", please: https://bugs.chromium.org/p/chromium/issues/detail?id=813778

вторник, 24 октября 2017 г., 11:38:36 UTC+3 пользователь Dominik Röttsches написал:

Daniel Bratell

unread,
Feb 23, 2018, 8:45:48 AM2/23/18
to blink-dev, Eric Arnol-Martin, cku...@gmail.com, bolt...@gmail.com, foo...@chromium.org, ko...@chromium.org, e...@chromium.org
While not directly involved in this feature, I've noticed that there have been improvements since the initial release. Please take a look at the most recent nightly and see if it's better.

But I have also noticed that while it's apparently a huge improvement for Arabic scripts, it's either unnecessary or look strange for Latin scripts. Personal observation is that descenders in Latin scripts all seem to be mostly long and vertical (well, g and y are not quite so) and work well with underlines. I doubt that is a coincidence, and I guess that is why skip-ink, for Latin scripts, solved a problem that didn't needed solving. I'm sure this has been discussed elsewhere in length.

/Daniel

On Wed, 21 Feb 2018 21:28:59 +0100, Eric Arnol-Martin <earnol...@gmail.com> wrote:

Yes, the change has been made, but I think it's wrong.  I am currently arguing against it in the www-style w3 org mailing list.  I originally filed a bug in Chrome for this as well (though it has since been labeled as "Won't Fix"):

https://bugs.chromium.org/p/chromium/issues/detail?id=813256
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbdbb553-0164-4467-9621-3e1cb8b2b7a7%40chromium.org.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

Artem Russakovskii

unread,
Feb 26, 2018, 7:56:58 PM2/26/18
to blink-dev, earnol...@gmail.com, cku...@gmail.com, bolt...@gmail.com, foo...@chromium.org, ko...@chromium.org, e...@chromium.org
Here's another case that caused unnecessary confusion: https://twitter.com/ArtemR/status/967948895945867265.

Please consider it.
Reply all
Reply to author
Forward
0 new messages