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)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jjensen, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: meta)

Attachments

(10 files, 1 obsolete file)

Short report in OpenOffice Impress format
102.69 KB, application/vnd.oasis.opendocument.presentation
Details
Report in PDF format
153.46 KB, application/pdf
Details
Summary data in text format
52.34 KB, text/plain
Details
Updated summary with better descriptions of some of the tables
36.81 KB, text/plain
Details
Summary of use of vendor-specific prefixes from CSS collected with Safari and Android Browser UA strings
45.20 KB, text/plain
Details
WebKit CSS - brief broken/working analysis
18.26 KB, application/vnd.oasis.opendocument.spreadsheet
Details
More detailed summary of vendor-specific prefixes
8.85 KB, text/plain
Details
CSS vendor-prefixed property analysis (18,000 sites)
29.66 KB, application/vnd.oasis.opendocument.spreadsheet
Details
Value summary of subset of vendor-prefixed properties
110.62 KB, text/csv
Details
ODS Spreadsheet summarizing per-domain and per-property prefixed and unprefixed statistics
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.
Attached file Report in PDF format —
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
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
Keywords: meta
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
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
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
(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)
(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
...and has been moved to: http://people.mozilla.com/~jjensen/css.csv.gz
The wiki discussion referencing this ticket can be found at https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility
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.
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.
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
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
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
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
> 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
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.
> 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.
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
Hi Gerv, See the attached .txt file.
It turns out that column #5 is inaccurate for some properties. The other columns are correct. I'll update it ASAP.
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
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
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
> 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.
> 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()"
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
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.
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
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?
> 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.
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.
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.
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?
We can probably close this now!
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
Hearing no objection...
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
No longer blocks: 690985
Blocks: 1170789
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: