Closed
Bug 708406
Opened 13 years ago
Closed 6 years ago
[meta] Analysis of the use of vendor-specific CSS property prefixes on the web
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
People
(Reporter: jjensen, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: meta)
Attachments
(10 files, 1 obsolete file)
102.69 KB,
application/vnd.oasis.opendocument.presentation
|
Details | |
153.46 KB,
application/pdf
|
Details | |
52.34 KB,
text/plain
|
Details | |
36.81 KB,
text/plain
|
Details | |
45.20 KB,
text/plain
|
Details | |
18.26 KB,
application/vnd.oasis.opendocument.spreadsheet
|
Details | |
8.85 KB,
text/plain
|
Details | |
29.66 KB,
application/vnd.oasis.opendocument.spreadsheet
|
Details | |
110.62 KB,
text/csv
|
Details | |
39.65 KB,
application/vnd.oasis.opendocument.spreadsheet
|
Details |
(I'm not sure if this the right project; please feel free to move elsewhere if necessary)
This is tracking bug to review data and summary presentation of a review of the use of vendor-specific (moz,webkit,o,ms,khtml) CSS prefixes across the web.
See the attached short summary document (in ODP and PDF formats), or more detailed results in the attachments that will be coming shortly.
Reporter | ||
Comment 1•13 years ago
|
||
Reporter | ||
Comment 2•13 years ago
|
||
Reporter | ||
Comment 3•13 years ago
|
||
These numbers used a traditional desktop UA for the crawl?
It would be useful to have the same reports for a crawl that pretends to be a mobile browser getting the "mobile version" of sites that have one.
Component: DOM: CSS Object Model → Style System (CSS)
OS: Linux → All
Hardware: x86 → All
Reporter | ||
Comment 5•13 years ago
|
||
Yes, it was the desktop Firefox 8.0 for the crawl.
I am currently setting up instances to crawl the web using the latest UAs for:
1) iOS Mobile Safari
2) Fennec
3) Android Browser
4) Desktop Firefox
In addition to parsing the static .css files, it will also parse inline style sheets and tags in HTML documents, where, anecdotally, more of the mobile-specific CSS can be found.
John
Comment 6•13 years ago
|
||
I took the 'most common properties' section of the report in comment 3 and sorted just the counts where webkit and moz properties are reported to get a list like below that shows for a lot of the top used properties the use of moz-* prefix outnumbers the -webkit-* prefix. there are some exceptions like:
6084 -webkit-transition
5139 -moz-transition
and
17971 -webkit-border-top-right-radius
275 -moz-border-top-right-radius
but this is the kind of thing that we want to get at, right? places where use of the -webkit prefix exceeds the -moz prefix, or the use of the moz prefix doesn't register at all... If we first did that for the accumulation of all the data like in the list below, then tried to do that on a more site specific basis, then we have a list of properties that provided the most impact, and a list of the sites that might "just start working" if we make some changes to accept webkit- properties.
147285 -moz-border-radius
128901 -webkit-border-radius
57968 -moz-box-shadow
57197 -webkit-box-shadow
18981 -moz-border-radius-topright
18926 -moz-border-radius-topleft
18793 -moz-opacity
17971 -webkit-border-top-right-radius
275 -moz-border-top-right-radius
17848 -moz-border-radius-bottomleft
17762 -webkit-border-top-left-radius
17495 -moz-border-radius-bottomright
17056 -webkit-border-bottom-left-radius
16805 -webkit-border-bottom-right-radius
6084 -webkit-transition
5139 -moz-transition
4576 -moz-background-clip
3677 -moz-box-sizing
3050 -webkit-box-sizing
3399 -moz-background-origin
3210 -moz-background-inline-policy
2805 -moz-user-select
2214 -webkit-transform
2176 -moz-transform
2145 -webkit-background-clip
2011 -moz-box-orient
1937 -webkit-text-size-adjust
1850 -webkit-appearance
1709 -webkit-font-smoothing
1488 -webkit-user-select
1420 -webkit-transition-duration
1367 -moz-outline
1295 -moz-text-shadow
1238 -webkit-text-shadow
1101 -moz-outline-style
1026 -moz-transition-duration
Comment 7•13 years ago
|
||
On radii, see:
https://developer.mozilla.org/en/CSS/border-top-right-radius
In short:
18981 -moz-border-radius-topright - the only value supported in Firefox 3.6 and below; now
we also support the standard border-top-right-radius.
275 -moz-border-top-right-radius - does not and has never existed; presumably someone
copied the Webkit property and just changed the prefix
However, for this property, we need to know which sites specify a webkit-border-radius without the standard version, or with an invalid moz version by mistake. Only then can we know which sites are broken.
The same applies to box-shadow - we implemented this unprefixed in 4.0, so we need to know how many sites are not using the unprefixed version.
webkit-opacity was in Safari 1.1, but has been opacity since then, so it's not surprising that we see very few instances of it. By contrast, we only unprefixed opacity in 4.0.
"transition" is currently unprefixed in neither browser, so we need to know how many sites use the webkit version without using the moz version. It looks like about 5/6 of them use both.
"box-sizing" - everyone else has it unprefixed; but our version is buggy (see bug 243412) so we haven't unprefixed it yet. It seems many sites are using it regardless...
Anyway: I guess what we need is more detailed info on how many sites use certain constructs but not other constructs (and therefore have some chance of starting to work if we support the alternative syntax).
Gerv
Reporter | ||
Comment 8•13 years ago
|
||
I have put the summary data file on a public URL for download:
http://analysis.net/moz/css.csv.gz
Note that it is 620MB compressed, 7.2GB uncompressed
Comment 9•13 years ago
|
||
(In reply to Gervase Markham [:gerv] from comment #7)
> webkit-opacity was in Safari 1.1, but has been opacity since then, so it's
> not surprising that we see very few instances of it. By contrast, we only
> unprefixed opacity in 4.0.
opacity has been supported _ un-prefixed _ since Firefox 1.0 (the prefix code was dropped in the Gecko 2.0 timespan, though)
Comment 10•13 years ago
|
||
(In reply to John Jensen from comment #8)
> I have put the summary data file on a public URL for download:
> http://analysis.net/moz/css.csv.gz
>
> Note that it is 620MB compressed, 7.2GB uncompressed
This file was corrupt; it has now been replaced with a fixed version.
Gerv
Reporter | ||
Comment 11•13 years ago
|
||
...and has been moved to: http://people.mozilla.com/~jjensen/css.csv.gz
Reporter | ||
Comment 12•13 years ago
|
||
The wiki discussion referencing this ticket can be found at
https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility
Reporter | ||
Comment 13•13 years ago
|
||
I've produced some raw datasets suitable for better assessing the issue of vendor-specific prefixes in content presented to mobile browsers. I am in the process of creating some reports on these but thought I would share the raw data for anyone else who is interested.
METHODOLOGY
Data was collected from approximately 1.1m URLs from 18,025 of the top global sites on the internet, using either the latest Android Browser User-Agent string, or that for the latest version of Mobile Safari.
All CSS from separate .css files, from inline <style> tags, or inline style attributes ("<p style='something'>") was parsed.
FILES
There are two CSV files, compressed using "xz":
*Android*
http://people.mozilla.org/~jjensen/files/bz708406/android.csv.xz
downloaded using the Android ICS Browser User Agent
127m rows
10.3 GB uncompressed
424 MB compressed
*Mobile Safari*
http://people.mozilla.org/~jjensen/files/bz708406/safariios5.csv.xz
downloaded using the Mobile Safari User Agent
128m rows
10.4 GB uncompressed
432 MB compressed
FILE FORMAT
The format of the files is as follows. I've tried to remove as much non-essential data to reduce size.
COL TYPE DESCRIPTION
1 VARCHAR(255) domain
2 VARCHAR(255) rule id (based on md5 of domain, url, and selector)
3 VARCHAR(255) CSS property
5 VARCHAR(255) unprefixed name of the property -- eg if col 3 is '-moz-background-color',
this column is 'background-color'
6 BOOLEAN whether this property has one of -moz-, -webkit-, -o-, -ms-, or -khtml- as a vendor prefix
7 BOOLEAN whether this property has been seen prefixed with vendor-specific variants
SAMPLE LINES
"www.fcc.gov","2da1159edb25a3551842bb1d04865f02","-moz-border-radius-topright","border-radius-topright","1","1"
"www.fcc.gov","026523b977400f615d9e69079f240510","color","color","0","1"
I'll update this ticket with some more reports once I have them.
Reporter | ||
Comment 14•13 years ago
|
||
Please find attached a short text file summarizing the use of vendor-prefixed CSS properties from a sample of pages from the top 18,000 websites globally. It's a short file with content like this:
4919 transition-duration
2427 49.34% -webkit-transition-duration
904 18.38% -moz-transition-duration
753 15.31% -o-transition-duration
442 8.99% -ms-transition-duration
0 0.00% -khtml-transition-duration
393 7.99% unprefixed
This output should be self-explanatory but please let me know if you have any questions.
Comment 15•13 years ago
|
||
Hi John,
I've been reviewing your summary file, and I have a few questions:
(In reply to John Jensen from comment #14)
> 4919 transition-duration
Is this number the total number of occurrences across all the CSS files downloaded from the 18,000 sites? Are you able to say what percentage of sites employ each particular construct?
> 2427 49.34% -webkit-transition-duration
> 904 18.38% -moz-transition-duration
> 753 15.31% -o-transition-duration
> 442 8.99% -ms-transition-duration
> 0 0.00% -khtml-transition-duration
> 393 7.99% unprefixed
These percentages appear to be percentages of occurrences, and so don't tell us the vital information about how many or what percentage of sites are using -webkit but not -moz or unprefixed. Are you able to do some analysis to tell us that?
In particular, I'd love to get the data that goes in this table:
https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility/Mobile
Thanks :-)
Gerv
Reporter | ||
Comment 16•13 years ago
|
||
Gerv,
See below:
[1]: # of sites with a rule using this property, with or without vendor prefix
[2]: # of sites with a rule using ONLY the -webkit- prefix for this property
[3]: # of sites with a rule using the -webkit- prefix AND a bare property
[1] [2] [3]
animation-duration: 73 65 4
animation-iteration-count: 51 44 3
animation-name: 72 64 4
animation-timing-function: 51 49 2
appearance: 431 386 11
background-size: 504 159 134
border-bottom-left-radius: 1359 641 652
border-bottom-right-radius: 1317 580 643
border-radius: 4022 454 2592
border-top-left-radius: 1353 587 679
border-top-right-radius: 1370 656 647
box-shadow: 2446 355 1888
box-sizing: 447 60 197
font-smoothing: 81 78 0
padding-start: 132 16 0
tap-highlight-color: 300 298 1
text-size-adjust: 779 725 3
transform: 405 225 79
transition-duration: 208 149 42
transition-property: 156 116 26
Comment 17•13 years ago
|
||
John: thank you! That's awesome!
I just started some analysis on that data, and I realised I underspecified slightly. Can you confirm that [3] is "Sites using -webkit- and -bare- but NOT using -moz-"? Or did you not check the presence or absence of "-moz-" for column [3]?
Secondly, I have now come across a much more complete list of variant CSS properties:
http://peter.sh/experiments/vendor-prefixed-css-property-overview/
Would you be able to do a similar analysis on all the properties listed there? Here are the column requests for each line in that table:
[1] # of sites using any listed variant of this property
[2] # of occurrences of any listed variant of property (these two together give an idea of
prevalence)
[3] # of sites using one or more (non-moz) prefixed versions but no bare version and no
-moz-prefixed version
[4] # of sites using one or more (non-moz) prefixed versions and a bare version but no
-moz-prefixed version
This does, of course, assume that all uses within a site are consistent. I'm not sure what to do if you find that's not the case. Suggestions?
If we can get this data, we should have a very good idea of where we can get the most bang for the buck in terms of implementing properties.
If [3] is high, then we may be forced to implement/alias the -webkit- (or whatever) property in order to work. If [4] is high, we can get gains from unprefixing our own implementation, if we have one. Looking at [1] and [2], together with our own knowledge of the sort of breakage that missing a property results in, will tell us how much impact we'd have making any fixes for a given property at all.
I will report my simple analysis of the data you've given above in just a moment.
Gerv
Comment 18•13 years ago
|
||
This spreadsheet uses the data just given by John to calculate what numbers and percentages of sites would not work fully in today's Mobile Firefox.
Overall conclusions:
- It _seems_ that the prevalence of prefixed-CSS-related brokenness, at least in the sample of properties given above and in the sample of sites used, is not that high. text-size-adjust is the property with the most sites using it where we wouldn't respect the CSS rule, and that's only 4% of sites.
- Next in the list are the border-radius properties. There's a big difference here in the % brokennesses for border-radius as opposed to border-*-*-radius. That may be an artifact of the fact that the -moz-prefixed version of this property is actually spelt differently - e.g. -moz-border-radius-bottomright, not -moz-border-bottom-right-radius - and perhaps John's checking only looked for a property spelt the same. We supported the moz-prefixed version up to Firefox 2, though, which is quite a long time ago.
After that, it's "appearance", which does have a moz-prefixed version, although most sites don't use it - but I suspect that might be a good thing, because it seems to me that this particular property is not well standardized, the last attempt being in 2004. So just copying syntax from -webkit- to -moz- probably wouldn't help.
Someone with better knowledge of the CSS landscape can perhaps interpret this data better than me :-)
Gerv
Reporter | ||
Comment 19•13 years ago
|
||
> Can you confirm that [3] is "Sites using -webkit- and -bare- but
> NOT using -moz-"? Or did you not check the presence or absence of "-moz-"
> for column [3]?
I did not check for the presence or absence of -moz- at all. -moz- properties (or -o-, -ms-, etc properties) could (and likely are) included in some of the rules and domains in column [3].
> Secondly, I have now come across a much more complete list of variant CSS
> properties:
> http://peter.sh/experiments/vendor-prefixed-css-property-overview/
>
> Would you be able to do a similar analysis on all the properties listed
> there?
Yup, will start it today.
> [1] # of sites using any listed variant of this property
> [2] # of occurrences of any listed variant of property (these two together
> give an idea of
> prevalence)
> [3] # of sites using one or more (non-moz) prefixed versions but no bare
> version and no
> -moz-prefixed version
> [4] # of sites using one or more (non-moz) prefixed versions and a bare
> version but no
> -moz-prefixed version
Comment 20•13 years ago
|
||
John: if [2], [3] and [4] are easier to do in terms of "rules featuring" instead of "occurrences" or "sites" respectively, then that would be fine too.
Doing a possibilities matrix, I've just realised I think we need:
[5] # of sites using a bare version only (no prefixed versions of any kind)
Then any site not in [3], [4] or [5] must be using a moz-prefixed version.
Gerv
(In reply to Gervase Markham [:gerv] from comment #18)
> After that, it's "appearance", which does have a moz-prefixed version,
> although most sites don't use it - but I suspect that might be a good thing,
> because it seems to me that this particular property is not well
> standardized, the last attempt being in 2004. So just copying syntax from
> -webkit- to -moz- probably wouldn't help.
Actually most (or at least a lot) of -webkit-appearance is probably just -webkit-appearance:none to disable theming, which maps exactly to -moz-appearance none.
Reporter | ||
Comment 22•13 years ago
|
||
> Doing a possibilities matrix, I've just realised I think we need:
> [5] # of sites using a bare version only (no prefixed versions of any kind)
[1] through [5] are running now; I'll update the ticket when done.
Comment 23•13 years ago
|
||
roc: that's useful to know. I think that when we get the full data set back from John soon, then we'll want to start looking at property-specific solutions in each of the prominent cases, and that will mean we may need to ask more detailed questions about particular properties (e.g. "What percentage of uses of -webkit-appearance have the value 'none'?").
Gerv
Reporter | ||
Comment 24•13 years ago
|
||
Hi Gerv,
See the attached .txt file.
Reporter | ||
Comment 25•13 years ago
|
||
It turns out that column #5 is inaccurate for some properties. The other columns are correct. I'll update it ASAP.
Comment 26•13 years ago
|
||
John: while you are checking, some other things to look at:
animation-play-state 2 15 1 2 0
This suggests there are 2 sites using this property, with 1 using a non-moz prefix only, and 2 using a non-moz prefix + a bare property. 2 + 1 != 2 :-)
The same issue occurs, more obviously, with box-shadow:
box-shadow 2446 153283 696 1890 0
My analysis is looking interesting; I just need those accurate values for column 5 (they are currently all 0!).
Gerv
Reporter | ||
Comment 27•13 years ago
|
||
Hi Gerv,
Sorry for the delay -- a hard drive failure interrupted processing. I've updated the data, see attached.
Attachment #599705 -
Attachment is obsolete: true
Comment 28•13 years ago
|
||
OK; please find attached my initial analysis. It needs to be taken on from here by someone with a better understanding of the individual CSS properties, their effects and uses, so that they can ask property-specific questions such as "what percentage of uses of "appearance" have the value "none", and so on.
But, looking at the headline figures, it seems to me that the problem of vendor-prefix-only CSS is not yet too widespread in the mobile web. The most prevalent property is "filter", which I guess might be lots of people using -ms-filter to enable PNG transparency or other make-IE-work hacks. The next is "zoom", which is actually implemented unprefixed in WebKit despite being an Apple extension; not sure what people are using that for. After that, the next most popular properties only break us on 4% of sites in the top 18,000.
John: now we've identified some properties of particular interest, it would be good to look at the most commonly-used range of values. In some cases, it may turn out that the property is only used to turn a default feature off, or that we don't have to support the full range for most sites to work.
Can you please develop a script which gives a summary of commonly-used values for a property, both overall and broken down by prefix/no-prefix? And then run it for the top 40 properties in the attached sheet (those with the greatest values for "Sites Not Working")?
Note that we changed the name of the border-radius properties when we unprefixed them, which may be throwing off the analysis and making it look like more sites are broken than actually are. For a sample border radius property, say border-top-right-radius, can you check and see if those sites which appear to be only using prefixes and "not" using moz prefixes, are in fact using the moz-prefixed version which is spelled differently, i.e. in this case -moz-border-radius-topright? Does that change the picture?
Also, can you run exactly the same analysis you just ran, but only over the top 100 mobile sites, and produce an identical sheet? That will give us some idea of whether problems are skewed at the top end (which may be pushing the envelope more), and therefore whether we might be seeing problems more often than these results would suggest.
Thanks!
Gerv
Comment 29•13 years ago
|
||
Reporter | ||
Comment 30•13 years ago
|
||
> Can you please develop a script which gives a summary of commonly-used values for a property,
> both overall and broken down by prefix/no-prefix? And then run it for the top 40 properties
> in the attached sheet (those with the greatest values for "Sites Not Working")?
> Also, can you run exactly the same analysis you just ran, but only over the top 100 mobile
> sites, and produce an identical sheet?
OK; will take a few days, am behind on a few other projects.
Reporter | ||
Comment 31•13 years ago
|
||
> Can you please develop a script which gives a summary of commonly-used values
> for a property,both overall and broken down by prefix/no-prefix? And then run it
> for the top 40 properties in the attached sheet (those with the greatest values
> for "Sites Not Working")?
See attached. Note that all values have been simplified in the following three ways:
1) All numeric values translated to "X". Eg "123px" -> "Xpx"
2) All hex color codes translated to "#XXXX". Eg "#303050" -> "#XXXX"
3) All values between brackets removed. Eg "url(http://this.com)" -> "url()"
Comment 32•13 years ago
|
||
Awesome - thanks John :-)
roc: seems like the next step is for you and your team to look at the data and come up with a plan (or more questions).
Gerv
I think you mean Jet.
To quote from an email I wrote on February 21:
> In particular, the data I've seen so far
> weren't quite measured the right way to answer the question "how
> much will implementing property X with a -webkit- prefix help site
> compatibility?". (In particular, we need to look for how many sites
> have -webkit- prefixed properties and *don't* have equivalent -moz-
> prefixed properties -- and possibly ask the same question again for
> equivalent -moz-prefixed properties or unprefixed properties.)
>
> Then once we have that data we should check a sample of the sites
> that the data predict will be fixed against a build with the
> prefixed properties to see that the benefit is what we think it is.
So what I'd like to see is:
1. a list of the properties that we ought to support either unprefixed or with -webkit- prefixes
2. for each such property, percentages of mobile sites in the sample that we think each would help (as predicted by the data)
3. for each such property, a small random sample of the sites expected to be fixed that we can actually look at the effects on (with a test build) to know what it is we're fixing, both to check that we're measuring the right thing and to characterize how broken the sites are
(Also, 'filter' is probably most likely the hack to support an 'opacity'-equivalent on old versions of IE.)
Also, to continue from the same email:
> Additionally, the plan I'd like to use for (2) is that if we
> determine something is bad enough that we need to support -webkit-
> for mobile, that we:
> a) add -webkit- prefixed support for mobile only
> b) add unprefixed support everywhere
> but I haven't discussed that much with other Mozilla folks. I think
> we're likely to be able to get some other browsers (likely WebKit
> and Opera) to follow on any unprefixing decisions -- but the more
> and better tests we have, the more likely we are to be able to get
> them to follow.
Comment 35•13 years ago
|
||
CCing Jet. Someone take this forward! :-)
The "ought" in dbaron's point 1) is the key question. How do we decide that? We need CSS and web experts to look at the data, the possible effects of support and non-support, the variance between implementations, the likelihood of further change, the effort it would be to support the prefixed version, etc. etc. and then come up with a suggested set of properties to implement which give the most bang for the buck.
Gerv
Comment 36•13 years ago
|
||
We are taking this forward. We know that it's not enough to come with a list of properties to emulate. We're going to prioritize our efforts sorted using a simple equation:
affected_users * pain_level^2
affected_users = (vendor_specific_occurrences - moz_specific_occurrences)
pain_level = (busted_property_multiplier * site_usability)
We square the pain_level to add weight to the relative suffering that a missing property inflicts on affected_users. Using this admittedly subjective formula, we'll find properties that are cosmetic (eg. border-radius) sort after properties that break sites (eg. transform.)
We are working through the W3C to unprefix the worst offenders while we fix bugs in our implementations. At this point, the top of that list includes these properties:
transform-*
transition-*
animation-*
text-size-adjust
John: please see [2] and [3} from comment 34. Can we run this analysis on just the properties I listed?
Reporter | ||
Comment 37•13 years ago
|
||
> John: please see [2] and [3} from comment 34.
> Can we run this analysis on just the properties I listed?
Yes, but sorry, I need a bit more clarity on what that means:
> 2. for each such property, percentages of mobile sites in the sample
> that we think each would help (as predicted by the data)
a) By "mobile site", do you mean "HTML returned to a GET request made with an Android mobile browser UA"? If so, great, that's what I have. If not, please define.
b) Could you/roc define exactly what "that we think would help" means in terms of identifying properties or sites.
> 3. for each such property, a small random sample of the sites expected to be fixed
> that we can actually look at the effects on (with a test build) to know what it
> is we're fixing, both to check that we're measuring the right thing and to characterize
> how broken the sites are
a) I assume this means "produce a tarball of the HTML from the sites identified above". Correct?
(In reply to John Jensen from comment #37)
> > John: please see [2] and [3} from comment 34.
> > Can we run this analysis on just the properties I listed?
>
> Yes, but sorry, I need a bit more clarity on what that means:
>
> > 2. for each such property, percentages of mobile sites in the sample
> > that we think each would help (as predicted by the data)
>
> a) By "mobile site", do you mean "HTML returned to a GET request made with
> an Android mobile browser UA"? If so, great, that's what I have. If not,
> please define.
Sounds good enough.
> b) Could you/roc define exactly what "that we think would help" means in
> terms of identifying properties or sites.
I think measuring whether implementing something unprefixed would help involves, for properties we currently implement with -moz-prefixes, looking at the number of sites that use an unprefixed form of that property without the -moz-prefixed form.
I think measuring whether implementing a -webkit- prefix would help involves looking at, for properties we currently implement either with -moz- prefixes or unprefixed, looking at the number of sites that use a -webkit-prefixed form of that property without the unprefixed form or the -moz-prefixed form.
That said, you've had a lot of discussion above about what to measure; perhaps you have better ideas based on that discussion?
> > 3. for each such property, a small random sample of the sites expected to be fixed
> > that we can actually look at the effects on (with a test build) to know what it
> > is we're fixing, both to check that we're measuring the right thing and to characterize
> > how broken the sites are
>
> a) I assume this means "produce a tarball of the HTML from the sites
> identified above". Correct?
I think URLs would be better.
Reporter | ||
Comment 39•13 years ago
|
||
Gerv, Jet, dbaron, please see attached spreadsheet in OpenDocument format. The meat of it is as below:
base_property num_domains num_rules pct_no_unprefixed_and_no_moz
animation-count 1 1 100.0
animation-delay 5 137 80.0
animation-direction 8 10 62.5
animation-duration 73 324 87.9
animation-fill-mode 2 3 50.0
animation-iteration-count 51 78 84.7
animation-name 72 756 87.6
animation-play-state 2 3 0.0
animation-timing-function 51 100 94.5
text-size-adjust 779 6352 99.5
transform-origin 68 196 56.9
transform-origin-y 2 3 0.0
transform-style 35 50 100.0
transition-delay 19 53 63.2
transition-duration 208 853 71.5
transition-property 156 491 76.2
transition-timing 1 2 0.0
transition-timing-function 45 111 58.9
Sample explanation for text-size adjust:
A total of 779 of 24,510 domains had at least one rule that included “text-size-adjust”.
There were a total of 6,352 such rules across all the 24,510 domains surveyed.
Of the 779 domains, on average, 99.5% CSS rules that had a “text-size-adjust” property did not also include an unprefixed or -moz- version.
Updated•13 years ago
|
Comment 40•13 years ago
|
||
Just wanted to add that we have also 2 non-standard, but implemented unprefixed (in WebKit and MS), to consider: background-position-x and background-position-y.
It is using to achieve spriting images and when it is used, non-supported browsers often render the page in an unusable way.
According this http://lists.w3.org/Archives/Public/www-style/2012Feb/0623.html , it breaks several mobile web sites.
In that case a quick specification (in CSS4 B&B) and an implementation (even prefixed) would help.
Though slightly different for what we are tracking here, this is also something we need to track.
Blocks: layout-compat
Comment 41•13 years ago
|
||
There's a been a lot of analysis on this bug, but the end of when the report is "finished" is not clear. What's left to closeout this bug?
Comment 42•8 years ago
|
||
We can probably close this now!
Updated•6 years ago
|
Summary: Analysis of the use of vendor-specific CSS property prefixes on the web → [meta] Analysis of the use of vendor-specific CSS property prefixes on the web
Comment 43•6 years ago
|
||
Hearing no objection...
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•