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 _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
