adamschwartz

Wow, thank you! If there’s anything we can do to improve it please let us know.

Thanks! We really appreciate that.

Thanks so much!

Here are some of the other targets that are on deck: https://git.io/vi8IK.

If there are any others not on that list you’d like to see added, please let us know or create an issue on GitHub. Thanks again!

See my comment above [1]. I think you’ll find that the iOS 8 and SmartUnderline implementations are closer than you think.

[1]: https://news.ycombinator.com/item?id=8588492

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

See my comment above [1]. I think you’ll find that the iOS 8 and SmartUnderline implementations are closer than you think.

[1]: https://news.ycombinator.com/item?id=8588492

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.

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.

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.

Here are the results: [3].

To summarize, I believe iOS 8 has some advantages and some disadvantages, but to me there is no clear winner.

Some specific points in no particular order:

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

- iOS 8 shows a line between a “g” and ”y” (as in ”piggy”) and SmartUnderline does not.

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

- In general, SmartUnderline sets a little more space around each descender.

- Both implementations show no underline before or after a leading or trailing “g”.

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

[1]: http://jsfiddle.net/adamschwartz/hyyerbq4/show/light/

[2]: https://eager.io/app/eA9ULux0UOJP/install

[3]: http://postimg.org/image/nf9b2ahd1/ (@2x http://postimg.org/image/688ricy2v/)

In our tests (scrolling an older iPhone on a page with 300 links), we found that it’s actually not as much an issue as you might think, particularly because none of the shadows use a spread value. I’d definitely be interested to see if you have evidence to the contrary.

That being said, it’s definitely something worth considering, particularly since iOS 8 now implements descender-aware link underlines now. If there were a way to duck type for this feature, we’d definitely disable the JS anywhere we detect it working. Drawing an underlined “g” on a canvas and then reading the pixels at a certain location may work, but we haven’t tried it yet.

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

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

Thanks for the suggestion. We’ll be taking a crack at descender-heavy links [1], so this may come in handy!

[1]: https://github.com/EagerIO/SmartUnderline/issues/1

I appreciate your feedback. No doubt on some level this comes down to aesthetic preference. I’m curious though, on the before-and-after examples on the homepage [1] do you feel that all of the afters are worse?

You and devindotcom did indeed bring up some good points, particularly about descender-heavy links, something I plan to take a crack at [2]. But I’m curious if you feel the entire strategy is flawed or if there’s just more work to be done. On a related note: if you’ve used/seen it, how do you feel about links in iOS 8 Safari? How do you feel about this before-and-after [3] (screenshot of the first paragraph of the blog post)?

[1]: https://eager.io/showcase/SmartUnderline/

[2]: https://github.com/EagerIO/SmartUnderline/issues/1

[3]: http://postimg.org/image/rgfx5icq9/

I appreciate your feedback. There are always ways of improving something, even in the case of Apple’s implementations.

Are there particular aspects of this implementation you feel make it worse than Apple’s?

Ultimately we see this as an incremental improvement to the default text-decoration underline styling provided by most operating systems and browsers. However, we’re eager to work with OS community to improve this even further. Thanks again!

This choice came down to typographical best practices. Butterick, a well-respected typographer, recommends in Practical Typography not using underlines for stylistic emphasis. [1]

[1]: http://practicaltypography.com/underlining.html

I think this is a very reasonable criticism, particularly about words like “piggy”—no doubt typography is *ing hard.

Like is often the case with design, there are trade-offs. In this case I think the readability improvements to links with descenders outweighs the visual cue / scannability of links, particularly because I think links with more-descenders-than-non are not as common.

An interesting experiment might be to try to turn off the effect on words which fail some check (a high percentage of descender glyphs, for example). I created an issue on GitHub [1]—definitely something worth exploring. Thanks!

[1]: https://github.com/EagerIO/SmartUnderline/issues/1

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

I really like how he applies the styles on hover. I wanted to do something like that with SmartUnderline but unfortunately there is no way to call getComputedStyle with the :hover pseudo-class applied. (This is necessary because SmartUnderline only applies to links which have text-decoration underline.)

Traversing the enter style ruleset is possible but didn’t seem worth it for a library like this.

Another way is through a configuration option. Something like `SmartUnderline.init({ '.content a': 'hover' });` perhaps.

Thanks!

Ha! Yeah, my co-founder and I debated that one... (he thought I should reverse it). I can see it both ways, but your comment certainly puts another vote in the reverse-it column. Thanks again :)

No doubt, at a certain point it does come down to aesthetic preference.

Using a border-bottom to achieve the look you’re describing is totally a valid preference. One potential advantage to the border-bottom technique is the way it can be used to make a link stand out. In fact, I use this link styling on my personal website for that reason [1].

(Note: when using a border-bottom, I’d recommend using a slightly larger line-height so that the line still seems associated with the text above it and not the text below it. This is one of the pitfalls described in the original Medium post [2].)

Unfortunately, aside from iOS 8, normal text-decoration underline links have the descender crossing problem.

I absolutely took this into consideration when designing SmartUnderline. SmartUnderline literally only applies itself to links with text-decoration underline, nothing else. It even tries to ensure other conditions which make the transformation favorable (display inline, solid background color, etc.).

Ultimately I think the before-and-after on the SmartUnderline website tells the best story [3]. No doubt one may appreciate other, very different link styles. (For example, just using a different text color to denote _link_ is a perfectly valid and commonly used technique.) But if you’re using text-decoration underline already, this just makes those links look better.

I think blogs, news articles and wikis are some of the primary examples of where these links look best. Anywhere where text is heavy and the links are _not_ the primary focus.

[1]: http://adamschwartz.co

[2]: https://medium.com/designing-medium/crafting-link-underlines...

[3]: https://eager.io/showcase/SmartUnderline/