David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Description • 13 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 13 years ago

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?

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 13 years ago

Over to David to actually land sometime.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 3 • 12 years ago

I'd have pushed to try, but it's closed.

	Dave Townsend [:mossop]
	Comment 4 • 12 years ago

Gregg, this latest patch affects the feedback code, you probably want to upstream it.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 5 • 12 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/9dd4c4a72f43
https://hg.mozilla.org/integration/mozilla-inbound/rev/bffddfedcaf7

	Ed Morley [:emorley]
	Comment 6 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/bffddfedcaf7

	Ed Morley [:emorley]
	Comment 7 • 12 years ago

Sorry, and:
https://hg.mozilla.org/mozilla-central/rev/9dd4c4a72f43

	zigboom
	Comment 8 • 12 years ago

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.

	j.j.
	Comment 9 • 12 years ago

(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?

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Assignee
	Comment 10 • 12 years ago

(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.

	Frank Lion
	Comment 11 • 12 years ago

(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?

	rob64rock
	Comment 12 • 12 years ago

(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.

	Jean-Yves Perrier [:teoli]
	Comment 13 • 12 years ago

I've updated:
https://developer.mozilla.org/en/CSS/border-radius
https://developer.mozilla.org/en/CSS/border-top-left-radius
https://developer.mozilla.org/en/CSS/border-top-right-radius
https://developer.mozilla.org/en/CSS/border-bottom-right-radius
https://developer.mozilla.org/en/CSS/border-bottom-left-radius
https://developer.mozilla.org/en/CSS/box-shadow
and there is a mention in:
https://developer.mozilla.org/en/Firefox_13_for_developers

	Jack Roberts
	Comment 14 • 12 years ago

What a ridiculous justification for removing legacy border-radius support. pfft.

	j.j.
	Comment 15 • 12 years ago

(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

	Jack Roberts
	Comment 16 • 12 years ago

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?

	j.j.
	Comment 17 • 12 years ago

(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

	Dave Townsend [:mossop]
	Comment 18 • 12 years ago

(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.

	James Edward Lewis II
	Comment 19 • 12 years ago

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.

	Dan Ancona
	Comment 20 • 12 years ago

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)