Closed Bug 804944 Opened 7 years ago Closed 7 years ago
add preferences for sets of CSS prefixed properties
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
Attachment #674585 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/f3d0e95c83ee Should this have tests?
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
FWIW, I plan to blog about this (assuming I remember) after it hits the release channel.
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
Attachment #718188 - Flags: review?(bzbarsky) → review+
> 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
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.
You need to log in before you can comment on or make changes to this bug.