Frequently Asked Questions

Below are a few of the common questions we've been asked about eCSStender.

Should I use eCSStender on my site?

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.

eCSStender is running really slowly for me, how can I fix that?

It may not be eCSStender that's running slowly. Take a look at the eCSStender test suite and see if that performs well. If that's the case, it's probably an extension that is causing an issue. Or you may be including a bunch of CSS files, all of which eCSStender will read. For more on optimization and how you can improve it, check out this article. If you are seeing a speed issue with eCSStender core, please post a note to the mailing list.

Does eCSStender play well with other JavaScript libraries?

Yes. eCSStender was built from the ground up using native JavaScript and is namespaced so as to not conflict with any known library. Though some extensions may leverage libraries like jQuery, the eCSStender does not. And extension developers are encouraged to make their extensions library agnostic if at all possible.

How can I help?

If you want to help out with eCSStender core, drop Aaron a note on the mailing list. If you want to get involved with one of the extensions currently in development, contact the lead developer. If you want to write your own extensions, read the documentation and let us know when you have something stable... we’ll happily link it up.

Wouldn’t it be better to do all of this on the server side?

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.

What's the difference between Modernizr and eCSStender?

Modernizr and eCSStender are related JavaScript libraries, but they do not serve the same function. The main difference is in each's respective focus: eCSStender is, first and foremost, a library for working with CSS; Modernizr detects "the availability of native implementations for next-generation web technologies."

While it is true that each library offers a mechanism for determining a browser's capabilities, eCSStender's testing is aimed squarely at CSS property and selector support. Modernizr, on the other hand, tests the browser's support for a specific set of technologies—some CSS-related others HTML-related. There is some overlap on the CSS property support area, but not much. And while Modernizr does offer some JavaScript-based callback support when tests complete, it is (at least as of October 2009) being primarily used for the behavior of adding classes to the html element, denoting support for a certain technology (or lack thereof). Using eCSStender, a developer could easily add the same functionality, but eCSStender is geared more for identifying and solving CSS implementation issues in addition to allowing for the extension of the CSS language.