Platform/Layout/CSS Compatibility

CSS vendor-prefix compatibility

This page is preserved to maintain history and not intended for current status of projects.

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?

1. Studying the extent of -webkit- property dependence (Bugzilla 708406).
2. Prioritizing standardization for such properties that have high levels of -webkit- prefix usage on the web (text-size-adjust, CSS3 Animations/Transitions/Transforms).
3. 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

• A List Apart: The Vendor Prefix Predicament
• Policy for experimental CSS features in Gecko

problem statement

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).

data: https://bugzilla.mozilla.org/show_bug.cgi?id=708406

problematic sites

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.

goals

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.

straw proposal

• Prioritize standards for commonly used -webkit- prefixed properties.
  • text-size-adjust
  • 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).

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:
  • transforms
  • transitions
  • animations
  • border-image

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 principles

• 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

2010:

• 2010-05-10 Microsoft states support for a -webkit- property and then withdraws it a day later due to community feedback: http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx in particular:

  "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:

• 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:

• 2012-02-06 CSSWG - http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html (IRC log)
• 2012-02-07
  • 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
• 2012-02-09
  • 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
• 2012-02-10
  • 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
• ...
• 2012-02-14
  • A List Apart: The Vendor Prefix Predicament: ALA’s Eric Meyer Interviews Tantek Çelik
• 2012-02-15
  • Alex Russell: Misdirection
  • Dylan Wilbanks: Vendor prefixes and their discontents
• ...
• 2012-04-25
  • .net: Opera confirms WebKit prefix usage
• ...
• 2012-04-27
  • 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
• ...
• 2012-06-04
  • mozilla.dev.platform: Policy for experimental CSS features in Gecko - proposal by David Baron
• ...
• 2012-07-03
  • PPK: Vendor prefixes are fucking batshit crazy (troll?)
• ...

• change.org: Microsoft, Mozilla & Opera: Don’t make -webkit- prefixes a de facto standard

FAQ

• ...

Next Steps

• 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?

text-size-adjust	510	1.70%
box-shadow	428	1.42%
border-radius	412	1.37%
appearance	379	1.26%
font-smoothing	285	0.95%
tap-highlight-color	250	0.83%
transform	75	0.25%
border-top-left-radius	72	0.24%
border-top-right-radius	72	0.24%
transition-duration	61	0.20%
animation-duration	56	0.19%
animation-name	56	0.19%
border-bottom-left-radius	55	0.18%
border-bottom-right-radius	55	0.18%
transition-property	49	0.16%
animation-iteration-count	45	0.15%
padding-start	45	0.15%
background-size	43	0.14%
animation-timing-function	42	0.14%
box-sizing	42	0.14%

Larger, as-yet-unprocessed datasets

• Raw data downloading completed in mid-January 2012, using these UAs:

1. latest Android Native Browser from ICS
2. latest Mobile Safari UA

• Includes all HTML, Javascript, CSS files in compressed format
• Roughly 1.1m files downloaded for each UA

Summary data is attached to bug 708406.