Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Intent to implement: -webkit-background-clip:text

69 views
Skip to first unread message

Ku(顧思捷)CJ

unread,
Mar 22, 2016, 12:59:30 AM3/22/16
to dev-pl...@lists.mozilla.org
Summary:
-webkit-background-clip:text has been available for years in webkit based
browsers and has seen widespread usage on the web. This css property is
currently available in Chrome, Safari and Edge.

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=759568

Link to standard:
https://compat.spec.whatwg.org/#the-webkit-background-clip-property

Platform coverage:
All platforms.

Estimated or target release:
Firefox 48

Preference behind which this will be implemented:
layout.css.prefixes.webkit

Note:
The way we support this property value is a little bit different with
webkit.
After turning on layout.css.prefixes.webkit,
1. -webkit-background-clip property is supported.
2. In gecko, "text" is a valid value for *both* background-clip and
-webkit-backkground-clip.
3. In webkit, "text" is a valid value for only -webkit-backkground-clip.

If you set "text" into -webkit-background-clip and serialize
background-clip prop by style.getPropertyValue, you will still get "text",
which is problematic. dholbert gave more detail explanation on bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=759568#c40

Jet Villegas

unread,
Mar 22, 2016, 1:38:45 AM3/22/16
to Ku(顧思捷)CJ, group, mozilla.dev.platform
I'd like to see this guarded by its own pref && layout.css.prefixes.webkit

Thanks for working on this, CJ!

--Jet
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

Mike Taylor

unread,
Mar 22, 2016, 1:37:49 PM3/22/16
to Ku(顧思捷)CJ, dev-pl...@lists.mozilla.org
Just wanted to say thanks for working on this -- it was a pleasant
surprise to come back from PTO and see this nearly done!
--
Mike Taylor
Web Compat, Mozilla

Daniel Holbert

unread,
Mar 22, 2016, 4:11:16 PM3/22/16
to j...@mozilla.com, Ku(顧思捷)CJ, dev-pl...@lists.mozilla.org
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

Mike Taylor

unread,
Mar 22, 2016, 5:16:29 PM3/22/16
to Daniel Holbert, dev-pl...@lists.mozilla.org, Ku(顧思捷)CJ, j...@mozilla.com
On 3/22/16 3:11 PM, Daniel Holbert wrote:
> - 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.

+1. It has been nice to have a single pref to flip to test for potential
regressions (and for instructing people to do the same thing).

Jet Villegas

unread,
Mar 22, 2016, 8:21:58 PM3/22/16
to Daniel Holbert, group, mozilla.dev.platform, Ku(顧思捷)CJ
I'm thinking we need two prefs so we cover the prefixed and unprefixed API
as per:
https://lists.w3.org/Archives/Public/www-style/2016Mar/0283.html

It's a bit odd to have the -webkit parser pref also control the rendering
pref in this case.

--Jet




On Wed, Mar 23, 2016 at 5:11 AM, Daniel Holbert <dhol...@mozilla.com>
wrote:

> 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.
>

Daniel Holbert

unread,
Mar 23, 2016, 12:47:30 AM3/23/16
to Mike Taylor, dev-pl...@lists.mozilla.org, Ku(顧思捷)CJ, j...@mozilla.com
On 03/22/2016 02:16 PM, Mike Taylor wrote:
> +1. It has been nice to have a single pref to flip to test for potential
> regressions (and for instructing people to do the same thing).

That's probably not a big concern here -- even if we ship this with its
own dedicated feature-pref, we could still test for potential webcompat
regressions by toggling the main webkit pref on & off, since that would
control whether the "-webkit-background-clip" alias was enabled at all.
(And realistically, people only use this feature via that alias -- not
via the standard "background-clip" property.)

~Daniel

Daniel Holbert

unread,
Mar 23, 2016, 12:55:52 AM3/23/16
to j...@mozilla.com, group, mozilla.dev.platform, Ku(顧思捷)CJ
On 03/22/2016 04:53 PM, Jet Villegas wrote:
> I'm thinking we need two prefs so we cover the prefixed and unprefixed
> API as per:
> https://lists.w3.org/Archives/Public/www-style/2016Mar/0283.html
>
> It's a bit odd to have the -webkit parser pref also control the
> rendering pref in this case.

Yeah... I guess I agree.

(I guess I can also imagine a future where we're ready to ship
"background-clip:text" because it's ready, though we still want to hold
off on shipping webkit prefixing support in general, e.g. because of
some as-yet-undiscovered new source of compat regressions. In that
world, it would be useful to have this feature individually preffable
separately from webkit prefix support.)

So, I'll retract my pushback & agree with giving this its own pref after
all (something like "layout.css.background-clip-text.enabled" per my
earlier response).

Thanks,
~Daniel
0 new messages