Platform/Layout/CSS Compatibility: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "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 J...")
 
(added banner note on history for page)
 
(40 intermediate revisions by 7 users not shown)
Line 1: Line 1:
= CSS vendor-prefix compatibility =
<div style="width: 80%; padding: .5em 4em; background-color: #fc0;font-size: 1.rem;margin:auto;">
This page is preserved to maintain history and not intended for current status of projects.
</div>
'''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 ([https://bugzilla.mozilla.org/show_bug.cgi?id=708406 Bugzilla 708406]).
# '''Prioritizing standardization''' for such properties that have high levels of -webkit- prefix usage on the web ([[CSS/text-size-adjust|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 [https://bugzilla.mozilla.org/show_bug.cgi?id=708406 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
* [http://www.alistapart.com/articles/the-vendor-prefix-predicament-alas-eric-meyer-interviews-tantek-celik/ A List Apart: The Vendor Prefix Predicament]
* [https://groups.google.com/forum/?fromgroups=#!msg/mozilla.dev.platform/itl6mtx2dxI/mbdPvbexB2EJ Policy for experimental CSS features in Gecko]
__TOC__
== 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 &amp; [[Mobile/Evangelism|Evangelism]] can investigate and follow-up:
* ...
See the  [https://bugzilla.mozilla.org/show_bug.cgi?id=739832 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.
** [[CSS/text-size-adjust|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 <cite>[http://dbaron.org/log/20130225-removing-prefixes How you can help with removing -moz- prefixes]</cite>.
== 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: [https://groups.google.com/forum/?fromgroups=#!msg/mozilla.dev.platform/itl6mtx2dxI/mbdPvbexB2EJ 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: <blockquote><p>"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).</p><p> ... [one day later] ... </p><p><b>"[Update 05/11/2010: based on community feedback, we will only be implementing the -ms- prefix, not the -webkit- one.]"</b></p>
* 2010-05-11 Jonathan Snook: [http://snook.ca/archives/html_and_css/vendor-prefixes-competing Vendors using Competing Prefixes]
'''2011:'''
* 2011-11-15 Henri Sivonen: [http://hsivonen.iki.fi/vendor-prefixes/ Vendor Prefixes Are Hurting the Web]
** 2011-11-16 Glazblog: [http://www.glazman.org/weblog/dotclear/index.php?post/2011/11/16/CSS-vendor-prefixes-an-answer-to-Henri-Sivonen CSS vendor prefixes, an answer to Henri Sivonen]
** 2011-11-18 Infrequently Noted / Alex Russell blog: [http://infrequently.org/2011/11/vendor-prefixes-are-a-rousing-success/ Vendor Prefixes Are A Rousing Success]
'''2012:'''
* 2012-02-06 CSSWG - http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html ([http://krijnhoetmer.nl/irc-logs/css/20120206#l-244 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: [http://www.ubelly.com/2012/02/vendor-prefixes-the-good-the-bad-and-the-ugly/ Vendor prefixes: the good, the bad and the ugly]
* 2012-02-09
** Bruce Lawson blog: [http://www.brucelawson.co.uk/2012/on-the-vendor-prefixes-problem/ On the vendor prefixes problem]
** Eric Meyer: [http://meyerweb.com/eric/thoughts/2012/02/09/unfixed/ Unfixed]
** Christian Heilmann blog: [http://christianheilmann.com/2012/02/09/now-vendor-prefixes-have-become-a-problem-want-to-help-fix-it/ Now vendor prefixes have become a problem, want to help fix it?]
** CNET: [http://news.cnet.com/8301-1001_3-57373764-92/w3c-co-chair-apple-google-power-causing-open-web-crisis/ W3C co-chair: Apple, Google power causing Open Web crisis]
** Easy Designs Blog: [http://blog.easy-designs.net/archives/2012/02/09/this-must-not-happen/ This Must Not Happen!]
** Glazblog: [http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION:-THE-OPEN-WEB-NEEDS-YOU-NOW CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*]
** Remy Sharp's blog: [http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south/ Vendor Prefixes - about to go south]
** Gilles Vandenoostende blog: [http://blog.vandenoostende.com/2012/on-vendor-prefixes/ On Vendor Prefixes]
** Lea Verou: [http://lea.verou.me/2012/02/vendor-prefixes-the-css-wg-and-me/ Vendor prefixes, the CSS WG and me]
** .net: [http://www.netmagazine.com/news/css-vendor-prefixes-threaten-open-web-121757 CSS vendor prefixes threaten open web]
** WebMonkey: [http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ WebKit Isn’t Breaking the Web, You Are]
** YCombinator Hacker News: "[http://news.ycombinator.com/item?id=3570713 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: [http://www.pamgriffith.net/blog/thoughts-on-all-this-vendor-prefix-nonsense Thoughts on all this vendor prefix nonsense]
** Robert O'Callahan blog: [http://robert.ocallahan.org/2012/02/alternatives-to-supporting-webkit.html Alternatives To Supporting -webkit Prefixes In Other Engines]
** Web Standards Project: [http://www.webstandards.org/2012/02/09/call-for-action-on-vendor-prefixes/ Call for action on Vendor Prefixes]
* ...
* 2012-02-14
** A List Apart: [http://www.alistapart.com/articles/the-vendor-prefix-predicament-alas-eric-meyer-interviews-tantek-celik/ The Vendor Prefix Predicament: ALA’s Eric Meyer Interviews Tantek Çelik]
* 2012-02-15
** Alex Russell: [http://infrequently.org/2012/02/misdirection/ Misdirection]
** Dylan Wilbanks: [http://dylanwilbanks.com/blog/2012/02/15/vendor-prefixes-and-their-discontents/ Vendor prefixes and their discontents]
* ...
* 2012-04-25
** .net: [http://www.netmagazine.com/news/opera-confirms-webkit-prefix-usage-121923 Opera confirms WebKit prefix usage]
* ...
* 2012-04-27
** Dev.Opera: [http://dev.opera.com/articles/view/opera-mobile-emulator-experimental-webkit-prefix-support/ Opera Mobile Emulator build with experimental WebKit prefix support] - has list of -webkit- properties Opera has decided to support so far.
** WebMonkey: [http://www.webmonkey.com/2012/04/opera-forges-ahead-with-plan-to-support-webkit-prefixes/ Opera Forges Ahead With Plan to Support WebKit Prefixes]
* ...
* 2012-06-04
** mozilla.dev.platform: [https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/itl6mtx2dxI Policy for experimental CSS features in Gecko] - proposal by David Baron 
* ...
* 2012-07-03
** PPK: [http://www.quirksmode.org/blog/archives/2012/07/vendor_prefixes.html Vendor prefixes are fucking batshit crazy] (troll?)
* ...
* change.org: [http://www.change.org/petitions/microsoft-mozilla-opera-dont-make-webkit-prefixes-a-de-facto-standard 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=708406 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.
Here's a summary of the data collection and analysis that has been conducted regarding the use of various CSS vendor-specific prefixes.


Line 8: Line 170:
* Tables and summary reports in https://bugzilla.mozilla.org/show_bug.cgi?id=708406
* Tables and summary reports in https://bugzilla.mozilla.org/show_bug.cgi?id=708406
* Written report and summary tables are attached to the ticket.  
* Written report and summary tables are attached to the ticket.  
* Summary file, in CSV format, is 620MB compressed, 7.2GB uncompressed, available at http://analysis.net/moz/css.csv.gz
* 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 ===
=== Larger, as-yet-unprocessed datasets ===
Line 16: Line 234:
* Includes all HTML, Javascript, CSS files in compressed format
* Includes all HTML, Javascript, CSS files in compressed format
* Roughly 1.1m files downloaded for each UA
* Roughly 1.1m files downloaded for each UA
* CSS file parsing is underway to produce more data
 
Summary [https://bug708406.bugzilla.mozilla.org/attachment.cgi?id=596728 data] is attached to [https://bugzilla.mozilla.org/show_bug.cgi?id=708406 bug 708406].
 
 
[[Category:Web Compatibility]]

Latest revision as of 21:15, 6 March 2024

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

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:

2011:

2012:

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

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.

Retrieved from "https://wiki.allizom.org/index.php?title=Platform/Layout/CSS_Compatibility&oldid=1250166"