Closed Bug 1248785 Opened 5 years ago Closed 5 years ago

Disable webkit-prefixed gradient support, if we see "-webkit-background-clip: text" anywhere in the same style rule

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox47 --- affected

People

(Reporter: dholbert, Unassigned)

Details

MOTIVATION/BACKGROUND:
======================
Probably the biggest visual regression from webkit-prefixed CSS support right now is stuff like bug 1238527 and bug 1248644. This comes from CSS that looks like this (taken from bug 1238527):
{
  color: #f0c0e5;
  background: -webkit-linear-gradient(0deg, #dca2ef, #ffd2df);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
}

* In Firefox release (without webkit-prefix support), this renders as pink text (because we honor the "color" and nothing else).

* In Firefox Nightly, this renders as a pink background-gradient with pink text on top of it. (because we honor the "color" and "background", and nothing else)

* In Chrome, this renders as pink text whose color changes slightly (because it honors all of the above-quoted declarations -- aside from 'color' which gets overridden -- and clips the background-gradient to the text).

This is more complicated at the bloomberg example (bug 1248644), which looks OK in Firefox release, but looks gross with any webkit emulation unless we support the styles quoted above *as well as* -webkit-text-stroke (bug 1248708).

THE UPSHOT
==========
This means we can't really ship webkit prefix emulation in its current form, until we've added support for -webkit-background-clip:text, -webkit-text-fill-color, and -webkit-text-stroke -- otherwise, we'd be shipping some or all of bug 759568's dependent bugs to our users.

SUGGESTED SHORT-TERM SOLUTION:
==============================
Rather than blocking our webkit prefix support until we support all of the above text-clipping/filling/stroking features (which are of questionable value & which the CSSWG frown upon[1]), I propose we could instead make our webkit-prefixed gradient support a bit trickier.  IN PARTICULAR: if we come across a webkit-prefixed gradient, then we should do some sort of scan through the rest of the CSS rule, and only accept the gradient if we don't find "-webkit-background-clip: text" anywhere.

Something like that, anyway.

This would only work in cases where the background-gradient and -webkit-background-clip:text appear as part of the same CSS rule, clearly. But so far, that seems to always be the case -- it seems to be part of the standard coding pattern for this gradient-colored text.

[1] https://lists.w3.org/Archives/Public/www-style/2012May/1228.html
(In reply to Daniel Holbert [:dholbert] from comment #0)
> * In Firefox release (without webkit-prefix support), this renders as pink 
> * In Firefox Nightly, this renders as a pink background-gradient with pink text on top of it. 
> * In Chrome, this renders as pink text whose color changes slightly

I should have clarified here: the Firefox release & Chrome behaviors here are both acceptable. The Firefox Nightly behavior is unacceptable because the text has the same color as its background.

The goal of this bug would be to restore us to having the Firefox release behavior.
I'm going to WONTFIX this now that "-webkit-background-clip: text" has landed. (bug 759568)

(This bug was intended as a stopgap solution, if bug 759568 turned out to be too hard to fix in a reasonable amount of time.)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.