I'll check what Safari does for links with protocol specifiers, colon and double-slashes, and slashes in general.
In a bug tracker links with protocol specifier, colon and double slash appear more frequently than in general, so one possibility would be that Monorail styles links in the issue comments as text-decoration-skip-ink: none; if that is preferred.
It looks like:
- Safari has smaller gaps horizontally.
- Safari has even smaller gaps (no gaps?) vertically, so that underscores rarely intercepts, even for fonts that underscores touch the underline.
That might make URLs to look better.
Take Safari's implementation with a grain of salt. There are some rounding errors where the underline disappears and reappears with different zoom levels. I'd imagine we'd want this to be stable at all zoom labels.
Looking at various results for the monospace kind of bugtracker links, including the http(s):// protocol specifier and slashes / paths in links:
Slashes are not causing underline gaps on Android and Mac. In fact, Safari and Chrome Canary on Mac look pretty similar. They do start to cause gaps at large font sizes.
On Windows, monospace maps to "Consolas", in which the slashes extend below the baseline and will cause gaps in the underline. If the font is changed to Courier New, the slashes do not cause ink skipping.
On Linux, the monospace font is DejaVu Sans, which has low slashes, and ink skipping is invoked.
I am attaching a set of screenshots for illustration.
The behavior is font specific because we compute the placement of the underline based on font metrics.
Underline placement varies between browsers: We've tried to change the automatic underline placement and thickness before and move it closer to using values from the OpenType information in the fonts, however that information is often garbage and leads to other breakage so those changes were reverted.
The discussion in the CSS working group resulted in defining two new properties: text-decoration-width and text-underline-offset for controlling the underline distance from a baseline, as well as underline thickness.
I believe the best thing we can do here is give authors additional control with the new CSS properties for text-decoration-width and text-underline-offset.
Alternative approaches like:
a) Reverting the change: I am reluctant to that, as it a) generally improves readability for "non-technical links", i.e. plain text links that do not have protocol specifiers and slashes in them. Compare the reasoning and image in the Intent to Ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/47BHtmz0jVY
It also improves interoperability between browsers, since the text-decoration-skip-ink: auto; initial value is part of CSS Text Decoration Level 4. Safari has been shipping ink skipping as a default since Safari 8.
b) Content inspection, e.g. checking what kind of content is inside the <a href="..."> (check here) </a> and apply styling conditionally. This is probably not feasible from a performance point of view and difficult to spec.
Concluding, I would recommend we implement the additional underline control CSS properties, which would address our previous underline positioning and thickness issues at the same time as it would authors give control to avoid underline gaps for links containing slashes by increasing the underline distance.
hi - thanks for your analysis, do you have any studies that show that this change 'generally improves readability for "non-technical links"'? Perhaps this discussion is best on the intent to ship rather than here, I'm happy to move it there.
No, I do not have such a study. I did receive feedback from several typography experts who appreciate and prefer the change, and I also see a highly positive response to this change in the design community, including the Chrome UX team. A Github discussion among internationalisation experts and contributors familiar in Arabic also see benefit in ink skipping underlines in Arabic script.
Besides that, using the auto value for text-decoration-skip-ink: improves interop: Safari has been shipping this for years. The spec discussion has resolved in auto as initial value for this property.
Just curious: Were the typography examples evaluated in the context of URLs? I can see this being fine for regular underlined text.
Is there other additional data besides Safari being used as the bar? Does this help or distract current Chrome users?
I think the issue is where it just looks weird, i.e. underscores and slashes or punctuation where it breaks up the underline. I think these edge cases would need to be resolved before this ships to stable, otherwise I think user reaction could be quite... polarized.
There's another issue, which is that this breaks the (until now) invariant that separate underlines mean different links. Now I find myself spending some amount of (sub-second) time wondering, e.g., which side of a "g" I should click on to get the link I want. It's particularly a problem for anchor text containing commas, since "foo, bar, or baz" can be done as one link or three, and the distinction between these two cases is a lot less clear than it used to be.
Safari’s algorithm looks much better than Chrome’s, as the gaps it produces are thinner, are subpixel-antialiased, and work better with e.g., the descender of “y”.
I would like to second #13: This really annoys me because it makes harder for me to identify "a link" when it is broken into parts that look visually like separate words.
I believe links are the most common place where underscores are used on the web, so I believe this makes Web typography worse on a big scale - can we leave this off by default, and instead let web designers enable it where it makes sense if they really care (e.g. titles in a blog post)?
Here's an example from GMail where it looks bad even with non-URL characters. It's harder to identify that there are 2 relevant items for me in this email.
Thanks for the investigation in #7. I understand there's font-specific differences, but comparing Roboto as used by Gerrit I see different behaviour across platforms too, which seems like it will be quite awkward for authors.
As a specific example, looking at https://chromium-review.googlesource.com/c/chromium/src/+/891447 on Canary Mac, it looks quite nice, as neither the / nor _ break the links. (attached)
On Dev Linux, it's pretty bad though, as both do break the links which makes the text look very jumbled. (second attachment)
Do we have the ability to do platform & font-specific hacks to make these common fonts look nicer by default?
Re #24, Scott, what are the device pixel ratios for the Mac Canary and Linux desktop you're comparing? I believe the platform difference are due to differences between Retina device pixel ratio and your Linux monitor's device pixel ratio, which influences underline thickness and positioning.
If I open the link to your CL [1] on Linux, I see the same as in your screenshot. If I magnifiy to 110%, the slashes and underscores do not trigger the descender skipping anymore.
[1] https://chromium-review.googlesource.com/c/chromium/src/+/891447
What we can try for improving the underline placement: Move to using underline thickness and distance values from the fonts again, instead of using a "one size fits all" approach, as we do now (compare #7 for reasoning), and start maintaining a blacklist of fonts that have garbage underline metrics.
We should do that not without providing a means for authors to control the placmement with CSS as well thought, through text-decoration-width and text-underline-offset.
I think you're probably right that the dpi is relevant. I believe the Mac is 2x (whatever the default setting for an older 15" MacBook Pro). On Linux `xrdb -query | grep dpi` reports 144, so I assume that means 1.5x.
Stinky!
FWIW, doing the opposite (zooming out on Mac) doesn't make it repro there.
I also don't know how common 1.5x is, I thought might be pretty common as the default dpi for a large-ish 4k monitor on Linux & Windows Desktop, but I don't know if we have any metrics on that.
In Windows I am seeing something similar recently but I don't see text-decoration-skip-ink set. In Yahoo Mail webmail the underline in the links is broken up for every slash /, see attached.
I bisected it but the resultant range is 200+ commits.
Bisect info: 514027 (good) - 514238 (bad)
https://chromium.googlesource.com/chromium/src/+log/04e78cc6..8535de60
04e78cc6 is 64.0.3259.0
8535de60 is 64.0.3261.0
Maybe this:
cc22f53 Text-decoration-skip to text-decoration-skip-ink with initial value auto by Dominik Röttsches · 3 months ago
If what I'm describing is different from what is discussed here, please let me know so that I can open a new issue. Thanks
Local experimentation shows, even with more closely aligning the underlines based on font metrics the underline splits for slashes still occurs for Roboto on device pixel ratio 1 and 1.5 at the Gerrit sizes.
kojii@ and I discussed that exempting slashes and underscores from ink skipping might be a reasonable compromise.
Uploaded https://chromium-review.googlesource.com/c/chromium/src/+/897663
I am curious to hear your opinions on this approach.
Again I'm not sure if this is the same thing but here is a combined screenshot of before and after the break in the links. My opinion is exempting anything from the underline is not as intuitive as a contiguous line for the whole link.
The screenshots were taken with --disable-remote-fonts (ie Arial is shown) from https://daniel.haxx.se/blog/2018/02/01/reducing-2038-problems-in-curl/
Deleted:
Chrome Link Underline Comparison.png
20.4 KB
I'm not sure why we are still posting regression windows and screenshots, as it's already clear at #1 where this change comes from (and it's a deliberate change).
(I'm not saying we shouldn't discuss or change this behavior since it's indeed a controversial change, just that we don't need to repeat the known information.)
I'd kindly ask to get this merged to M65 due to the attention and intense discussion this triggered internally and publicly. I consider the change itself safe to merge to Beta.
This bug requires manual review: M65 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
I would prefer to merge to M65, as there were a number of quite vocal responses to this issue, but I see that we're late in M65, so I'd leave it up to you.
Comment 1 by wfh@chromium.org
, Nov 13 20175.3 KB
5.3 KB View Download