Can Apple redefine the Underline?

Particularly observant Safari users may have noticed something different after upgrading to OS X Yosemite.

Underlines rendered in Safari 8

In case you still can’t spot it, the underline breaks for the descender of the font (the bottom of the ‘g’). Naturally, a small number of apple fanatics have treated this like the second coming of typography*, but should the rest of us care? Probably not much, but it does raise a few interesting questions.

Doesn’t the font include its own underline data?

Yes, fonts often contain some data about how to draw their underline. Both TrueType and Type 1 based fonts contain fields for underline thickness and position. However, in TrueType they’re specified as suggestions and the Type 1 specification has nothing to say about them at all.

In any case, browser rendering engines mostly ignore these fields anyway, resulting in entirely inconsistent results, and they have nothing to say about breaking for descenders.

Does any other specification have anything to say about underline rendering?

Yes. The CSS specification has a whole module for text decoration. CSS 2.1 doesn’t technically forbid breaking for descenders, but this leads us to the really interesting questions…

How and Why have they done this?

The candidate recommendation of CSS 3’s text decoration model has a property called ‘text-decoration-skip‘ which controls when to draw text decorations like underlines and line-throughs. Apple have not only implemented this in Safari, they’ve also added ‘text-decoration-skip: ink;’ to their default CSS in Safari. (The default specified in the specification is ‘objects’.) As far as I know they’re the first to implement ‘text-decoration-skip’.

The relationship between what browsers implement and the stage the relevant document is at is somewhat complex. At ‘Candidate Recommendation’ stage the W3C essentially suggests implementing the feature in the way it will finally appear. Many features arrive long before the Candidate Recommendation stage, which makes this feature somewhat unusual.

Unusual enough, in fact, that a note at the top of the specification states that it’s ‘at risk and may be cut from the specification during its CR period if there are no (correct) implementations’. Well, there is one now!

Will other browsers follow suit?

To some degree, it seems likely, yes. The extra publicity Apple’s non default underline has generated means Mozilla have received a little more pressure to implement it. (Which they’d previously been told by one of the W3C’s editors not to worry about!)

Will they use ‘ink’ as the default value, though? The positive reception in Safari suggests to me that the W3C could even change the default value in the final recommendation. Only time will tell!

Would you like to see it become the default version in CSS 3? Answer in comments below.

If you’re a first-time reader, or simply want to be notified when we post new articles and updates, you can keep up to date by social media (TwitterFacebook and Google+) or the Blog RSS.

Related Posts:

The following two tabs change content below.
Sam is a developer at IDRsolutions who mostly specialises in font support and conversion. He's also enjoyed working with Java 3D, Java FX and Swing. His other interests include music and game design.
SamH

About Sam Howard

Sam is a developer at IDRsolutions who mostly specialises in font support and conversion. He’s also enjoyed working with Java 3D, Java FX and Swing. His other interests include music and game design.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>