blog
User Experience Design, Web Development, Browsers, CSS, JavaScript
JavaScript-CSS Compatibility Layers to Save You Some Money? January 25th, 2010
Andy Clarke recently wrote about a new CSS JavaScript compatibility layer called IE-CSS3.js. The library allows users to write CSS using pseudo-element selectors, and have it work natively in IE8 via JavaScript. The JavaScript parses the linked CSS, and dynamically adds rules to the document. This means that the shortcomings of the browser’s CSS display methods can be automatically overcome by creating custom CSS with JavaScript. All users will thus see the same thing. Great.
The Web has a long, sordid history of dealing with browser incompatibilities, and some people have made their careers out of dealing with them. Some have always seen the Web, or at least the front end of Web sites, as one big hack for just these reasons.
While the landscape has improved dramatically in the last decade, there’s still always something, somewhere that needs help. And that takes effort. If you’re in the business of providing beautiful, graceful, maintainable solutions for your clients and your users, you’re on top of all of this.
This JavaScript is Doing What, Now?
JavaScript has become a common way to attain cross-browser compatibility. On my projects, I rely on it extensively for things that are “finishing touches.” It’s important to note, however, that nothing absolutely necessary for users’ access to content should be tied to JavaScript being enabled or working properly. We’re talking about CSS, remember, which is for the presentation layer.
Within a controlled audience, such as a corporate intranet, depending on the reliability of JavaScript can be less of a concern. Also, there’s right ways to apply JavaScript so it can scale and degrade effectively. But that’s another article.
So the idea here is to use JavaScript to add various visual tweaks and modifications. This can mean visual adjustments, adding additional CSS classes, or other things that might help a given Web browser render your page. Not all browsers can do everything you want to do with your CSS files, and ideally you would have rules you could strip out easily one day, either in your JavaScript or CSS files, or both.
It’s crazy frustrating to know there’s a cleaner, more efficient way to do something and not be able to use it, am I right?
Writing JavaScript or Writing CSS
So that’s pretty cool, being able to cope with browser issues using JavaScript. Other projects have come close to doing similar tasks. First there was CSSQuery, then IE7.js, and many other projects including eCSStender and others. When John Resig released jQuery, just about every JavaScript library and framework user took notice because of the simplicity of being able to use a JavaScript engine with CSS selectors to find and match objects using CSS syntax as opposed to using the Document Object Model (DOM). Now, virtually every library features a selector engine. Some lesser known examples, such as DOMAssistant, actually required by the new IE-CSS3 tools, specializes in that and that alone. In fact, I believe jQuery now uses John Resig’s Sizzle selector engine which snaps in and is designed to be independent and very high performance.
There are some big differences between some of these engines though. Some argue, if you’re going to include something like jQuery, why bother with yet another library, like this IE-CSS work around? Well the difference is that in the case of libraries like IE7.js and IE-CSS3.js, you only have to include the library and write your CSS. The library parses the CSS so there’s no extra JavaScript that needs to be written. It’s one less step than I’m used to, since I’ve become accustomed to actually writing sets of jQuery rules which impact presentation alone. And that takes time.
A brief aside: As a developer, it’s pretty cool to pick these things apart. In particular, IE-CSS3.js solves some problems such as Internet Explorer tossing out selectors it doesn’t understand by using XMLHttpRequest (a.k.a. Ajax) to download the CSS files separately. A pretty cool solution to be sure.
Only Writing CSS, or: “Sheesh, Consider the Effort Here”
Only having to write rules in CSS files is a real benefit, that’s for sure, and it’s the way things should be. And quite the time saver. If you were to add specific JavaScript to emulate the CSS selector behavior in JavaScript, you’d have to write out specific JavaScript rules and apply new classes that you created manually in order to have them applied to the page. I do it all the time, and I know my coworkers do as well.
But someone’s gone and done that for you. Thanks, guys. But why? Why do they go through all that trouble? Because it’s worth it. Supporting these browsers adds untold costs to every project. IE6, for instance, continues to be a thorn in the sides of Web developers and designers everywhere. Extra time and effort has been spent on every project I can think of in recent memory to just get it working in IE6.
A better thing would be to target Web browsers that actually support modern Web standards. Think about the time saved.
Microsoft, we’re looking at you. And companies whose IT departments still depend on IE6 for whatever reason, we’re looking at you, too. But it’s worse. That compatibility layer we’re talking about? It’s making up for weaknesses in IE8! Let’s hope IE9 doesn’t disappoint, and saves the Web working world a few dollars.
Another Option – Let People See What they See
It’s possible to get awfully close, and every developer I know, myself included, goes that extra mile to make the front end as spotless as possible for as many people as they can. That’s what we do.
But where was it written that every Web browser (and user) has to see exactly the same pixel-perfect design? It’s nearly impossible. The Web was created for universal access, and everyone’s going to get a slightly different experience based on their operating system, connection speed, and the software they use. Not to mention if they have the fonts jacked up because their eyes just aren’t what they used to be.
In the corporate world, things are going to be fairly consistent. So don’t fret. If you all have no choice, and are stuck on IE6, the guy in the cube next to you will see pretty much what you see. What’s that you say? You pay all this money for good design, and you want people to see it in its full glory. Well, guess what? They’ll never know the difference.
We’re not talking about changing out your company color palette. We’re not talking about changing your logo or crucial functions on the site. Your visitor didn’t approve this design, and doesn’t know it the way you do. Trust me, they’re looking for content. We’re talking about losing a few finishing touches: some corners, gradients, or possibly a few small background ornaments. And that’s the tradeoff for smaller file downloads, and less production and maintenance time. You’d be shocked at the amount of effort some of these little touches take. Save a buck by leaving off some drop-shadows in IE6, ok? In a few months or years, it will be history (hopefully).
This discussion has gone on for a while in various online forums, so I’m not some lunatic with a game changer of a notion. Andy Clarke, who I mentioned at the start of this little article, takes a pretty strong stance. I may not even be ready for that.
For your consideration: Do Web Sites Need to Look Exactly the Same In Every Browser?
To come full circle: it’s nice that a handful of resourceful developers out there have put their blood, sweat, and tears into coming up with things like IE-CSS.js, so the rest of us can benefit. Like I said: thanks, guys. But downloading yet another file isn’t always the right answer.
2 Comments for "JavaScript-CSS Compatibility Layers to Save You Some Money?"
-
Thanks for mentioning eCSStender!
It’s still early yet, so there aren’t a ton of extensions out there, but what eCSStender really excels at is working with your CSS so you only have to write it once. It can be used to patch holes in browsers, but it can also be used to experiment with new CSS properties in order to help make sure the syntax makes sense and is useful before it becomes a standard.
For designers, the benefit is that you can write it once and it will work everywhere (especially helpful with selectors). Ideally, a designer would never have to touch the Javascript. Developers, on the other hand, can get their mitts dirty and either build something new and cool or make someone’s day by freeing them from the scourge of browser inconsistencies.
Anyway, thanks again for the post and the mention.
Aaron Gustafson on January 29th, 2010 at 7:37 pm
-
Hey Aaron, thanks for stopping by. Absolutely. A great time saver in not having to work overtime to get the compatibility that we all deserve.
Wow, I realized I totally spaced and didn’t link to the eCSSender web site:
I will update the article. Fair is fair, especially with all the hard work being put into it. Thanks,
:rob
Rob Cherny on January 31st, 2010 at 8:47 pm
Post a Reply
Newsletter
Sign up to receive our monthly email newsletter about strategy, user experience, and technology.
Careers
We are looking for experienced professionals to join us and contribute to our clients’ success.