1170789 - Add support for the most important WebKit prefixed CSS properties & features for web compatibility

Status: NEW

(Core :: CSS Parsing and Computation, enhancement)

Description

[Mike Taylor [:miketaylr]]

See Bug 1170774 as well as the ones implemented in Edge:

<https://docs.google.com/spreadsheets/d/173d1p3LkW_LWk-VMnrxGPhTobtKSpED30Fys5ZJLttA/edit#gid=51341101>

Comment 1

[Mike Taylor [:miketaylr]]

This is sub-meta bug to collect the bugs related to aliasing -webkit- CSS properties. Individual bugs incoming.

Comment 2

[Daniel Holbert [:dholbert]]

[Broadening this from "CSS properties" to "CSS properties & features", to better cover things like -webkit-min-device-pixel-ratio, -webkit-gradient, display:-webkit-box, none of which are "properties" technically.]

Comment 3

[Pierre-Yves Gérardy]

It would be nice, in the process, not to break things for people who use Lea Verou's PrefixFree [0] to handle prefixes where needed.

Since some browsers support multiple prefixes, PrefixFree iterates over all existing properties [1], at load-time, to pick the most used prefix.

I know that you don't use the -moz prefix for new WIP features, but if there are still -moz-prefixed properties/values/selectors/at-rules hanging around by the time you ship this issue, -moz may be drowned out by -webkit, and PrefixFree will pick the wrong one.

While I'm sure PrefixFree can be adapted to cope with the situation, sites that rely on older versions may break.

----

[0] http://lea.verou.me/prefixfree/
[1] https://github.com/LeaVerou/prefixfree/blob/gh-pages/prefixfree.js#L276-L325

Comment 4

[Pierre-Yves Gérardy]

To be frank, I'm not very familiar with the current state of -moz-prefixed features left in Firefox...

If some of them are still present when -webkit lands, you could double the remaining -moz things with -webkit counterparts, and both would be deprecated when the corresponding non-prefixed feature ships.

Comment 5

[Mike Taylor [:miketaylr]]

Hi Pierre-Yves, if we're breaking sites then that's a bug. Can you point to a site or demo page to demonstrate the issue? Or is this more a theoretical concern?

Comment 6

[Pierre-Yves Gérardy]

I don't have a concrete example, but given the popularity of the library, it is quite likely that some sites could end up being affected. Finding examples on my own would require infrastructure that I don't have at hand.

Actually, it depends on whether the `-webkit`-prefixed properties are exposed to JS through `getComputedStyle(document.documentElement, null)`. If they aren't PrefixFree as it extists today will continue to work fine.

Comment 7

[Pierre-Yves Gérardy]

How can I build a FF version that implements -webkit prefixes? I'd like to test if the way it is implemented breaks PrefixFree as it currently works  (or could break it in the future if the -webkit count ever surpasses -moz).

Comment 8

[Daniel Holbert [:dholbert]]

You can just download & test Nightly from http://nightly.mozilla.org/ -- these prefixes are enabled by default there.  Or, any trunk build should work too ( https://developer.mozilla.org/en-US/docs/Simple_Firefox_build )

Comment 9

[Pierre-Yves Gérardy]

Ok, I got it up and running.

As it is, it will not break PrefixFree, but I don't know if it is by design of by accident.

`getComputedStyle(document.documentElement, null)` returns an array-like `CSS2Properties` object with 256 string items representing properties. Among those, none are Webkit-prefixed, which means that PrefixFree will not stumble on the wrong prefix.

However, the prototype of that object, `CSS2PropertiesPrototype`, a dictionary-like object, has 600+ entries, many of which being webkit-prefixed and enumerable.

I don't have any idea of the criteria to select what to put in the Array-like `CSS2Properties` object, though, and if `webkit` prefixed properties ever outnumbered `moz` prefixed ones there, it would break things.

It may be nice to add a comment in the source that populates `CSS2Properties` to keep it webkit-free.

Comment 10

[Daniel Holbert [:dholbert]]

Glad to hear it works! I don't know much about the distinction between that CSS2Properties & CSS2PropertiesPrototype interface offhand, but it sounds like the difference is that one includes aliases (whether -webkit or not), and one does not.  I believe they're populated by macros which are run over our lists of known properties & property-aliases, and I think the restricted nature of CSS2Properties is deliberate.

Anyway -- if you do run into any issues, please file a bug and CC me. Thanks!

Comment 11

[Pierre-Yves Gérardy]

Thanks for the help.

I just had a look at the source and it looks like you are right about the distinction, so it was a false alarm, definitely.

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Release Note Request (optional, but appreciated)
[Why is this notable]: Important change for compatibility
[Suggested wording]: Support of the most important WebKit CSS properties & features
[Links (documentation, blog post, etc)]: Do we have an official blog post which explains that?

Comment 13

[Daniel Holbert [:dholbert]]

This bug here is actually a metabug, which didn't directly have anything land (and there will likely continue to be a long tail of helper-bugs that get filed/fixed here, before we consider this bug "fixed").

Also: this feature isn't shipping past aurora, for the time being (bug 1238827).  Given that, does it still merit a relnote? (Perhaps an Aurora-only relnote?)

> Do we have an official blog post which explains that?

karl blogged about this here:
 http://www.otsukare.info/2016/01/04/webkit-resolved-fixed

(I should perhaps blog about this from more of a technical/implementation perspective, too, though I might wait until this is closer to shipping past Aurora.)

Comment 14

[Daniel Holbert [:dholbert]]

(If we do want an aurora-only relnote, I'd suggest tying that to bug 1213126 instead of to this bug, since this bug here is "meta" & hence hard to follow from a release-tracking perspective -- whereas bug 1213126 had a patch land to enable the feature.)

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Right, thanks. Moved to bug 1213126