RE: Dropping Prefixes Early on Transforms/Transitions/Animations

[Aryeh Gregor:]
> 
> On Fri, Feb 17, 2012 at 2:08 PM, Sylvain Galineau <sylvaing@microsoft.com>
> wrote:
> > I think it can help somewhat, actually. If you need to work around one
> > browser's bug or rendering issue by tweaking the value and the new
> > value is still valid for the other UAs, you either end up falling back
> > to what the buggy UA accepts across the board, or you'll do what
> > prefixes do - browser sniffing - in much uglier ways.
> 
> To the contrary -- browser-sniffing based on the UA string is much less
> ugly.  

To whom? I can't even count the number of bugs due to browser-sniffing done
badly (bad regex, not updated to account for new browsers, breaks when a vendor's
release number moves to two digits...).

> Browser-sniffing using prefixes means you have to use the prefixes
> even when you don't want to UA-sniff.  
Er, except you want to UA-sniff since you're targeting browser-specific version
of a feature. Again, the scenario here is that one or more UAs don't render a
given value right.

> This means that 1) your code is
> much more verbose even in the common case where you want a simple effect
> that's more or less interoperable, 
Again, the scenario here is that what you want is not 'more or less interoperable'.
There is a problem you need to work around.

>and 2) in the rare case where you do
> want to give different markup to different browsers, nobody will notice
> because they're not going to spot the difference in the long otherwise-
> identical lines.  
Why is that relevant to the guy building the page and trying to workaround some
UA's buggy rendering?

> It also means that you're doing engine detection instead
> of feature detection, which is bad.
Statements that 'it's bad' are also not that relevant or helpful to the guy delivering
a web site. That is overwhelmingly borne out by the many site issues I've had to debug
with every release.

> 
> If the point of prefixes is only to allow UA-sniffing to get around bugs
> after the syntax is solidified, then browsers should all just implement
> both prefixed and unprefixed versions.  That way you can use the
> unprefixed version in most cases, and if one browser has a bug you want to
> work around, you can use the prefixed version to override its behavior.
> This argument doesn't justify browsers not supporting the unprefixed
> version.
Well, that was exactly my point i.e. prefixes do help in that case. But maybe
your proposal here is the novel one in this old topic i.e. what if browser implement
new features both behind and without a prefix? Values that do interop will work
as-is unprefixed. Those that don't and other changes can be targeted using the
UA-specific prefixed property i.e. the prefix property is a fallback if and when
a browser needs a targeted workaround instead of being the only available way to
use the feature.

> 
> Also, allowing authors to browser-sniff using prefixes is too crude to be
> a replacement for real browser sniffing.  It doesn't let you distinguish
> browser versions.  
If you need to distinguish browser versions then not having prefixes is of
no help either. It may be true that browser sniffing is the 'better' solution
from a strictly technical standpoint but there is compelling evidence that many
authors are even more likely to get it wrong than they do vendor prefixes. Not
very appealing as a 'fix' to me.

Received on Monday, 20 February 2012 22:45:17 UTC