W3C home > Mailing lists > Public > www-style@w3.org > February 2018

Re: text-decoration-skip-ink auto should continue past behavior - 30+ years of underline behavior changed by latest CSS draft

From: Gérard Talbot <www-style@gtalbot.org>
Date: Mon, 26 Feb 2018 20:45:03 -0500
To: Allan Sandfeld Jensen <kde@carewolf.com>
Cc: "Myles C. Maxfield" <mmaxfield@apple.com>, W3C www-style mailing list <www-style@w3.org>
Message-ID: <aed5895307e766b6f940ec4f8ef86d82@gtalbot.org>
Le 2018-02-26 18:47, Allan Sandfeld Jensen a écrit :
> On Mittwoch, 21. Februar 2018 20:07:43 CET Gérard Talbot wrote:
>> Le 2018-02-21 12:27, Myles C. Maxfield a écrit :
>> >> On Feb 21, 2018, at 9:22 AM, Myles C. Maxfield <mmaxfield@apple.com>
>> >>
>> >> wrote:
>> >>> On Feb 21, 2018, at 7:33 AM, OwN-3m-All <own3mall@gmail.com> wrote:
>> >>>
>> >>> I initially thought this was a problem with Chrome (since they seem
>> >>> to
>> >>> be one of the early adopters - bug report here:
>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=813256#c2), but
>> >>> now that I've seen the actual spec, I'm shocked that the auto value
>> >>> for the text-decoration-skip-ink property is to change the way
>> >>> underlined text has worked since the beginning of computers!
>> >>
>> >> Yep. This change is intentional.
>> >>
>> >>> https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-ink-prop
>> >>> erty
>> >>>
>> >>> Underlined text should always have the line over all characters.
>> >>
>> >> Nope. This is how computers have historically rendered text.
>> Glyphs with descender parts (eg. pqjgy) must overlap an underline
>> decoration according to CSS 2.x:
>> CSS Test: 'underline' decoration painting order and descender
>> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/painting-order-un
>> derline-001.htm (you need to download
>> https://www.w3.org/Style/CSS/Test/Fonts/Ahem/
>> and install Ahem font
>> AHEM____.TTF  2017-01-31 20:55   22K
>> to view that test)
>> > However, historically, most high-typographic-quality examples which
>> > include underlines make the underlines skip over the descenders.
>> >
>> > Or, stated differently, underlines cross descenders in existing
>> > software because it was convenient for software authors writing code.
>> > However, we’ve done research in underlines through the ages (way
>> > before computers were invented) and the best typographical samples
>> > always use skipping underlines. This is a situation where changing
>> > behavior on the Web doesn’t break content
>> If textual links have descenders (or a blank space), then it may look
>> like there is 2 links and not 1 link. On 1 hand, it will be easier to
>> read  (typographically speaking) the textual link but it may confuse 
>> the
>> user (or lead him/her to hesitate) in thinking that there are 2 
>> textual
>> links.
> Those two arguments really should end the discussion right here. It is
> documented CSS 2.x behavior and it is confusing for users given 
> existing
> behavior.
> As I see it the only way we can have the underline skip the descender 
> and not
> look like two links is by making the skipped part very short,

This is the case too. The skipped part is very short, I would say. At 
least, when I view pages with Chrome 64.0.3282.119.

Netscape 3.77 also used to skip descenders. Look closely for the words 
or strings "@phoenix", "..Message", "@clearphone", "Pages" in the image:


So, this makes 4 browsers so far: Mosaic for Mac, Viola, Erwise, NS3.77 
were all skipping descenders.

> that is
> underlining a glyph partially, but that would require font support and 
> would
> in that case be a matter of the font dictating how it is to be 
> underlined and
> no longer a CSS matter.
> Note also that some fonts have and underline position below the 
> descenders
> which makes the skipping even worse.

According to CSS2.x, the underline position may (or may not) be provided 
by the font metrics of a font but there is no requirements from CSS2.x 
to apply the underline position if such information was provided by the 

For the same font type, browsers can differ with regards to thickness of 
the underline and can also differ for the exact position of the 
underline. There are no requirements with regards to these from CSS2.x 
and CSS3 Text decoration.

As you can see in this image [1]


Chrome's underline is rather thick.
Safari's underline is close(er) to the baseline (or to what we call the 
foot of the font).
Firefox's underline is thinner and lower than Safari.

So, some fonts may have the underline position below descenders but we 
already know that the underline with the same font can differ for 3 
mainstream browsers with regards to position and with regards to 

[1]: I take no credit for such image; credit should go to Marcin 
Wichary, author of the article
"Crafting link underlines on Medium", March 18th 2014


> Regards
> 'Allan
Received on Tuesday, 27 February 2018 01:45:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 27 February 2018 01:45:45 UTC