I want to add preferences for sets of prefixed properties (which are going to be among the more difficult prefixes to get rid of) as a way to ease the path towards disabling those prefixes. This will allow: * authors (or other testers) to test what happens when the prefixed property support is removed * easy landing and backout of the final patch in case we have to slip it across releases

Comment on attachment 674585 [details] [diff] [review] Add preferences (defaulting to enabled, for now) to control whether certain prefixed aliases for CSS properties are supported, so that authors can have a way to test what happens when they're turned off in advance of our disabling them. () r=me

https://hg.mozilla.org/mozilla-central/rev/f3d0e95c83ee Should this have tests?

FWIW, I plan to blog about this (assuming I remember) after it hits the release channel.

Blog post: http://dbaron.org/log/20130225-removing-prefixes

Ms2ger discovered (and I verified) that turning this on breaks styling of tabs in Firefox 20. :-(

Comment on attachment 718188 [details] [diff] [review] , patch 2: Also condition @-moz-keyframes parsing on the animations preference. r=me

> turning this on breaks styling of tabs in Firefox 20. :-( Not surprising; our UI has a tendency to use -moz-prefixed stuff before the unprefixed versions are available. The good news is that we can easily search-and-replace our UI. ;)

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #7) > Blog post: http://dbaron.org/log/20130225-removing-prefixes Added the link: https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_19

patch 2 landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/6ff3de859ce3

er, backed out, because it depended on unlanded patches: https://hg.mozilla.org/integration/mozilla-inbound/rev/cc6c725d463d

If this is backed out it probably should not be set to RESOLVED FIXED.

The bulk of it is still fixed, just the one thing I missed that's not.