Last Comment Bug 693510 - drop support for prefixes from border-radius* and box-shadow
: drop support for prefixes from border-radius* and box-shadow
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P3 normal with 1 vote (vote)
: mozilla13
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
:
Mentors:
Depends on:
Blocks: 729971
  Show dependency treegraph
 
Reported: 2011-10-10 18:34 PDT by David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
Modified: 2012-06-20 16:25 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (2.85 KB, patch)
2011-10-10 18:34 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
bzbarsky: review+
Details | Diff | Splinter Review
fix the uses that have crept back in to the tree (42.46 KB, patch)
2012-02-16 16:23 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
dtownsend: review+
Details | Diff | Splinter Review

Description David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2011-10-10 18:34:32 PDT
Created attachment 566107 [details] [diff] [review]
patch

We've supported border-radius and box-shadow unprefixed since Firefox 4, but we've kept support for the prefixed versions as aliases.  It's time to remove those aliases.

This is the main patch (which I've had sitting in my tree for a while), but we also need patches to deal with most of:
http://mxr.mozilla.org/mozilla-central/search?string=moz-box-shadow
http://mxr.mozilla.org/mozilla-central/search?string=moz-border-radius
Comment 1 Boris Zbarsky [:bz] 2011-10-11 20:08:13 PDT
Comment on attachment 566107 [details] [diff] [review]
patch

r=me but maybe we should just have a SUPPORT_CSS_ALIASES that's not defined until we add some or something?
Comment 2 Boris Zbarsky [:bz] 2012-01-26 09:49:05 PST
Over to David to actually land sometime.
Comment 3 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2012-02-16 16:23:12 PST
Created attachment 598054 [details] [diff] [review]
fix the uses that have crept back in to the tree

I'd have pushed to try, but it's closed.
Comment 4 Dave Townsend [:mossop] 2012-02-22 10:29:08 PST
Gregg, this latest patch affects the feedback code, you probably want to upstream it.
Comment 5 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2012-02-22 14:17:32 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/9dd4c4a72f43
https://hg.mozilla.org/integration/mozilla-inbound/rev/bffddfedcaf7
Comment 6 Ed Morley [:emorley] 2012-02-23 13:21:35 PST
https://hg.mozilla.org/mozilla-central/rev/bffddfedcaf7
Comment 7 Ed Morley [:emorley] 2012-02-23 13:21:54 PST
Sorry, and:
https://hg.mozilla.org/mozilla-central/rev/9dd4c4a72f43
Comment 8 zigboom 2012-02-25 01:08:22 PST
As a Theme Developer that have more thank 800,000 daily users, I'd like to protest against this bug. 

My themes have code that goes back much before FF4 and of course it includes a lot of -moz pre-fixes. This decision forces me to invest hours in order to find all the -moz uses and to replace them across 5 themes. 

Maybe you guys forgot that there are many theme & add-on developers that have other work to do and hardly find time to maintain their projects. Why do you need to force all these unproductive work-hours on us? we could use this time in a much better way than running around our code and replacing those references, just so our projects won't break (there's definitely no added value for the users). We could create something meaningful instead. 

This isn't the way to support a community of developers. I'm starting to feel that we're not supported or even thought of. For example, I'm developing for Facebook too and when they make a change like this, they give many months for the developers to adjust and make sure everyone knows about it. Anyway, when they do, it's for a good reason that upgrades the user experience eventually. 

I think I've explained the down side on the developer's side, maybe someone representing Mozilla could explain what's the down side of keeping the legacy support? I hope it's not too late to reverse this decision.
Comment 9 j.j. 2012-02-25 06:03:18 PST
(In reply to zigboom from comment #8)
> As a Theme Developer that have more thank 800,000 daily users, I'd like to
> protest against this bug. 
> 
> My themes have code that goes back much before FF4 and of course it includes
> a lot of -moz pre-fixes. This decision forces me to invest hours in order to
> find all the -moz uses and to replace them across 5 themes.

You have to do this anyway unless you don't want to support IE9, IE10 and Opera, no?
Comment 10 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2012-02-25 09:46:59 PST
(In reply to zigboom from comment #8)
> I think I've explained the down side on the developer's side, maybe someone
> representing Mozilla could explain what's the down side of keeping the
> legacy support? I hope it's not too late to reverse this decision.

The downside of keeping the legacy support is that we support -moz- prefixed properties for Web content, which encourages Web authors to do the same thing you've done -- write browser-specific CSS and (which I think you haven't, if by "Theme" you mean a Firefox Theme) put it on the Web.  This, in turn, makes it harder for new entrants in the Web browser market, which reduces competition and thus innovation on the Web -- which is directly against the Mozilla organization's primary mission.

Removing support for the prefixes forces those Web authors who weren't already aware (as they should have been) that they need to support the unprefixed form of these properties.
Comment 11 Frank Lion 2012-02-25 18:02:30 PST
(In reply to j.j. (inactive in 2012) from comment #9)
> (In reply to zigboom from comment #8)
> > As a Theme Developer that have more thank 800,000 daily users, I'd like to
> > protest against this bug. 
> > 
> > My themes have code that goes back much before FF4 and of course it includes
> > a lot of -moz pre-fixes. This decision forces me to invest hours in order to
> > find all the -moz uses and to replace them across 5 themes.
> 
> You have to do this anyway unless you don't want to support IE9, IE10 and
> Opera, no?

...and you've seen a lot of Firefox themes supporting IE9, IE10 and Opera,have you?
Comment 12 rob64rock 2012-02-25 18:23:11 PST
(In reply to Frank Lion from comment #11)
> (In reply to j.j. (inactive in 2012) from comment #9)
> > (In reply to zigboom from comment #8)
> > > As a Theme Developer that have more thank 800,000 daily users, I'd like to
> > > protest against this bug. 
> > > 
> > > My themes have code that goes back much before FF4 and of course it includes
> > > a lot of -moz pre-fixes. This decision forces me to invest hours in order to
> > > find all the -moz uses and to replace them across 5 themes.
> > 
> > You have to do this anyway unless you don't want to support IE9, IE10 and
> > Opera, no?
> 
> ...and you've seen a lot of Firefox themes supporting IE9, IE10 and
> Opera,have you?

I haven't, basically Firefox Themes Developers should been informed when trying to keep Legacy Theme support(Fx 3.6 and prior) when Fx4 was released not to combined Legacy Theme support under one Fx Theme version.(Have a Fx Theme version up to Fx 3.6 and a Fx Theme version for Fx 4+)Which a lot of Theme developers have said it makes it easier to keep up with Fx UI changes post Fx 3.6 without having to muck around the Fx Legacy Themes coding.
Comment 14 Jack Roberts 2012-06-08 08:42:13 PDT
What a ridiculous justification for removing legacy border-radius support. pfft.
Comment 15 j.j. 2012-06-08 10:54:05 PDT
(In reply to Jack Roberts from comment #14)
> What a ridiculous justification for removing legacy border-radius support.
> pfft.

Removing -moz-prefixes was always done some time after unprefixed properties were supported, there is nothing new.
Removing it avoids various problems and isn't ridiculous at all.

If you are interested to learn about those problems start with searching for "prefixing" or "prefixes" here:
http://www.w3.org/Search/Mail/Public/search?type-index=www-style
Comment 16 Jack Roberts 2012-06-08 11:36:49 PDT
Of course there is going to be 1000s of search results for the word prefixes in a CSS related mailing list. 

The justification given above was that it is mozilla's mission to create more competition in the browser market, by forcing theme developers to make their themes work in other browsers. This is the ridiculous justification that i was referring to. But now you have said that there is various problems that are solved by removing moz prefix support. Then you advise me to search a mailing list for the generic term "prefixes", are you serious?
Comment 17 j.j. 2012-06-08 14:23:58 PDT
(In reply to Jack Roberts from comment #16)
> Then you advise me
> to search a mailing list for the generic term "prefixes", are you serious?

More specific links (with focus on recent problems):
http://hsivonen.iki.fi/vendor-prefixes/
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/itl6mtx2dxI
Comment 18 Dave Townsend [:mossop] 2012-06-08 16:13:23 PDT
(In reply to Jack Roberts from comment #16)
> The justification given above was that it is mozilla's mission to create
> more competition in the browser market, by forcing theme developers to make
> their themes work in other browsers.

There were a few crossed lines in comments in this bug. It's done because that is what the CSS specs say to do so that web content is forced to use CSS rules that work in every browser. The fact that it impacts themes is really only a side effect of the fact that themes use the same CSS parser as web content.
Comment 19 James Edward Lewis II 2012-06-16 22:03:49 PDT
I read a lot of whining in this comment-thread from people who made extensive use of vendor-prefixed CSS without future-proofing with the unprefixed versions, ignorant of the fact that the prefixed versions were always meant to be temporary and future-proofing is an obvious best practice.

In short, the whiners had cut corners early on and expected it to always work; the moral is that when the vendors say their prefixes are temporary, they're not kidding.
Comment 20 Dan Ancona 2012-06-20 16:25:06 PDT
Fine, prefixes are considered harmful. But doesn't dropping support for existing ones that are in fairly widespread use break the principle of "Support Existing Content?" (from the hsivonen.iki.fi link above)

Note You need to log in before you can comment on or make changes to this bug.