Aaron, thanks for the explanations in comment 32. I can see that eCSStender could be overkill in some situations, while being very useful in others. It’s good to consider it on a case-by-case basis.
Regarding vendor prefixes, the following has been echoed many times:
when browsers update themselves and become CSS3 and W3 compliant, you can easily get rid of them
That will be true at some point, but depending on how far back you may need to support certain browser versions, you may have those prefixes in your stylesheets for some time. Just sayin’.
Copy & paste the code below to embed this comment.
Perkin5
I love the idea of ecsstender but I can’t get it to work in IE – specifically rounded corners or text-shadow. Works OK in webkit and mozilla. Should it work in IE or is that still under development?
Mostly web sides users: approx 70% with IE <= 8.
Even IE8 isn’t using CSS3. I’m testing some of my domains every few days and thing what’s happened with IE9? Or shell we get a other Firefox or Chrome or Safari …
What you’ve assembled is great. It does make for clean use of CSS3. However, I’m taking exception to the premise that you present it in—specifically losing the need to use conditional forks.
You are still forking, but you are using JS routines to sniff and detect browsers. A practice that you derided.
And what happens when JS is disabled? Yes, I know. I know. In this day and age, darn near every site on the web breaks horribly with JS disabled, but the fact is that people do still do it.
Have you considered doing what you do with JS, but doing it with a server-side language? Having it server-side would circumvent the client-side issue.
I’m not diminishing what you’ve done. I think it’s great. It certainly makes life easier, through use of a standard libraries that degrade gracefully. What I’m taking issue with is the context of “no more forking” that you present it in.
It won’t really be useful for us designers until we can guarantee that it will work on all browsers, our clients expect the site to look the same across all platforms and hence we cannot see this as a viable solution.
A shame because I would really love to use this, and it would really make our lives allot easier. :)
btw: you probably already know this but there are still issues with FF on your scripts homepage. :)
I agree with comment #56… it’s a great idea, but to me the beauty of CSS3 is that we can do a great deal of what used to be done with Javascript instead with CSS3. I can’t bring myself to use Javascript to cleanup my slightly messy CSS3, knowing that if someone were to visit my page without Javascript (think poor mobile phone support, people switching it off for security, etc.), they would not be able to see the shadows, animations, etc. that they might (depending on their browser) be able to see simply with pure CSS.
I’d also rather not keep patching up old browsers with Javascript… the more we do this (as developers), the more we’re doing to keep those browsers around. If the web was entirely broken in old versions of IE, would anyone continue to use it? And if they did, would they really care about how sites looked, given that so many would have rendering issues?
The idea (mentioned in prior comments in this thread) of a CSS pre-processor is a nice one though, it’d be great if something like this could be executed in that fashion (a bit like Sprockets?)
i’ve been super excited to try this, but im looking at the Spoon demo site and it’s not working correctly in anything i view it in:
-Chrome 6: animates and has rounded corners but no shadow
-Safari 4: rounded corners with shadows, but no animation
-FFox 3.6: no corners, no animation, no shadows
-IE8: no containing box at all, two small quote marks
Copy & paste the code below to embed this comment.
generalExpert
Well this still doesn’t work in FF. I’m on 3.6.12 / Linux and it’s a no go. Works great in Chrome/Linux though. I’m wondering… with this being such a large file compared to just a few extra lines in our CSS… Is it worth it? I’ve always thought that one of the main points of coding semantically was to reduce bandwidth. So, doesn’t this increase [it] greatly compared to a few extra (ugly) lines of code in our CSS? Am I missing something. Seems like a great tool but just not too sure about the size of the file?
I like this idea a lot and found a similar attempt by Lea Verou. But i have similar concerns.
1. Performance.
2. We are watching evolution of support over browsers like linear-gradient in chrome 10 How is that taken care?
61 Reader Comments
Back to the Articlenatewalton
Aaron, thanks for the explanations in comment 32. I can see that eCSStender could be overkill in some situations, while being very useful in others. It’s good to consider it on a case-by-case basis.
Aaron Gustafson
Regarding vendor prefixes, the following has been echoed many times:
That will be true at some point, but depending on how far back you may need to support certain browser versions, you may have those prefixes in your stylesheets for some time. Just sayin’.
suedejohnny
So to clean up our CSS we use JS instead of vendor-specific properties? I don’t get it. It’s a waste of time IMO.
Perkin5
I love the idea of ecsstender but I can’t get it to work in IE – specifically rounded corners or text-shadow. Works OK in webkit and mozilla. Should it work in IE or is that still under development?
Rolan Rozga
Mostly web sides users: approx 70% with IE <= 8.
Even IE8 isn’t using CSS3. I’m testing some of my domains every few days and thing what’s happened with IE9? Or shell we get a other Firefox or Chrome or Safari …
Annapolis Website Designer
What you’ve assembled is great. It does make for clean use of CSS3. However, I’m taking exception to the premise that you present it in—specifically losing the need to use conditional forks.
You are still forking, but you are using JS routines to sniff and detect browsers. A practice that you derided.
And what happens when JS is disabled? Yes, I know. I know. In this day and age, darn near every site on the web breaks horribly with JS disabled, but the fact is that people do still do it.
Have you considered doing what you do with JS, but doing it with a server-side language? Having it server-side would circumvent the client-side issue.
I’m not diminishing what you’ve done. I think it’s great. It certainly makes life easier, through use of a standard libraries that degrade gracefully. What I’m taking issue with is the context of “no more forking” that you present it in.
René Reinholdt
It won’t really be useful for us designers until we can guarantee that it will work on all browsers, our clients expect the site to look the same across all platforms and hence we cannot see this as a viable solution.
A shame because I would really love to use this, and it would really make our lives allot easier. :)
btw: you probably already know this but there are still issues with FF on your scripts homepage. :)
beemuse
I agree with comment #56… it’s a great idea, but to me the beauty of CSS3 is that we can do a great deal of what used to be done with Javascript instead with CSS3. I can’t bring myself to use Javascript to cleanup my slightly messy CSS3, knowing that if someone were to visit my page without Javascript (think poor mobile phone support, people switching it off for security, etc.), they would not be able to see the shadows, animations, etc. that they might (depending on their browser) be able to see simply with pure CSS.
I’d also rather not keep patching up old browsers with Javascript… the more we do this (as developers), the more we’re doing to keep those browsers around. If the web was entirely broken in old versions of IE, would anyone continue to use it? And if they did, would they really care about how sites looked, given that so many would have rendering issues?
The idea (mentioned in prior comments in this thread) of a CSS pre-processor is a nice one though, it’d be great if something like this could be executed in that fashion (a bit like Sprockets?)
mroncetwice
i’ve been super excited to try this, but im looking at the Spoon demo site and it’s not working correctly in anything i view it in:
-Chrome 6: animates and has rounded corners but no shadow
-Safari 4: rounded corners with shadows, but no animation
-FFox 3.6: no corners, no animation, no shadows
-IE8: no containing box at all, two small quote marks
generalExpert
Well this still doesn’t work in FF. I’m on 3.6.12 / Linux and it’s a no go. Works great in Chrome/Linux though. I’m wondering… with this being such a large file compared to just a few extra lines in our CSS… Is it worth it? I’ve always thought that one of the main points of coding semantically was to reduce bandwidth. So, doesn’t this increase [it] greatly compared to a few extra (ugly) lines of code in our CSS? Am I missing something. Seems like a great tool but just not too sure about the size of the file?
sushil.java@gmail.com
I like this idea a lot and found a similar attempt by Lea Verou. But i have similar concerns.
1. Performance.
2. We are watching evolution of support over browsers like linear-gradient in chrome 10 How is that taken care?