5 ms·

Stop Forking with CSS3

10 points by audionerd 16y ago

samdk 16y ago
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/ http://basicio.com/snippets/moz_border_radius/.
- TrevorBurnham 16y ago
  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 16y ago
    There are two examples listed: http://ecsstender.org/ http://ecsstender.org/ and http://ecsstender.org/demos/spoon/ 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 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 16y ago
      Ouch. Thanks for taking the time to test.
thwarted 16y ago
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.

10 points by audionerd 16y ago

samdk 16y ago

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/ http://basicio.com/snippets/moz_border_radius/.

TrevorBurnham 16y ago
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 16y ago
  There are two examples listed: http://ecsstender.org/ http://ecsstender.org/ and http://ecsstender.org/demos/spoon/ 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 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 16y ago
    Ouch. Thanks for taking the time to test.

thwarted 16y ago

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.