bq. Just to note, internet explorer is still the most used browser (if you put ie6 plus ie7 plus ie8 market quote), and if you work with medical related websites, you should multiply those percentage.
And that’s why many extensions are working to back-port things like full CSS3 selector support for IE. You’ll also find that that things like CSS rotation do work in IE6. We’re still working on a solution for dynamically managing an @-ms-filter@ stack, which is why the spoon demo won’t currently work in IE, but we’ll have a solution for that in eCSStender 1.3.
bq. Safari 5.0 does not have a drop shadow on the boxes. Firefox 3.2.3 doesn’t animate the box rotation. Also, I can’t see the “˜download’ button on the eCSStender home page (maybe you are moving the image to a different server?).
I can’t replicate the Safari issue you’re having on Mac or Windows (Safari 5 did change some innards of its @box-shadow@ support between 4 and 5, but we patched that in the extension). Chrome seems to suffer from that problem though (but Android, Dolphin, and xScope on my Nexus One don’t… go figure). Perhaps a refresh will fix that for you?
As for Firefox… Firefox doesn’t support CSS transitions in that version (or any non-beta release AFAIK). Some smart folks are working on extrapolating the simple extension I put together into a more robust JS-based animated fallback as we speak.
And on the download button… that was the issue, yes. It should be there now.
bq. if you are advocating removing the forks from CSS files wouldn’t the last section of the article and the idea for developing eCSStender in the first place have the same effect as many forks in the CSS file?
If it is the only implementation of something experimental, there are no forks to be had. Just as @-ms-filter@ is not a fork (no other browser that I’m aware of implements filter either with or without an vendor-specific prefix), neither is @-easy-physics-fill@.
bq. The article conflates vendor specific extensions with CSS hacks that rely on vulnerable CSS parsers. I think this is a mistake. Vendor specific extensions are invalid but only because they use property names that are outside the CSS standards.
I never said they were _invalid_, I simply think that having to write the same thing 3 different ways is _undesirable_. eCSStender is not an attempt to jettison vendor-specific prefixes, far from it. eCSStender is about making things better for designers from an authoring standpoint by equalizing browser support, back-porting newer CSS functionality to older browsers, and creating a mechanism for experimenting with the future of the language.