1225661 - Apple ID page has odd gradient behind title, with "layout.css.prefixes.webkit" enabled, due to reliance on "-webkit-background-clip: text;"

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Set about:config pref layout.css.prefixes.webkit = true
 2. Visit either of these sites:
   (A) https://appleid.apple.com/
   (B) https://appleid.apple.com/choose-your-country

ACTUAL RESULTS:
 The "Apple ID" title has an odd rectangular gray gradient background.

EXPECTED RESULTS:
 No such background.

Chrome shows EXPECTED RESULTS. So does Firefox with layout.css.prefixes.webkit disabled.

Comment 1

[Daniel Holbert [:dholbert]]

The element in question has the following style applied to it:
  h1 {
    background:-webkit-linear-gradient(#eee, #333);
    -moz-background-clip:text;
    -webkit-background-clip:text;
    -webkit-text-fill-color: transparent;
  }
https://appleid.cdn-apple.com/static/cssj/2022217682/appleid/web-new.css

 * We do not support "background-clip: text" at all (bug 759568), so we render the background across the whole padding-box.

 * WebKit/Blink *do* support "background-clip: text". So they would clip this background-gradient to the text, producing a "shiny" look on the characters themselves.

(TANGENT: In actual fact, this styling has *zero* effect in WebKit/Blink right now, surprisingly.
  At site (A) -- the appleid front page -- *there is no text*.   The "title text" there is actually an image. So, the "text" background-clipping makes the gradient-background get clipped entirely.
  At site (B), the title is actually text, but it just renders as black -- no visible gradient.  It *would* let the gradient shine through, if the "-webkit-text-fill-color: transparent" were honored. But it's not honored, because there's a more specific declaration that sets "-webkit-text-fill-color:inherit" (i.e. black) in the h1's style attribute.)

So, the gradient doesn't show up *at all* on either of these sites, though it's arguably intended to at site (B) and Apple's just got a bug in their styling that's preventing it from working.)

Comment 2

[Daniel Holbert [:dholbert]]

In an ideal world, we could suggest that Apple add
 @supports (-webkit-background-clip:text) { ... }
around this rule.

However, http://caniuse.com/#search=%40supports shows that iOS Safari 8.4 (reported there as 1.75% market share) doesn't recognize @supports at all. So those users would stop seeing this gradient effect, on any pages where the gradient effect actually works correctly. (though ites (A) and (B) here would remain unchanged, per tangent in comment 1. Not sure if there are other sites where this actually does what it's supposed to.)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot of "choose-your-country" in Firefox vs. Chrome vs. Chrome with transparent text

Here's a screenshot showing how Firefox (top left) & Chrome (bottom left) render the AppleID "choose-your-country" page.

Bottom right shows Chrome with "-webkit-text-fill-color:inherit" disabled in the inline style rule, so that the text ends up transparent & this gradient actually has a chance to be shown through the text that it's clipped to, per -webkit-background-clip:text. (Not sure whether that is Apple's intended look or not.)

Comment 4

[Daniel Holbert [:dholbert]]

So, our options here seems to be:
 (0) Make this work, in Gecko -- i.e. implement [-webkit-]background-clip: text (bug 759568).  This seems unlikely to happen (at least, with this particular syntax), since there's currently no spec, and the CSSWG (or Tab at least) says this particular abuse of "background-clip" is "the devil" & the wrong way to get this particular effect. Reference: https://lists.w3.org/Archives/Public/www-style/2012May/1228.html

 (1) Reach out to Apple & ask them to remove this h1 {...} rule, since it seems to be effectively unused AFAIK (i.e. it's blocked from having any effect in WebKit, as noted in comment 1's "TANGENT").  There may exist other sites Apple that use this same stylesheet where this rule does get actually used, though I haven't noticed any from clicking through Apple's site menus for a few minutes.

 (2) Reach out to Apple & ask them to wrap this h1-rule in a @supports condition, per comment 2.  If there do exist sites which actually use this h1-rule effectively [not sure], then this remedy would give old-iOS Safari 8.4 users a slightly degraded experience (solid-color h1 text) on those sites, since their browser won't recognize "@supports" at all. Not sure how much anyone cares about that. (Surely nobody cares, if it's not actually used effectively on any sites.)

Comment 5

[Daniel Holbert [:dholbert]]

(Reclassifying as Tech Evang, since of our options in comment 4, the Tech Evang ones are the most viable.)

Comment 6

[Daniel Holbert [:dholbert]]

Actually, since we've discovered more sites that are affected (dependencies of bug 759568), we'll probably have to fix this in Gecko, i.e. option (0) from comment 4.

(The fix will happen in bug 759568. Marking depencency.)

Comment 7

[Daniel Holbert [:dholbert]]

Resolving this as FIXED in Nightly by bug 759568.

(The second URL in comment 0 still shows the problem, **if** I manually turn off "layout.css.background-clip-text.enabled".  And then the problem goes away when I set that pref to its default "true" state and reload. Hooray! The first URL doesn't show any problems anymore, regardless of that pref, so that page must've been rewritten since this bug was filed.)

Actually, the first URL from comment 0 no longer reproduces the problem at all -- but the second one still does if I disable