It's a very nice idea — I always like smartening up the look of the Web — but the resulting links are ghastly. If your word starts or ends with a descending letter (e.g. "ghastly"), then the underline looks like it omits the first and last letters. It breaks the semantics of what the underline means — any bit that's underlined is supposed to be the link, and if it's not underlined it's not a link.<p>They also made the mistake of showing a link that includes the word "Typography", which has an underline so broken up and interrupted that it's distracting (which devindotcom also pointed out). It's linked, then it's not, then it's linked, then it's not!<p>So yeah, I have to give them credit for a good idea and a clever implementation, but it just doesn't work out in the end.
To me, it actually adds visual complexity while eliminating the useful visual cue of a single line being a single link. Here, there are many lines, which to me indicate many links. In some cases, the line may present as dotted or dashed (the word "piggy" randomly came to mind) — things that signify something other than a link to me.<p>I would rather descenders weren't subsumed by the line either, but interrupting the element itself instead seems like as much as a problem as it is a solution.
In order to more accurately compare iOS 8 Safari’s text-decoration underline implementation to SmartUnderline, I created a test page. [1] It contains five links to the words gesture, quitting, discovery, piggy, and eager, set in Helvetica.<p>To produce the iOS 8 version, I opened the page in Safari on iOS 8.1 pinched zoomed to the maximum amount while keeping all five links within the frame, and took a screenshot.<p>To produce the SmartUnderline version, I visited the SmartUnderline install page [2] in Google Chrome on Mac OS X, entered the test page URL, and clicked “Preview in a separate window”. With the screenshot from my iPhone opened next to the browser, I used Command+[+/-] to zoom the browser until the font sizes were the same size, then took a screenshot.<p>Here are the results: [3].<p>To summarize, I believe iOS 8 has some advantages and some disadvantages, but to me there is no clear winner.<p>Some specific points in no particular order:<p>- iOS underline breaks are always vertical cuts. Since SmartUnderline uses text-shadow to “white-out” the underline, the cut-outs are in the shape of the glyph. To me, this looks better in the “g” in “eager”, but worse in the “q” in “quitting”.<p>- iOS 8 shows a line between a “g” and ”y” (as in ”piggy”) and SmartUnderline does not.<p>- SmartUnderline’s underline extends less far to the left of the first letter and right of the last letter. This looks better in “quitting” and potentially worse in ”discovery”.<p>- In general, SmartUnderline sets a little more space around each descender.<p>- Both implementations show no underline before or after a leading or trailing “g”.<p>- Both implementations show the underline very close to the left side of the “y” descender. I think improvements could be made here with both implementations.<p>[1]: <a href="http://jsfiddle.net/adamschwartz/hyyerbq4/show/light/" rel="nofollow">http://jsfiddle.net/adamschwartz/hyyerbq4/show/light/</a><p>[2]: <a href="https://eager.io/app/eA9ULux0UOJP/install" rel="nofollow">https://eager.io/app/eA9ULux0UOJP/install</a><p>[3]: <a href="http://postimg.org/image/nf9b2ahd1/" rel="nofollow">http://postimg.org/image/nf9b2ahd1/</a> (@2x <a href="http://postimg.org/image/688ricy2v/" rel="nofollow">http://postimg.org/image/688ricy2v/</a>)
This kind of underline painting behaviour is proposed in <a href="http://dev.w3.org/csswg/css-text-decor-3/#text-decoration-skip-property" rel="nofollow">http://dev.w3.org/csswg/css-text-decor-3/#text-decoration-sk...</a> as text-decoration-skip:ink. Not yet implemented anywhere though.
Neat, though I don't actually think I like the look of it. I think I'd rather have an underline further down, so that it's below the descenders.
<i>> First we define a helper mixin textShadowToCropUnderline which draws 12 text-shadows, half to the left, half to the right, spaced every .03em.</i><p>This seems like a big waste of CPU and memory. I don't want to drain my phone's battery rendering these underlines.
I had seen this effect about two years ago on the website of Roman Komarov and was impressed by it at the time: <a href="http://kizu.ru/en/fun/" rel="nofollow">http://kizu.ru/en/fun/</a>
While I admire the attention to detail, it is all in vain for me. I much prefer the simplicity of a solid line to the awkward fragments dodging descenders. My brain continuously tries to make sense of the incomplete line, and some words no doubt will add to the confusion with long stretches of characters having minimal expression of the underline.<p>Case in point, the word giggly has what appear to be specs of dust underneath.
Why limit yourself to just underlining links? Why not some other convention? I played around with this a bit over a decade ago: <a href="http://www.conman.org/people/spc/writings/hypertext/fragment/" rel="nofollow">http://www.conman.org/people/spc/writings/hypertext/fragment...</a> (note: In the twelve years since I wrote that, most of the links offsite are now dead, which is another issue with links).<p>At first, the links in the "fragment" are invisible. You can toggle among that, single angle quotes (not used in English, which is why I picked that option), small bullet points on either end, and the default HTML underline.
The library's showcase page has the key bits imo:<p>> - It makes an assumption about selection color, which is OS- and browser-dependent.<p>> - Each smart-underlined link has 12 text-shadows drawn underneath it, which could potentially have performance penalties on mobile or older devices.<p><a href="https://eager.io/showcase/SmartUnderline/" rel="nofollow">https://eager.io/showcase/SmartUnderline/</a><p>(Imho, the two points introduce enough risks and reasons to not use it and wait for OS- or browser-level updates instead.)
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?
This example shows once again that CSS is not a good declarative language: it provokes hacking. In this case, a hack has to be applied in every instance where this is needed.<p>Instead, if CSS were developed by actual language designers, it would have been possible to write this as a modularized thing, completely hiding the actual implementation.
Aside from the many other criticisms raised in the comments, this seems like something of a deal-breaker to me: "It requires that the text be on top of a solid background color."
That's nice in theory, but it's also yet another example of Apple innovating and getting it right, and people implementing a quick copy without going through nearly as much <i>necessary</i> design thinking as Apple did. The end result is that only Apple's implementation is better than the default one. Of course I'm not blaming you personally for that, I mean, even Microsoft has fallen prey to this phenomenon (and on a vastly larger scale). But it would nice if people were more observant.