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

Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

214 views
Skip to first unread message

Daniel Holbert

unread,
Dec 31, 2015, 1:40:56 AM12/31/15
to dev-pl...@lists.mozilla.org
Summary:
A good chunk of the web today (and particularly the mobile web)
effectively relies on -webkit prefixed CSS properties & features. We
wish we lived in a world where web content always included
standards-based fallback (or at least multiple-vendor-prefixed
fallback), but alas, we do not live in that world. To be successful at
rendering the web as it exists, we need to add support for a list of
frequently-used -webkit prefixed CSS properties & features.
Every other major modern browser engine implements support for these
aliases -- Blink & WebKit obviously have them, & Edge includes them for
compatibility. (I'm not sure about IE's support, but it's not a
particularly important data point, given that Microsoft is focused on
Edge going forward.)

Bug tracking implementation:
https://bugzilla.mozilla.org/show_bug.cgi?id=1170789

Bug to enable pref:
https://bugzilla.mozilla.org/show_bug.cgi?id=1143147
(Will likely land in the next few days.)

Link to standard:
Mike Taylor is working on a WHATWG spec describing the -webkit
prefixed features that we believe are needed for web compatibility.
That spec lives here: http://compat.spec.whatwg.org/
There's also been some discussion on the CSSWG mailing list about
updating official CSS specs to mention legacy -webkit aliases (and
discourage authors from using them), as discussed in this thread:
https://lists.w3.org/Archives/Public/www-style/2015Dec/0132.html

Platform coverage:
All platforms.

Estimated or target release:
Firefox 46 (current Nightly), or 47 if we need to hold it back a
release to fix things.

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

Side note on earlier work:
Earlier this year, in bug 1107378, we shipped an experimental JS-based
version of this feature, which was only active for a whitelist of sites
(all of which strongly depend on webkit prefixes for usability). This
experiment proved successful at making the whitelisted sites usable in
Firefox. The new implementation (behind "layout.css.prefixes.webkit")
will supersede the older experimental JS-based implementation and will
not be whitelisted.

Jonas Sicking

unread,
Dec 31, 2015, 3:40:45 AM12/31/15
to Daniel Holbert, dev-platform
Yay!

(I agree that it's sad that we need to do this, but still "yay" for
being more compatible with the web).

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

Tantek Çelik

unread,
Dec 31, 2015, 12:41:26 PM12/31/15
to Daniel Holbert, Mike Taylor, dev-platform, Jonas Sicking
Daniel, Mike, and the whole compat team, thank you for diligently
figuring out all the nasty details here and pushing this contentious
"feature" forward.

This is a tough balance for the good of our users, and I'm grateful
for all the thought and careful consideration you have put into it.

We noted a high level intent to consider doing this at the CSSWG f2f
nearly two years ago, and as this lands I'm sure it will come up again
at the next f2f. dbaron and I will be there to support your work.

Tantek

Martin Thomson

unread,
Dec 31, 2015, 2:37:27 PM12/31/15
to Daniel Holbert, dev-platform
On Thu, Dec 31, 2015 at 5:40 PM, Daniel Holbert <dhol...@mozilla.com> wrote:
> Summary:
> A good chunk of the web today (and particularly the mobile web)
> effectively relies on -webkit prefixed CSS properties & features. We
> wish we lived in a world where web content always included
> standards-based fallback (or at least multiple-vendor-prefixed
> fallback), but alas, we do not live in that world. To be successful at
> rendering the web as it exists, we need to add support for a list of
> frequently-used -webkit prefixed CSS properties & features.

This is definitely worth doing.

If we intend to continue to support these, and particularly if we
anticipate more prefixed rules in future, I think that it would be
worthwhile providing developers with a more visible notice regarding
their status. Something like the deprecation warning we use for DOM
APIs [1] could be useful. Otherwise, I worry that the warnings will
go unnoticed.

[1] https://dxr.mozilla.org/mozilla-central/rev/22f51211915bf7daff076180847a7140d35aa353/dom/base/nsDocument.cpp#10354

Daniel Holbert

unread,
Dec 31, 2015, 4:15:16 PM12/31/15
to Martin Thomson, dev-platform
On 12/31/2015 11:37 AM, Martin Thomson wrote:
> If we intend to continue to support these,

(We do.)

> and particularly if we
> anticipate more prefixed rules in future

(Happily, I don't anticipate too many more of these -- at least, the
space of -webkit-prefixed features is bounded, because implementors &
standards bodies have realized that vendor prefixes are bad for
web-compat, so they aren't being used for new features. The Chrome/Blink
team, at least, have committed to implementing new features behind their
equivalent of about:config prefs instead of vendor prefixes:
https://www.chromium.org/blink#vendor-prefixes )

> I think that it would be
> worthwhile providing developers with a more visible notice regarding
> their status. Something like the deprecation warning we use for DOM
> APIs [1] could be useful. Otherwise, I worry that the warnings will
> go unnoticed.

I'm not sure I agree. We discussed this a bit during a web-compat
session in MozLando, and there are several reasons not to bother with a
warning in this case (and note that these reasons do not apply to the
deprecated DOM API scenario that you brought up):

(1) Dubious effectiveness: The existing web content where these
warnings would be *most* warranted -- content with webkit-prefixed CSS &
no fallback -- is (by definition) *exactly* the web content whose
developers are not bothering to test Firefox. So, any warning that we
add would have little chance of reaching that intended audience of
developers; it'd just add background noise to our users' error consoles.

(2) Dubious usefulness: Given that these prefixed features will now
Just Work in Firefox, and given that we're saying they're de-facto part
of the web & committing to supporting them (and so are all other modern
browsers), then there's no clear benefit/motivation for web developers
to remove these from their sites. So, for web developers that *do* see
these warnings, it's not clear why they should care & address them (and
take time away from fixing other things).

(3) False positives: There are many "legitimate" ways that authors can
use prefixed properties, and if we added a warning, we'd probably need
to exclude those cases. Some examples of "legitimate" use cases, which
would require some careful extra instrumentation to detect:

CSS with standards-based fallback after it:
.box {
display: -webkit-box;
-webkit-box-orient: horizontal;
/* lots more -webkit-box stuff */
display: flex;
flex-direction: row;
/* lots more modern-flexbox stuff */
}

CSS with standards-based fallback in a completely different CSS rule
(not sure how often this happens, but it's conceivable):
.legacyBox {
display: -webkit-box;
}
.modernBox {
display: flex;
}
...
<div class="legacyBox modernBox">

"@supports"-guarded conditions (where the author is explicitly checking
for browser support before using the legacy feature):
@supports (display: -webkit-box) {
.foo { display: -webkit-box }
}

JavaScript that sets the prefixed style and modern style in separate
statements (i.e. separate passes through the CSS parser, so we have no
way of knowing that a standards-based version is coming up):
elem.style.display = "-webkit-box";
elem.style.display = "flex"; // use modern flexbox, if supported

Each of these "legitimate" scenarios would require a different set of
heuristics to skip the warning (and I'm not sure we'd be able to skip
the warning at all, for the 2nd and 4th cases).

Daniel Holbert

unread,
Dec 31, 2015, 4:53:19 PM12/31/15
to Martin Thomson, dev-platform
On 12/31/2015 01:15 PM, Daniel Holbert wrote:
> (1) Dubious effectiveness:
[...]
> (2) Dubious usefulness: Given that these prefixed features will now
> Just Work in Firefox, and given that we're saying they're de-facto part
> of the web & committing to supporting them (and so are all other modern
> browsers), then there's no clear benefit/motivation for web developers
> to remove these from their sites. So, for web developers that *do* see
> these warnings, it's not clear why they should care & address them (and
> take time away from fixing other things).

(In retrospect, I should've titled (2) "Dubious benefits", instead of
"usefulness", to more clearly differentiate it from (1). Let's pretend I
did.)

Martin Thomson

unread,
Dec 31, 2015, 8:07:22 PM12/31/15
to Daniel Holbert, dev-platform
On Fri, Jan 1, 2016 at 8:15 AM, Daniel Holbert <dhol...@mozilla.com> wrote:
> (3) False positives: There are many "legitimate" ways that authors can
> use prefixed properties

Yep, you convinced me with this.

Daniel Holbert

unread,
May 13, 2016, 1:15:20 PM5/13/16
to dev-pl...@lists.mozilla.org
On 12/30/2015 10:40 PM, Daniel Holbert wrote:
> Estimated or target release:
> Firefox 46 (current Nightly), or 47 if we need to hold it back a
> release to fix things.
>
> Preference behind which this will be implemented:
> layout.css.prefixes.webkit

Following up on this -- this feature will be default-enabled in Firefox
49, as of the pref-unguarding-patch that I just landed on this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1259345

(This feature has been enabled & getting very useful testing & having
bugs filed in Nightly/Aurora ever since Firefox 46. At this point, we've
fixed all known regressions that are triggered by this feature, so we're
calling it safe to ship in Firefox 49, and we'll be watching for any
more bugs that are reported.)

Thanks,
~Daniel

Jet Villegas

unread,
May 13, 2016, 1:50:22 PM5/13/16
to Daniel Holbert, group, mozilla.dev.platform
If I'm reading the dependency list correctly, we still plan to uplift to 48
if we can get bug 1264905 fixed in time. Is that correct?

--Jet

On Fri, May 13, 2016 at 10:15 AM, Daniel Holbert <dhol...@mozilla.com>
wrote:

Daniel Holbert

unread,
May 13, 2016, 1:57:16 PM5/13/16
to j...@mozilla.com, mozilla.dev.platform
On 05/13/2016 10:49 AM, Jet Villegas wrote:
> If I'm reading the dependency list correctly, we still plan to uplift to
> 48 if we can get bug 1264905 fixed in time. Is that correct?

bug 1264905's fix (a pref-unguarding) was just landed, as well.

We could uplift both, if we *also* uplift bug 1269971 (which was just
fixed yesterday, and which bug 1264905 depends on).

I'm instinctively uneasy about that, since that bug (bug 1269971) is
basically a reimplementation of the feature in question.
(background-clip:text)

~Daniel
0 new messages