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

NEW
Unassigned

Status

()

enhancement
4 years ago
13 days ago

People

(Reporter: miketaylr, Unassigned)

Tracking

(Depends on 4 bugs)

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Updated

4 years ago
Blocks: 1170774
Reporter

Updated

4 years ago
Depends on: 1176968
Reporter

Comment 1

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

Updated

4 years ago
Depends on: 1132748
Reporter

Updated

4 years ago
Depends on: 1179386
Reporter

Updated

4 years ago
Depends on: 1179393
Reporter

Updated

4 years ago
Depends on: 1179406
Reporter

Updated

4 years ago
Depends on: 1179408
Reporter

Updated

4 years ago
Depends on: 1179437
Reporter

Updated

4 years ago
Depends on: 1179444
Depends on: 837211
Reporter

Updated

4 years ago
No longer depends on: 1179386
Depends on: 1208635
Depends on: 1208344
Reporter

Updated

4 years ago
No longer depends on: 1179406
Reporter

Updated

4 years ago
Depends on: 1231829
[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.]
Component: Layout → CSS Parsing and Computation
Summary: Alias the most important WebKit CSS properties for mobile compatibility → Alias the most important WebKit CSS properties & features for mobile compatibility
Depends on: 1217643
Depends on: 1210575
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
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.
Reporter

Comment 5

3 years ago
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?
Flags: needinfo?(pygy79)
Depends on: 1236506
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.
Flags: needinfo?(pygy79)
Reporter

Updated

3 years ago
Depends on: 1241021
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).
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 )
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.
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!
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.
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?
relnote-firefox: --- → ?
Depends on: 1242617
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.)
Flags: needinfo?(sledru)
Summary: Alias the most important WebKit CSS properties & features for mobile compatibility → Alias the most important WebKit prefixed CSS properties & features for mobile compatibility
(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.)
Right, thanks. Moved to bug 1213126
relnote-firefox: ? → ---
Flags: needinfo?(sledru)
Reporter

Updated

3 years ago
Depends on: 1244492
Reporter

Updated

3 years ago
Depends on: 1245997
Reporter

Updated

3 years ago
Summary: Alias the most important WebKit prefixed CSS properties & features for mobile compatibility → Alias the most important WebKit prefixed CSS properties & features for web compatibility
See Also: → 1294593
Reporter

Updated

2 years ago
Depends on: 1355574
Reporter

Updated

2 years ago
Summary: Alias the most important WebKit prefixed CSS properties & features for web compatibility → Add support for the most important WebKit prefixed CSS properties & features for web compatibility

Updated

a year ago
Duplicate of this bug: 690985

Updated

a year ago
Depends on: 1432935

Updated

a year ago
Depends on: 1455565

Updated

a year ago
Depends on: 1368555
Type: defect → enhancement
You need to log in before you can comment on or make changes to this bug.