See Bug 1170774 as well as the ones implemented in Edge: <https://docs.google.com/spreadsheets/d/173d1p3LkW_LWk-VMnrxGPhTobtKSpED30Fys5ZJLttA/edit#gid=51341101>
This is sub-meta bug to collect the bugs related to aliasing -webkit- CSS properties. Individual bugs incoming.
[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
It would be nice, in the process, not to break things for people who use Lea Verou's PrefixFree  to handle prefixes where needed. Since some browsers support multiple prefixes, PrefixFree iterates over all existing properties , 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. ----  http://lea.verou.me/prefixfree/  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.
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?
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.
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?
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.)
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.)
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
3 years ago
Depends on: webkit-line-clamp
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
You need to log in before you can comment on or make changes to this bug.