Closed Bug 690985 Opened 13 years ago Closed 12 years ago

accept -webkit prefix for all non-yet-standard properties where the implementation matches

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 1170789
blocking-kilimanjaro ?
blocking-basecamp -

People

(Reporter: gal, Unassigned)

Details

Similarly to IE compatibility way back, on mobile WebKit's dominant position is seriously hurting us on web content compatibility. Web authors aren't paying attention to -moz- prefixing. We should accept the -webkit- prefix for all properties we implement identically. I know this isn't fun, but until we have build up some market share for Gecko, this is the only way to deal with the problem.
Is this intended to be restricted to mobile only?
As long we stick to whats compatible, I don't think it would hurt desktop, hence all/all for platform/cpu.
They Said This Day Would Never Come :/
Andreas, the IE team tried this a few years back and got _serious_ flack for it.  The Fennec team also proposed it, but we decided that the PR hit would be too serious.

Are we willing to take this PR hit now?
And for what it's worth, I think the set of -webkit properties that we implement identically is pretty close to empty....
It should be possible to measure this to see how prevalent the problem is, and what css rules are the most often affected. I will chat with bc.

border radius + box shadow, gradients, and transform are what I see most often break. Our gradients are totally different. Do we know yet who is going to win that one?
We shouldn't do this, of course.
Nobody wants to do this. Its a miserable solution all around, but we should strictly go by whether it temporarily improves compatibility. I will try to get some more practical data, and we need to understand #5. If there isn't much it would apply to, the bug is moot. We don't want to match webkit behavior where we disagree on the spec direction.
(In reply to Andreas Gal :gal from comment #8)
> we should strictly go by whether it temporarily improves compatibility.

That's about the worst thing to go by. I thought we still cared about doing the right thing. If temporary compat wins are our highest goal now, how about just using WebKit?
(In reply to Andreas Gal :gal from comment #8)
> we should strictly go by whether it temporarily improves compatibility
temporary improved compatibility is dear-bought with longer living bad coded sites.

If we break this taboo, then we should break another one:
Display a fat user-bothering warning 

> border radius + box shadow
shouldn't WebKit drop support for the prefix here soon?
(Shouldn't we too, BTW? Is there a bug?)
I don't think these properties are that important.
>> border radius + box shadow
> shouldn't WebKit drop support for the prefix here soon?
> (Shouldn't we too, BTW? Is there a bug?)
Unlike us, WebKit doesn't drop support for prefixed version. It's the very reason lazy mobile developers don't care about prefixes other than "-webkit" (and even unprefixed properties).
I think it's important to have a principled approach, not just shortest-path play to win. If we do only that, we can get stuck at a local maximum.

Remember our undetected document.all emulation? The principles there were

1. We never return a truthy value for detection of document.all. That would fall into IE-only JS code paths that want ActiveX, etc.

2. Some pages stupidly use document.all without detecting it, and are doomed to JS errors if we do not emulate undetected document.all. Thus Firefox loses market share (this was in 2004) by not emulating, and strictly gains by emulating.

3. We emulate undetected document.all only in quirks mode.

There is a slippery slope, but let's argue fairly. Comment 10 is off base talking about random "taboos". Comment 9 is too vague -- what is "the right thing?" De-jure standards only are not enough in competitive markets with de-jure standards.

Comment 11 amkes a good point. We should be hammering WebKit's owners to remove prefixes, but I take it from comment 5, there is not enough agreement on semantics for the unprefixed properties. But why is that? Didn't WebKit create a de-facto standard? Who are we kidding, doing soemthing different for gradients? Or are non-WebKit browser vendors all agreed on a better way? Even so, years late and mega-dollars short.

So I propose we measure first, but also work to get prefixes removed, which means making de-jure standards of de-facto ones instead of dragging out a de-jure fight while -webkit prefixes proliferate. Finally, if we do emulate, we should try to follow the undetected document.all emulation principles:

* emulate only where failure not fallback is likely (not sure how to discern this -- definitely could mean on mobile only);

* emulate only in quirks mode if possible.

/be
> De-jure standards only are not enough in competitive markets with de-jure standards.

Obviously I meant to write "De-jure standards only are not enough in competitive markets with de-facto standards." Ah, third day jetlag...

/be
> and what css rules are the most often affected.

That would be good data, yes.

> border radius + box shadow, gradients, and transform are what I see most often break.

None of those are actually compatible between WebKit and Gecko outside the simplest cases.  Gradients most obviously, but we have slightly different syntax for transform, different interpretation of the same syntax for box shadow, and iirc border radius is also different once elliptical corners are involved.

> We should be hammering WebKit's owners to remove prefixes

They have a policy of never doing that.  Ever.  They add the unprefixed properties, but keep the prefixed ones because otherwise they'd break all the software that uses system-webkit on Mac or something.  <sigh>.

> there is not enough agreement on semantics for the unprefixed properties

Or there is agreement and they haven't implemented it yet, in some cases.

> Didn't WebKit create a de-facto standard?

For border-radius?  Not so much, no.

> Or are non-WebKit browser vendors all agreed on a better way?

For gradients, yes.  So are the WebKit folks; they think their old syntax is not as good as what's in the spec.

Note that some of the de-facto stuff that WebKit ships is _really_ broken.  They're strong believers in worse-is-better and prefixes let them do that... but standardizing something that's completely broken in an RTL environment most likely just won't fly, for example.
(In reply to Boris Zbarsky (:bz) from comment #14)
> > there is not enough agreement on semantics for the unprefixed properties

This is the case for transforms.

> Or there is agreement and they haven't implemented it yet, in some cases.

Whereas this is the case for box-shadow (and if they're incompatible with us for border-radius, which I haven't heard before, for border-radius as well).

For gradients, we've both been somewhat-keeping-up with the evolution of the spec, but they've been keeping their old prefixed form.
Component: DOM → Style System (CSS)
QA Contact: general → style-system
Also, box-shadow and border-radius are widely supported *unprefixed* as well.  We're at the point where we should be dropping our prefixed support.

And I recently wrote and submitted a testcase for a major area of incompatibility with box-shadow (the definition of blur radius, which the working group spent a substantial amount of time discussing in 2009 or so and came to an agreement):
http://test.csswg.org/source/contributors/mozilla/submitted/css3-background/box-shadow/box-shadow-blur-definition-001.xht
... I need to work on pushing other browsers to match that agreement.
Just to clarify, does webkit make their old prefix match the final spec, or do they have old and new (unprefixed) syntax usually?
WebKit keeps the prefixed version matching what it originally supported, rather than the spec.

For Gecko, I try to avoid too much churn in the stages of getting to match the final spec; for example right now I'd like to avoid dropping support for the dropped features of Gradients until we can unprefix at the same time.  This means authors are forced to update fewer times.  And for things commonly used prefixed, we leave our support for prefixes for a period of time after adding unprefixed support (especially when we added that unprefixed support late in a release cycle, back before rapid release) -- but even when we do that we change it to match the final spec.  (Though gradients might be painful there; we'll see.)
(In reply to Andreas Gal :gal from comment #6)
> border radius + box shadow, gradients, and transform are what I see most
> often break. Our gradients are totally different.

Were you talking about old-style Webkit gradients (-webkit-gradient(linear/radial, ...)) or new-style, spec-ish Webkit gradients (-webkit-linear-gradient, -webkit-radial-gradient) which are much more like ours?

I think we could have a pref that enables treating -webkit as -moz for a certain set of properties. That'd be cheap and it would be interesting to see how much it helps (or hurts). However, it'd be an enormous leap to ship it enabled by default. Maybe we could do something horrible like whitelist it for certain sites.

I would not be interested at all in specifically reverse-engineering Webkit and adding new implementations that match their behavior. That's a treadmill and not a good use of our resources.
Before considering to "fix" this bug (even before filing it), consider this: 

Try to convince WebKit to do add warnings about obsolete -webkit-prefixes (if they don't want to remove supporting them).

And/or

Add warnings in Gecko if -webkit-prefixes are found for properties that have non-prefixed and interoperable working counterparts.
(In reply to j.j. from comment #20)
> Before considering to "fix" this bug (even before filing it),

No, wrong bug. Warnings are irrelevant -- they nag indiscriminately and developers either ignore them or actually disagree with them.

This bug is effective compatibility measures now, not warnings.

/be
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #19)
> I think we could have a pref that enables treating -webkit as -moz for a
> certain set of properties. That'd be cheap and it would be interesting to
> see how much it helps (or hurts). However, it'd be an enormous leap to ship
> it enabled by default. Maybe we could do something horrible like whitelist
> it for certain sites.

Why disadvantage ourselves with a pref or a whitelist?

> I would not be interested at all in specifically reverse-engineering Webkit
> and adding new implementations that match their behavior. That's a treadmill
> and not a good use of our resources.

We could go a long way by merely treating -webkit-foo as an alias for our foo. Web authors already treat -webkit-foo, -moz-foo, -o-foo, -ms-foo and foo as being similar enough most of the time.

My full take on this didn't fit in a Bugzilla comment: http://hsivonen.iki.fi/vendor-prefixes/
Bob, John: do we have good enough data to share here? I'm hoping we can make progress in this bug soon: data, analysis, plan of action, dependent bugs, patches. Data first is good ;-).

/be
I think John has the prefix data.
A summary of the analysis I conducted of vendor-specific prefixes is attached to bug 708406. I am also in the process of collecting a much larger sample from the top 18,000 sites on the web (currently around 1m HTML pages and 20K CSS files). I'd be happy to produce more specific analyses -- just let me know what you are looking for.
blocking-basecamp: --- → ?
blocking-kilimanjaro: --- → ?
I think what I'd like to know is
 - what % of "sites" served to the Firefox Android UA include -webkit-prefixed properties but not the -moz ~analogues.  I.e., what would we win by adding the -webkit hacks, out of the box.
 - what % of "sites" served to the Android and iOS UAs include -webkit-prefixed properties but not the -moz ~analogues.  I.e., what can we expect to win from the minimum amount success of evangelizing Firefox Android to web admins (update sniffing rules but no real changes).
(In reply to Chris Jones [:cjones] [:warhammer] from comment #26)
> I think what I'd like to know is
>  - what % of "sites" served to the Firefox Android UA include
> -webkit-prefixed properties but not the -moz ~analogues.  I.e., what would
> we win by adding the -webkit hacks, out of the box.
>  - what % of "sites" served to the Android and iOS UAs include
> -webkit-prefixed properties but not the -moz ~analogues.  I.e., what can we
> expect to win from the minimum amount success of evangelizing Firefox
> Android to web admins (update sniffing rules but no real changes).

That sounds like a question for bug 708406. I'd ask it there to John Jensen.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #26)

Chris, that info is indeed buried within bug 708406.
That doesn't tell you whether that's the only issue preventing the site from working in Gecko (or, for that matter, doesn't tell you whether it causes a noticeable problem in Gecko).  See bug 708406 comment 34.
(In reply to David Baron [:dbaron] from comment #29)
> That doesn't tell you whether that's the only issue preventing the site from
> working in Gecko (or, for that matter, doesn't tell you whether it causes a
> noticeable problem in Gecko).  See bug 708406 comment 34.

Correct. To complicate things further, some CSS properties are problematic in of themselves, for some properties only certain values are problematic, some properties cause minor disturbances in page, others cause major site breakage. On top of this, getting the CSS right is no guarantee that the site will function. 

There is no way we can say with 100% certainty that treating a -webkit property as an alias for a -moz property will result in X number of sites suddenly functioning as desired on Gecko. We can make an educated decision based on the data that John has put together.

To that end, I had previously asked John to create a prioritized list of CSS properties that we should support. The recommendations in the list show the number of sites that will be "fixed" (where fixed means that the site no longer has problematic CSS property usage according to the definitions that John used in his analysis) by supporting each property. If memory serves, this data set shows when a -webkit CSS property is in use without a -moz or unprefixed equivalent property.
https://docs.google.com/spreadsheet/ccc?key=0AushOZLFQoR0dEJNVzhFMGhqcXVxX203YVB4ckp2V2c#gid=0
Opera has now implemented this in 12.50 snapshot: http://my.opera.com/desktopteam/blog/2012/07/06/marlin-1250-swim


-webkit-box-shadow, -webkit-transform, -webkit-transform-origin, -webkit-border-radius, -webkit-border-top-left-radius, -webkit-border-top-right-radius, -webkit-border-bottom-left-radius, -webkit-border-bottom-right-radius, -webkit-transition, -webkit-transition-delay, -webkit-transition-duration, -webkit-transition-property, and -webkit-transition-timing-function
The Layout and QA teams are investigating the usefulness of aliasing Webkit CSS properties will have on compatibility. We should have more data in a week or two to aid in this decision.

I recommend leaving this as blocking-basecamp? until we have the data to support the decision.
Whiteboard: [blocked-on-input]
Blocked by 775235. We've decided to unprefix any CSS before we consider multi-vendor aliasing.
Depends on: unprefix
(In reply to Jet Villegas (:jet) from comment #33)
> Blocked by 775235. We've decided to unprefix any CSS before we consider
> multi-vendor aliasing.

Jet, let me rephrase in order to try and clarify. Is the following correct? 

We have decided that a CSS property must be unprefixed before we will consider multi-vendor aliasing for that specific property.
blocking-basecamp: ? → -
(In reply to Lawrence Mandel [:lmandel] from comment #34)
> We have decided that a CSS property must be unprefixed before we will
> consider multi-vendor aliasing for that specific property.

Yes, that is correct.
Thanks Jet & Lawrence. What does that mean for this bug?
(In reply to Dietrich Ayala (:dietrich) from comment #36)
> Thanks Jet & Lawrence. What does that mean for this bug?

This means that we can consider aliasing any property once it has been unprefixed.
So we're handling it property by property, which sounds like this bug is WONTFIX, since it's asking for all to be aliased.
(In reply to Dietrich Ayala (:dietrich) from comment #38)
> So we're handling it property by property, which sounds like this bug is
> WONTFIX, since it's asking for all to be aliased.

Right, that sounds right to me based on QA's investigation with John's marketing data integrated. Marking as such.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Whiteboard: [blocked-on-input]
Status: RESOLVED → VERIFIED
Resolution: WONTFIX → DUPLICATE
No longer depends on: unprefix, 708406
You need to log in before you can comment on or make changes to this bug.