

Stop Forking with CSS3 - audionerd
http://www.alistapart.com/articles/stop-forking-with-css3/

======
samdk
I'm really not impressed with this implementation, at least. Cleaner syntax,
maybe, but at the cost of _five_ more JavaScript files for one of the
examples. And it looks different in the latest non-beta versions of Chrome,
Firefox, and IE, so it's not any better there either.

If you really dislike having to use multiple properties that much, you can
deal with the syntax problem on the development side by using something like
Sass. I much prefer that to adding five more unnecessary HTTP requests.

The -vendor prefixes are a pain, but they _do_ exist for a reason. Firefox, at
least, uses them when the implementations of the properties aren't yet bug-
free/don't completely match the spec. -moz-border-radius, for example, has
some issues with very large borders that are different colors:
<http://basicio.com/snippets/moz_border_radius/>.

~~~
TrevorBurnham
To be fair, it makes sense to offer five distinct feature sets as five
different JS files; just pick the ones you need and concatenate them in
production.

I favor the Sass route as well, but that's not going to give me, say, rounded
corners in IE8. I'd need to use JS to accomplish that. When you say the
examples look different in the latest non-beta versions of major browsers,
what do you mean specifically?

~~~
samdk
There are two examples listed: <http://ecsstender.org/> and
<http://ecsstender.org/demos/spoon/>.

On Firefox 3.6, they both hang (for several seconds) as the JS loads/comes
into effect (and the "stop unresponsive script" box comes up). After it does
finally load, the first looks fine, but the second doesn't animate smoothly on
hover, and a scrollbar appears when you hover over the box, which really
shouldn't happen.

On Chrome, they both _work_ fine, but are missing drop shadows.

On IE8, the first loads fine, but not of the special effects (rounded corners,
drop shadows) actually works. The second...well, I think that's best described
with a screenshot: <http://i.imgur.com/ZjPNs.jpg> (there's no hover effect at
all).

All browsers are fully up-to-date. Unless I'm missing something, this really
isn't even at all functional.

~~~
TrevorBurnham
Ouch. Thanks for taking the time to test.

------
thwarted
You're doing it wrong. Vendor prefixes are not forks, they are test beds. If a
designer uses vendor prefixes in production code, they're setting themselves
up to have to maintain them when browser vendors eventually remove them. This
is the price you pay for ABSOLUTELY NEEDING CSS3 FEATURES NOW, OMG, JUST DO
IT! OUR APP IS NOT COMPLETE WITHOUT ROUNDED CORNERS! or whichever CSS3 feature
you didn't need before CSS3 was conceived of.

And wrapping up their use in a library that is meant to spackle over
differences in vendor prefix property implementation is even worse, since it
hides what is meant to be public for trying things out. You wanna get vendor
prefixes removed? Work on converting your site to use them for testing
purposes and report bugs and your opinions as to how you think things should
work: providing your real world use cases is much more constructive than
covering up differences in things which are, by design, supposed to be
different.

That being said, any browser that claims to support CSS3 but only through
vendor prefixes is lying. Which means that any vendor who claims CSS3 support
for things that have not been finalized or agreed upon or that don't work like
they should is lying.

Incidentally, I expect more from alistapart. Encouraging the use of vendor
prefix stuff in production files ends up delaying the standardization process.

