Hacker News Reader

Comment by WiseWeasel | Hacker News Reader

This seems like something user agents should apply to all 'underline' text-decoration by default in order to improve readability. Is there any reason not to?

View on HN

iOS8 Safari agrees with you. :) (As do I fwiw.)

Unfortunately I imagine this is easier-said-than-done and may have to do more with the underlying typographical engines of OS-s than browsers. (I’m just guessing though.)

Ah, an excellent point. The TrueType font format apparently does specify an underline position and height [1], though there's no mention of any allowance for this descender-dodging feature. The fact that font formats defer the actual drawing of the underline to the renderer gives me some hope. This seems to highlight the issue of web browsers having different font rendering needs from other apps, since underlining is so much more prevalent.

[edit] Obviously, it's a lot easier to fix this issue with a single font, as Apple has done in Messages, than to fix it well in every font.

With regards to this implementation, I'd rather not have to worry about the background, font and select background colors for every link. Applying text shadows over gradient-drawn underlines is an inspired hack that I'll have to remember, just in case, but I really wish there were a better way.

Maybe we should push for a 'text-mask-underline' CSS property that accepts radius, hardness and opacity values, in order to apply a fade to the underline around text descenders. [/edit]

[1] http://fontforge.github.io/fontinfo.html, http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=...

Thanks for that information re:TrueType! My knowledge of these things tends to end at the browser, but I too hold hope for better type in future OS-s.

The fact that Apple decided to tackle this on iOS, an OS used on handheld devices which are typically viewed at closer distances, tells me that it’s something they feel is worth doing when you have the display resolution to do it right.

SmartUnderline makes a similar assumption, not applying itself to links with a small-enough font-size computed style.

With respect to your [edit] block:

> Obviously, it's a lot easier to fix this issue with a single font, as Apple has done in Messages.

Apple has implemented this throughout iOS 8, not just in Messages. Here’s a screenshot of Safari [1].

> I'd rather not have to worry about the background, font and select background colors for every link.

That’s actually the beauty of SmartUnderline. It figures all of these things out for you, automatically [2]. Please let us know if you run into any trouble though. :)

[1]: http://postimg.org/image/4ncgrezxr/

[2]: http://git.io/9YNfgg

Re: [2], nicely done! For a dirty hack around browser limitations, it is well implemented. It's a good thing gradient backgrounds behind text are out of style. : P

Thanks!

If a background-image is specified, we abort [1]. (This would apply to CSS gradients as well.) Of course we’d like to support non-solid backgrounds at some point, but short of a true HTML-to-canvas solution, there’s not really that much better you can do without wreaking lots of havoc.

[1]: http://git.io/1WqsAA, http://git.io/n4tRrw

Is this only getting the first container's background? If so, what happens when a layer below that has an image or gradient bkg?

Nope, it traverses up the DOM until it finds an element which has any non-transparent background. If the first thing it finds has a background-image, it aborts. If it’s a solid color, it returns that container. [1]

This absolutely still is prone to bugs when `position` or other properties are used to move elements visually outside of their parents, but it’s about as good as you can do without a true HTML-to-canvas implementation.

[1]: http://git.io/ChvO3Q

I can think of one reason not to: This hinting belongs in the font file itself. I don't agree with hacks to the font being done outside the scope of the source.

A few issues with that; 1) I've only been able to find evidence that font formats specify underline position and height, and leave the drawing to the renderer, and 2) most fonts were created with a desktop publishing context in mind, and 3) the web context has significantly different needs. I think there's a good case for making this change for the font renderer used in web browsers.

The point is that if ligatures are used for this, no modifications to the font rendering front end is needed. Its already there - you just need to use the feature. The way to do that is with ligatures in your text..

That's not what ligatures are for; ligatures are for joining two adjacent letters. I don't believe font formats support this descender dodging feature for underlining, hence the need for the renderer to take charge.

Well, I would argue that using a ligature to establish the alpha gap around the lettering is a better use than hacking up a non-standard feature to the renderer. The gaps are attachments to the type, so ligatures are appropriate - since they would be used in this case to join/split the underline - which itself could be argued is a ligature, per-face, also.

Reply on news.ycombinator.com