>To achieve these effects, I needed a small truckload of CSS
You:
>Once the standards go final and the browsers get compliant implementations, the vendor prefixes will go away.
So the implementation is excessively long, temporary, and to be changed to something more standards compliant at a later date. Seems like the definition of "ugly hack" to me.
And I'm not talking about supporting an outdated browser like IE6 here. I'm talking about a browser whose public releases support more "pure CSS3" than both Gecko and WebKit.
So the implementation is excessively long, temporary, and to be changed to something more standards compliant at a later date. Seems like the definition of "ugly hack" to me.
The idea is that until the standard goes final and the implementation has been checked against it, you can't know that the implementation is correct or even that the syntax for the feature will be the same in the final version. So rather than yank the rug out from under people later on, you use a vendor prefix until the standard is finalized and the implementation's checked out. Then people can drop the vendor prefix.
I'm talking about a browser whose public releases support more "pure CSS3" than both Gecko and WebKit.
And... well, Opera's doing it wrong. CSS3 is not finalized. CSS3 may go final with subtle or even significant differences from the current spec. And then anyone who relied on Opera's implementation and patted themselves on the back for being so ahead of the game will instead be up a creek.
My implication was to do something standards compliant and browser-neutral like 1px wide PNGs and (for the super fancy) JavaScript. Avoid non-standard CSS hacks entirely. It has a higher chance of breaking and not-working because, as you said, CSS3 is not finalized.
I wouldn't care if it was supposed to be some sort of academic tech-demo, but in the comments the author says:
>On Posterous they are going to be used in many places
edit: moral: JavaScript enabled\disabled is 1 axis of degradation. Non-standard CSS3 hacks have 3 axises: Browser type, browser version, state of CSS3 spec. It's a statistically worse bet.
Do you actually develop sites with this kind of thinking? I'm shocked that you'd rather use a 1px png (adding an additional http request) and JavaScript to achieve an effect that CSS can handle all on its own. We use browser extensions because specs like CSS3 aren't suddenly turned on one day like a light switch.
You can make your layout look nicer on cutting-edge browsers and by the time the old browsers are no longer around and the spec is in widespread use you can remove the extensions. It's trivial to remove CSS from a stylesheet. It's usually a pain in the ass to re-implement CSS functionality from 1px pngs and JavaScript hacks once all the browsers have caught up.
CSS can't handle it all on its own is the point. And yes I'd rather incur the extra bandwidth of a 1px wide crushed PNG in order to have simpler code and have my site support all-browsers, including ones whose team made good CSS a priority before other browsers did. Rewarding the large monoliths by coding specifically for them simply because of their popularity while punishing teams that actually prioritized CSS is what got us into this mess in the first place. Would you encourage this behavior pre-CSS4? pre-CSS5?
>To achieve these effects, I needed a small truckload of CSS
You:
>Once the standards go final and the browsers get compliant implementations, the vendor prefixes will go away.
So the implementation is excessively long, temporary, and to be changed to something more standards compliant at a later date. Seems like the definition of "ugly hack" to me.
And I'm not talking about supporting an outdated browser like IE6 here. I'm talking about a browser whose public releases support more "pure CSS3" than both Gecko and WebKit.