On 03/21/2016 10:38 PM, Jet Villegas wrote:
> I'd like to see this guarded by its own pref && layout.css.prefixes.webkit
Pushing back on this slightly:
- At this point, I don't think it's conceivable that we'd want to ship
our webkit compatibility work until we're ready to also ship support for
"-webkit-background-clip:text". (If we're missing that feature, -webkit
gradient support ends up causing too many visual regressions to be
shippable, as noted at
https://lists.w3.org/Archives/Public/www-style/2016Mar/0290.html )
- Therefore, I'm not sure we get any real-world benefit from guarding
this feature with an additional dedicated pref. And there'd be a
complexity cost from making sure we test all combinations of pref
enabled/disabled states, & do the right thing when one or the other pref
is disabled.
So, I'm not sure the cost/benefit calculus of adding a new, dedicated
pref adds up here.
However, if we do add another pref here, I think we'd want to just have
it directly control this "text" value, independent of webkit prefixing
support. Specifically, I imagine we'd have these prefs:
(1) layout.css.background-clip-text.enabled (new) to control whether
"background-clip: text" is supported
(2) layout.css.prefixes.webkit (existing) to control whether
"-webkit-background-clip" is an alias for "background-clip". (This part
is already done.)
(This way, "-webkit-background-clip:text" would *effectively* be
disabled unless both prefs are on -- but we wouldn't need to do any
multi-pref checks anywhere in the code. There'd be no need for "own
pref && layout.css.prefixes.webkit" guarding.)
This configuration makes sense to me - though I'm still not sure it adds
value over just reusing the same pref, since as noted above we can't
really ship one without the other.
~Daniel