Open Bug 1574641 Opened 5 years ago Updated 5 years ago

Pocket-hosted articles have a weird double-underline at some resolutions/zoom-levels, which can look extra-broken with "text-decoration-skip-ink"

Categories

(Pocket :: getpocket.com, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: cpeterson, Unassigned)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(2 files)

[Tracking Requested - why for this release]:

This is a visual regression in Firefox 70 from bug 1572800. I bisected to the following regression range using mozregression:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9ae108bb86e2c93d9d74f43cfa8f39a9e84cc8b2&tochange=91ae5f60b8c081767422e8bf9bb88d666ff204b3

STR

  1. Load https://getpocket.com/explore/item/why-schools-are-banning-yoga
  2. Look for a link in the article text, such as "teacher-training courses".
  3. Look at the link's underline style.

Expected Result

The links should have a double underline, like Firefox 69, Chrome, and Edge.

Actual Result

The link text overlaps one of the double underlines, making the underline looked dashed. See the attached screenshot comparing Firefox 68 and 70.

The site is using some weird styling, with a background-image on the <a> elements to create a "fake" underline, but then also wrapping them with a <u> element that provides its own separate underline. On my mac with retina screen, the two lines have different thicknesses, and look pretty bad even before skip-ink comes into play.

The webfont they're using (https://assets.getpocket.com/web/fonts/BlancoWeb-Regular.woff2) has bad underline data in its 'post' table: it specifies an underlinePosition of zero, which puts the underline exactly at the baseline of the glyphs, so naturally it then ends up skipping.

So this is a combination of a defective font resource and some unwise authoring. If fixing the font isn't feasible, they could at least use text-underline-offset and text-decoration-thickness to control the "real" underline so that it better matches the fake one produced using background-image, and doesn't actually touch the glyphs.

(I don't think they were really trying for a double underline at all. In Chrome, the "real" and "fake" underlines overlap so it appears as a single line, although the effect around the glyph descenders is a bit weird. In Safari, it's double, and the behavior on hover is kinda strange.)

Can we ask whoever is responsible for getpocket.com to do something about this? It's not really a Firefox bug; AFAICS the browser is behaving correctly given the CSS involved and the (bad) data in the font here.

Component: Layout: Text and Fonts → Other
Product: Core → Websites

(In reply to Chris Peterson [:cpeterson] from comment #0)

Expected Result
The links should have a double underline, like Firefox 69, Chrome, and Edge.

(In reply to Jonathan Kew (:jfkthame) from comment #1)

(I don't think they were really trying for a double underline at all.

FWIW: On Ubuntu on my 200%-HiDPI laptop, no browser that I've tested shows a double-underline at the default zoom level. (I tried Chrome, Firefox 68, and Firefox Nightly 70). I do see a double-underline in both Chrome and Firefox if I add some full-page-zoom, but I don't think that's an intentional thing that the page is trying to go for.

Here's a screenshot showing similar artifacts in Chrome on Ubuntu (with OS-level 200% HiDPI scaling, plus 300% full-page-zoom in the browser).

I brought this up in the slack #pocket-questions channel, and apparently some folks who work on Pocket syndication have been notified and they're going to take a look.

Summary: Link underline visual regression from text-decoration-skip-ink → Pocket-hosted articles have a weird double-underline at some resolutions/zoom-levels, which can look extra-broken with "text-decoration-skip-ink"

Tracking this in Pocket's JIRA: https://getpocket.atlassian.net/browse/SYND-217

Component: Other → getpocket.com
Product: Websites → Pocket
Target Milestone: --- → 1.0
Version: unspecified → 1.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: