Stop Forking with CSS3

by Aaron Gustafson

61 Reader Comments

Back to the Article
  1. I was wondering if there was a way to make CSS3 work on all browsers. If flash can do it why couldn’t CSS?

    Implementing this through Javascript is even better, the users don’t even have to install any plugin.

    However the working example isn’t really… working. I’ll be checking the download link until I manage to get the libraries, I’ll test them in all major browsers including IE6 on Windows XP or Firefox on Ubuntu.

    I’ll post the results here, that’s if I ever manage to download the scripts :)

    Copy & paste the code below to embed this comment.
  2. As posted in the “eCSStender FAQ”: and in response to several comments:

    As much as we’d love to say everyone should be using eCSStender, it’s just not practical in many instances. The following are a few reasons eCSStender may not be a good choice for you:

    • You use CSS3 selectors and properties sparingly (e.g. you only use border-radius in a handful of places and that’s it)
    • You don’t care about backward-compatibility (e.g. IE6 is a not-so-fond, but rather distant memory)
    • You aren’t looking to use the extensions to CSS that are available.

    Reasons you may want to use eCSStender include:

    • You use CSS3 all over the place and need backwards compatibility with older browsers (e.g. you want your CSS transitions to work in IE6 so you don’t have to learn JavaScript).
    • You want to take advantage of cutting edge enhancements or proposed additions to the CSS language (e.g. OOCSS, CSS variables, etc.).

    When it comes down to it, there’s a trade-off of file size and flexibility. eCSStender currently weighs in under 20K (before GZipping), but you also need to factor in the size of the extensions as well. It’s a small performance hit (especially if you munge the minified files together and serve them over a CDN), but it’s probably not going to balance out minimal use of advanced properties.

    If you’re considering using eCSStender to get away from vendor-specific prefixes, we’d recommend taking your non-prefixed stylesheet and giving eCSStender a whirl on a dev server. You can, using a developer toolbar of some sort, copy out the content of the stylesheets it embeds in the document and add those rules to your CSS file, comment out eCSStender, and see if there’s a noticeable speed improvement.

    Copy & paste the code below to embed this comment.
  3. If you’re having problems downloading, please try one of the methods mentioned on “this page”: If you still can’t get a copy, please drop a message on the mailing list to let me know what it is.

    Copy & paste the code below to embed this comment.
  4. I liked the article, and thought it was a certainly a possible solution if combined with Modernizr. However, when I started to try it, the support for properties like border-radius and box-shadow is not consistent at all. And the point of the project is pretty much lost that way, at least in my opinion.

    Copy & paste the code below to embed this comment.
  5. There’s been a ton of debate over the necessity of vendor prefixes, so I thought it worth mentioning that I don’t think vendor prefixes are inherently bad. They serve a very important purpose: allowing implementors (the browser makers) to develop their implementations to track an evolving spec while giving them the leeway to get things wrong during that process.

    eCSStender is not an attempt to get rid of this necessary step in the process (in fact it fosters more people’s involvement in the development of experimental CSS). This library does, however, allow us to even things out the authoring side when it comes to these disparate implementations, leaving it to the extensions themselves to deal with the juggling act of serving the appropriate rules to the appropriate browser. From an author’s perspective (that’s you and me), having to write the same thing umpteen different ways (especially when it involves having to manually overcome incomplete or botched implementations) is an issue we shouldn’t have to deal with. That’s where eCSStender really helps: it makes it possible to write a single rule and leaves it to the extension to make it work everywhere.

    So, in summary, I’m not against vendor prefixes as a tool, I just think we have enough other things to worry about that we should not have to constantly tweak our stylesheets as vendor-prefixed implementations change (which they do). JavaScript is great at doing mundane tasks like that.

    Copy & paste the code below to embed this comment.
  6. Main problem: my Firefox freezes for 10 to 25 seconds when loading your website. Not a network/CDN issue.

    Also: maybe you’re introducing “leaky abstractions” to prevent “forking”? ie, fixing the “CSS purity” problem with a tool that’s probably beyond the skillset of many a CSS coder if something goes wrong.

    Using this to prototype CSS extensions sounds cool though.

    Copy & paste the code below to embed this comment.
  7. I don’t see the point in the eCSStender, since it doesn’t seem to work: IE7, IE8 don’t show rounded corners, neither on the eCCStender-site, nore on the ALA-demo-site.

    Copy & paste the code below to embed this comment.
  8. I’m been a bit perplexed at why you would want to use any of these hack CSS3 declarations in the first place. Right now too many browsers don’t support CSS3, and therefore you shouldn’t use them.

    I can’t imagine telling a client that their site looks great in modern browers but the people that visit the website that use older browsers will get a less aesthetically pleasing site. Clients just don’t accept this and furthermore I don’t. Each user should be given the best experience possible no matter what browser they use (unless it’s something like ie 5).

    I ensure my websites look great in all browsers and therefore at this time you have to use background images for rounded corners etc (sprite them if you wish).

    So overall eCSStender is a great plugin despite it not working that well and is slow. But the problem they it is solving is one that shouldn’t even be used in the first place.

    Copy & paste the code below to embed this comment.
  9. I mean, get serious! Most of the untidyness problems of those CSS forks are only of concern to the development. Therefore, the correct solution for this problem is not in the client, but in the deployment process.

    So, what is really needed: a versatile filter framework for deployment of CSS, with the ability to expand those (and other) shorthands – and while we’re at it, to clean those comments you do not want the world to see, put multiple files together and minify the CSS if necessary. And btw, a JS version of such a framework would be useful, too.

    Copy & paste the code below to embed this comment.
  10. If anyone was having issues with eCSStender in IE, there was a bug introduced in version 1.2.4 that has been fixed in version 1.2.5. Please visit and post a message to the mailing list if you see any further errors.

    Copy & paste the code below to embed this comment.
  11. Good concept but the eCSStender example page (Spoooon) looks very different in different browsers. It looks great in Safari and very good in Chrome (no drop shadows). There are drop shadows in Opera, but the action of the color boxes is not smooth. With Firefox, there are white letters against a blue square and no moving color boxes. IE 6 cuts off some letters, which are located in the upper left corner, with no color or moving boxes on hover.

    Copy & paste the code below to embed this comment.
  12. I’m sorry, I appreciate the want by some to indulge in extending CSS, but aren’t what is referred to as hacks actually standards compliant vendor prefixes that will eventually dissappear once fully integrated to the specific browser that simply allow for the vendors (and experimental coders) to start testing these new additions to the CSS fold?
    I just feel the hack comparison slightly misplaced, although I concede for the time being the code looks bloated, it is neither ‘forking’ or ‘hacking’.

    Copy & paste the code below to embed this comment.
  13. HI Aaron

    I’m not sure it’s a good idea to hide away vendor prefixes. They are there precisely because some people want to use experimental CSS, like border-radius for example. WebKit and Firefox used different syntaxes precisely because the spec was still in flux, and they correctly used vendor prefixes as this was an experimental implementation. (Opera, by the way, has supported border-radius reliably since version 10, without any vendor prefix and using the final syntax.)

    Other uses of vendor prefixes are for proprietary vendor extensions to CSS, such as gradients. Again, WebKit and Firefox have non-interoperable syntaxes so vendor prefixes are the only way to make sure that each gets the right rule.

    Developers should use each vendor prefix in their code; I advise writing the declarations in alphabetical order (so moz, ms, o, then webkit) and finally having a declaration with no vendor prefix, for future browsers that support the final standard. Sure, there’s a risk that the standard might change but if you don’t use the non-prefixed version, you are guaranteed to lock out other browsers – in the same way that if your code doesn’t use plain border-radius, you guarantee that it will not work in IE9.

    This is a developer’s responsibility. If you as a developer choose to use experimental, pre-standardised code on a production site, then you need to live with the consequennce of that choice.

    Copy & paste the code below to embed this comment.
  14. I have read all 5 pages of comments and I think a little controversy is good. Let’s everyone know there is a viable issue at hand. Many good points. This banter reminds me of something else… the screen resolution debacle.

    I was going to JS-Fork a website for North American audiences vs. “Global” audiences because I mistakenly believed that there needed to be smaller screen res for the Global community. Turns out that on average, it is the Americans using the highest % of 800×600. In that discussion, several “experts” stood firmly by the 760 for websites – in 2010! Others argued the fluid layout rule. Seems many people can’t maintain “enough” flexibility, combined with “enough” ingenuity, combined with enough “common sense” to render a real decision about the value of a given technology.

    I love the “functional” arguments whose thrust seems to be educating others how this library will function case-specific for them. Function is an Applied Science, not a Pure one.

    I think the library is a great idea which hits its mark and performs a valid service to the much sought after styling of the day. By the time there are standards for border-radius, the hype over rounded corners will be over, (I am using square and round alternating corners for a balanced, masculine/feminine appeal) and it will be left to a designer to express (semantically) what should be either function or fancy.

    In the meantime, tools help take the bleed out of the cutting edge. Thanks, Aaron.

    Copy & paste the code below to embed this comment.
  15. Any time you can move complex work to the server side, you’re going to get a speed improvement and we may add in some server-side components down the line (we’re certainly not ruling it out), but when most people ask this question, they’re weighing eCSStender against a CSS pre-processor like Sass or Less.

    Putting aside the debate over whether alternate CSS syntaxes are better or easier to use, there are definite advantages to using a tool that can translate one syntax into another (as some extensions do), but when your solution is 100% back-end, it does not allow for nuance and interpretation, which is where eCSStender excels.

    At the core of eCSStender’s power is the eCSStender.isSupported() method. This method allows a developer to test for property and/or selector support and then act upon their findings. Using this method, an extension can see that Safari 4 (and other Webkit-based browsers of its generation) doesn’t understand border radius shorthand with unequal radii (e.g. border-radius: 2px 4px;). If your preprocessor only knows to translate border-radius to -webkit-border-radius, -moz-border-radius, etc. and isn’t aware that it also needs to check the values and make further augmentations for Webkit, that’s a problem. And, if your preprocessor is pushing all of that extra markup over the wire, regardless of whether it’s useful to the browser, that too can become a problem.

    Additionally, a pre-processor can’t leverage that nuance to implement JavaScript-based animations as an alternative to CSS-based ones if they aren’t supported because the pre-processors (as they are currently built) take a “one size fits all” approach to handling CSS: everyone gets the same thing. Then there’s also the fact that eCSStender can help you implement a new property or concept you’ve conceived and make it work in the browser in a much more robust way.

    There are definite advantages to using a CSS pre-processor, but nuance and conditional translation/augmentation is what makes eCSStender different.

    Copy & paste the code below to embed this comment.
  16. I forgot Tick used to yell, “Spoooon!”.

    Thank you _

    Copy & paste the code below to embed this comment.
  17. After reading the article, I was expecting some display consistency between browsers for the demo you provided. Is it not supposed to display correctly in IE? Maybe I completely missed the point?

    Demo provided

    Copy & paste the code below to embed this comment.
  18. Unfortunately, IE’s support for advanced things like rotation, gradients, etc. relies largely on the non-standard filter property in CSS and, like CSS shorthand, any time you set filter to a new value (which each extension currently tries to do) it supplants anything that was there before instead of adding it to a stack (which is what we really need to happen). We’re currently looking into this limitation and are working with the IE team to figure out the best overall approach to allow access to and manipulation of the filter stack (so we can enable animation of these properties, for instance).

    It’s a bit much to wrap my head around at the moment, but I assure you it’s in the works. That said, most of the extensions out there work fine in IE. The only place you run into issues is where you have a combination of properties that need to write to filter being applied to the same element. That’s what’s happening in the case of the Spoon example.

    Copy & paste the code below to embed this comment.
  19. So to clean up the messy CSS with -webkit, -moz vendor specific properties, we add a Javascript? What good is that going to do?

    Copy & paste the code below to embed this comment.
  20. Even though the idea sounds great, I think there is still a way to go. Because eCSStender is 18kbs now but all the weird css in the article has been exampled only takes 726bytes. If we multiply that with 10 bordered stuff in a webpage (who would do that?), that means 7kbs, which is still lighter than the eCSStender. I’d advice a jquery (or any other library) version of it or an implementation in jquery code as default which would be greater.

    And an advice, I put these redundant CSS3 and CSS hack stuff in a seperate CSS (or seperate from all other ids’,classes) so when browsers update themselves and become CSS3 and W3 compliant, you can easily get rid of them.

    Copy & paste the code below to embed this comment.
  21. 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.

    Copy & paste the code below to embed this comment.
  22. 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.
  23. 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.

    Copy & paste the code below to embed this comment.
  24. 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?

    Copy & paste the code below to embed this comment.
  25. 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 …

    Copy & paste the code below to embed this comment.
  26. 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.

    Copy & paste the code below to embed this comment.
  27. 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. :)

    Copy & paste the code below to embed this comment.
  28. 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?)

    Copy & paste the code below to embed this comment.
  29. 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.
  30. 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?

    Copy & paste the code below to embed this comment.
  31. 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?

    Copy & paste the code below to embed this comment.