Three separated layers, capisce?
Si, capisco. But many people don’t understand. Or they don’t want to. Or both.
Interface code is supposed to consist of three layers:
- Content (HTML)
- Layout and looks (CSS)
- Behavior/interaction(JavaScript)
This is so basic, just like using semantics. However, as Jeremy Keith writes in his excellent piece Gotta keep ‘em separated (:hover Considered Harmful is also a recommended read), a common problem is that many, many developers use pseudo-classes in CSS for interaction effects.
Hence, of course they then complain about IE’s incomplete support for CSS 2 (which is a very sad thing, I agree), since there are a lot more pseudo-classes available in it that are supported by web browsers like Firefox, Opera and others.
But pseudo-classes aren’t the way to go, and I don’t know what they’re doing in the CSS specification in the first place.
So why do developers use them? Like Jeremy, I believe that it is because it’s easier to do it that way, and not all of them are accustomed with JavaScript. Peter-Paul Koch also wrote about this (amongst other things) almost a year ago, where he concludes:
However, everyone’s personal preference seems to be CSS these days, and that’s what bothers me. The balance is lost. People seem to be afraid of JavaScript.
And Jeremy wonderfully states:
There is a gap in your skill set that needs to be filled.
That’s all to say, really. Do it right or don’t use it. Many developers (including my Interface Developer colleague at the company where I work) argue:
But it’s so easy to have it in the CSS file.
But what kind of an argument is that? As easy as using tables instead of CSS? As easy as having FONT tags? As easy as using DIV tags for every element on the page and then style them?
It shouldn’t be easy, it should be correct.
There are two cases to argue this, that are semi-valid points that should be answered:
-
Accessibility
True. There might be cases where the visiting web browser has JavaScript deactivated/doesn’t support it, but supports CSS.
But as always, the page should be usable for visitors that doesn’t support script. Not a valid excuse. Another factor to this is that DOM scripting is more widely supported than CSS 2, which means that you will probably be able to target more users with an onfocus event than the corresponding :focus pseudo-class in CSS. -
Hover effects on A tags
Having a numerous amount of links in a page would end up in massive code if you were to add onmouseover and onmouseout attributes to every A tag. But that’s not the way I’d do it, and not the way I’d recommend. Luckily, Mark has written the code for display, so I don’t have to put it here.
Now that we’ve finally managed to separate content and presentation, the risk is that the CSS file will just be the new replacement bulk file, with interaction in it as well. Please, please don’t let us repeat the mistakes we did with the HTML files in the beginning. Let’s separate things into where they belong.
