CSS vendor-prefix compatibility
Problem: WebKit mobile web monoculture. There is currently (still) a WebKit mobile web monoculture, numerous sites that have WebKit-specific content and reduced content/style/functionality for everyone else, despite numerous evangelists at Mozilla, Opera, and Microsoft working with web developers to publish standards-based cross-browser content.
What is Mozilla doing about the problem?
- Studying the extent of -webkit- property dependence (Bugzilla 708406).
- Prioritizing standardization for such properties that have high levels of -webkit- prefix usage on the web (text-size-adjust, CSS3 Animations/Transitions/Transforms).
- Experimenting with some -webkit- prefix support to see if it fixes sites.
Is Firefox going to support WebKit prefixes?
- Very UNLIKELY - per our study of -webkit- dependent sites and experiments with some -webkit- prefix support see if it fixes sites (answer: very few, and even breaks some).
If so, when is that happening?
- We don't have a specific release or date yet. We are continuing to study which sites appear to require Webkit-prefixed properties, and if implementing them actually fixes those sites or not (WebKit-specific sites sometimes depend on other WebKit-specific features, e.g.: touch events, WebSQL, etc.)
For more details, read on, and see also
- 1 CSS vendor-prefix compatibility
- 1.1 problem statement
- 1.2 goals
- 1.3 straw proposal
- 1.4 straw proposal downsides
- 1.5 possible downside mitigation
- 1.6 questions and methodology
- 1.7 parsing other vendor prefixes approaches
- 1.8 unprefixing principles
- 1.9 meetings minutes discussions
- 1.10 FAQ
- 1.11 Next Steps
- 1.12 Data on vendor-specific prefixes
Sites that have WebKit-specific content and back-up content for everyone else.
-webkit- properties are used so much on mobile content in particular that non-WebKit browsers face a Prisoner's Dilemma problem, analogous to past quirks battles (e.g. 2003-4 era innerHTML and undetected document.all).
See http://people.mozilla.com/~atrain/mobile/Evangelism/chrome-compare/chrome-compare.html for a comparison of Chrome on Android vs. Mobile Firefox mobile/13.0a1 Nightly
Feel free to add specific problematic sites here so QA & Evangelism can investigate and follow-up:
See the tracking bug 739832 for more.
The underlying open web goal:
- Open up the webkit-specific part of the web to other vendors in the same way that we had to be practical about what IE-proprietary or IE-only technologies to support.
- Prioritize standards for commonly used -webkit- prefixed properties.
- CSS3 Animations (Mozilla ships unprefixed support)
- CSS3 Transitions (Mozilla ships unprefixed support)
- CSS3 Transforms (Mozilla ships unprefixed support)
- Consider implementing some -webkit- prefixed properties.
- Experiment with implementation and see if that fixes sites (the efficacy test).
- So far, efficacy is poor (very few sites are fixed), and there are negative side-effects (some sites got worse with -webkit- prefixes).
- Experiment with implementation and see if that fixes sites (the efficacy test).
straw proposal downsides
- Unfortunately for the open web, implementing a -webkit- prefixed property (outside of WebKit) will nearly legitimize (make people assume they'll work forever) the use of -webkit- prefixed properties.
possible downside mitigation
- In the short term we can at least remove pain for web authors and users.
- In the long term we can ensure the unprefixed properties (in CR drafts) work and encourage authors to switch to them. Done for:
See and try How you can help with removing -moz- prefixes.
questions and methodology
For sites in general:
- What are the thresholds (even approximate) for supporting an other-vendor prefixed property vs. not?
- How much of this is due to user-agent sniffing?
- Is there an approximate % of top N sites that justifies it?
- Is there a set of specific top sites that justifies it?
- Could grab the Alexa 50 for mobile and compare side-by-side
- How should we consider occurrence counts of -webkit- properties?
- Weighted by PageRank or equivalent?
- Severity of feature absence. Missing some properties breaks a lot more than missing others. Consider usability of page with/without the feature, not just how often it is used. E.g. tap-highlight-color does not affect the user's ability to use a website the same way text-size-adjust does.
For specific sites:
- *Which* sites will work *how much* better if we implement *which* properties?
- The sites which are currently "broken" should be listed above in "problematic sites" and have a bug# for each one.
parsing other vendor prefixes approaches
- parse other vendor prefixed properties only in conjunction with parsing the equivalent unprefixed properties
- only do it for environments where critically necessary, i.e. mobile not desktop, to encourage use of standard equivalents.
- unprefixing things early (before CR) should be an exceptional case
- what is the methodology for "exceptional" unprefixing?
- unprefixing things must be evaluated carefully on case-by-case basis.
- unprefixing is not something to do routinely just to "go faster" by a few months.
- put the energy first into contributing and passing test suites instead.
See also: Policy for experimental CSS features in Gecko.
meetings minutes discussions
"We've also added support for the -webkit-text-size-adjust CSS selector. This selector allows you to control how text on the Web page is scaled to increase readability for the user (you can also use -ms-text-size-adjust, IE Mobile recognizes both).
... [one day later] ...
"[Update 05/11/2010: based on community feedback, we will only be implementing the -ms- prefix, not the -webkit- one.]"
- 2010-05-11 Jonathan Snook: Vendors using Competing Prefixes
- 2011-11-15 Henri Sivonen: Vendor Prefixes Are Hurting the Web
- 2011-11-16 Glazblog: CSS vendor prefixes, an answer to Henri Sivonen
- 2011-11-18 Infrequently Noted / Alex Russell blog: Vendor Prefixes Are A Rousing Success
- 2012-02-06 CSSWG - http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html (IRC log)
- CSSWG - http://krijnhoetmer.nl/irc-logs/css/20120207#l-550 , http://krijnhoetmer.nl/irc-logs/css/20120207#l-1066
- blog post: http://qfox.nl/weblog/244 "Prefixed to death"
- UBelly: Vendor prefixes: the good, the bad and the ugly
- Bruce Lawson blog: On the vendor prefixes problem
- Eric Meyer: Unfixed
- Christian Heilmann blog: Now vendor prefixes have become a problem, want to help fix it?
- CNET: W3C co-chair: Apple, Google power causing Open Web crisis
- Easy Designs Blog: This Must Not Happen!
- Glazblog: CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*
- Remy Sharp's blog: Vendor Prefixes - about to go south
- Gilles Vandenoostende blog: On Vendor Prefixes
- Lea Verou: Vendor prefixes, the CSS WG and me
- .net: CSS vendor prefixes threaten open web
- WebMonkey: WebKit Isn’t Breaking the Web, You Are
- YCombinator Hacker News: "Long experience of contacting sites suggests that it is, at best, of limited effectiveness. ..." - hoppipolla at Opera on limits of evangelism
- Pam Griffith: Thoughts on all this vendor prefix nonsense
- Robert O'Callahan blog: Alternatives To Supporting -webkit Prefixes In Other Engines
- Web Standards Project: Call for action on Vendor Prefixes
- Alex Russell: Misdirection
- Dylan Wilbanks: Vendor prefixes and their discontents
- Dev.Opera: Opera Mobile Emulator build with experimental WebKit prefix support - has list of -webkit- properties Opera has decided to support so far.
- WebMonkey: Opera Forges Ahead With Plan to Support WebKit Prefixes
- mozilla.dev.platform: Policy for experimental CSS features in Gecko - proposal by David Baron
- PPK: Vendor prefixes are fucking batshit crazy (troll?)
- Propose -webkit- properties to implement in Firefox Mobile, each based on specific data from bug 708406.
- -webkit-... due to prevalence of usage in x% of sites ...
- (none so far that are justified by the experiments done / data collected)
Data on vendor-specific prefixes
Here's a summary of the data collection and analysis that has been conducted regarding the use of various CSS vendor-specific prefixes.
The current datasets, collected by John Jensen, are:
Initial CSS properties dataset
- Completed in November 2011
- Summary of 88,000 CSS files from top 30,000 sites on the web, collected using Desktop FF 8.0 User-Agent
- Tables and summary reports in https://bugzilla.mozilla.org/show_bug.cgi?id=708406
- Written report and summary tables are attached to the ticket.
- Summary file, in CSV format, is 620MB compressed, 7.2GB uncompressed, available at http://people.mozilla.com/~jjensen/css.csv.gz
Q and A
- how many sites in your mobile Webkit browser crawl use at least one of 'transition', 'transition-timing-function', 'transition-duration', 'transition-property', 'transition-delay' (ignoring prefixes)?
1245 / 30087 = 4.13%
- how many use them only with -webkit prefixes (no -moz or unprefixed versions of the properties)?
336 / 30087 = 1.12%
- how many use them only with -webkit prefixes and unprefixed (no -moz versions of the properties)?
365 / 30087 = 1.21%
- For each CSS prefix for which there are both -moz- and -webkit- prefixes, what percentage of domains host CSS that uses only the -webkit- version and not the -moz- or unprefixed version?
Larger, as-yet-unprocessed datasets
- Raw data downloading completed in mid-January 2012, using these UAs:
- latest Android Native Browser from ICS
- latest Mobile Safari UA
- Roughly 1.1m files downloaded for each UA