Comment by WiseWeasel | Hacker News Reader

Comment by WiseWeasel | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com