4 ms·

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

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.)

WiseWeasel 12y ago
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://fontforge.github.io/fontinfo.html, http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=IWS-Chapter08#05931f9d http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=...
- adamschwartz 12y ago
  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/ http://postimg.org/image/4ncgrezxr/ [2]: http://git.io/9YNfgg http://git.io/9YNfgg
  - WiseWeasel 12y ago
    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
    - adamschwartz 12y ago
      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/1WqsAA, http://git.io/n4tRrw http://git.io/n4tRrw
      - WiseWeasel 12y ago
        Is this only getting the first container's background? If so, what happens when a layer below that has an image or gradient bkg?
        adamschwartz 12y ago
        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 http://git.io/ChvO3Q

WiseWeasel 12y ago

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://fontforge.github.io/fontinfo.html, http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=IWS-Chapter08#05931f9d http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=...

adamschwartz 12y ago
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/ http://postimg.org/image/4ncgrezxr/ [2]: http://git.io/9YNfgg http://git.io/9YNfgg
- WiseWeasel 12y ago
  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
  - adamschwartz 12y ago
    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/1WqsAA, http://git.io/n4tRrw http://git.io/n4tRrw
    - WiseWeasel 12y ago
      Is this only getting the first container's background? If so, what happens when a layer below that has an image or gradient bkg?
      - adamschwartz 12y ago
        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 http://git.io/ChvO3Q