1 Posted by Robert Nyman on 22 April 2005 | Permalink

Jeremy's article is extremely well-written and right to the point.
Very good to "bring back" focus to JavaScript again so people use the right tool for the job.

The reason that is difficult to adress and that hasn't been mentioned is accessibility-related:
I think (some) developers use CSS instead of JavaScript for such functionality because then it will also work in web browsers that have JavaScript deactivated/don't support JavaScript (given that they support CSS 2 of course).

2 Posted by JD on 22 April 2005 | Permalink

Are CSS developers scared of if's and while's? ;)

Anyway, I totally agree with Jeremy that these days everyone is trying to solve problem using CSS whether it's the right tool or not.

JD

3 Posted by JD on 22 April 2005 | Permalink

Btw, thanks for the link to Chris' page. I think it's a great resource! :)

JD

4 Posted by Vesa Piittinen on 22 April 2005 | Permalink

I guess the non-JavaScript use among web developers has come from somewhere... when I did some JavaScript, one of the first comments I got was "eww... JavaScript!" - for sure this isn't very encouraging. I think more and more people should get evangelism about JavaScript once again, just like ppk and others are doing here. But it shouldn't only touch people who do web design primarily, it should touch the next level too: the people who love to give critic, yet know less...

5 Posted by Milo on 22 April 2005 | Permalink

I agree that if a functionality is worth implementing, it's worth implementing for everyone. However, I don't agree that DOM JavaScript is a more appropriate tool than CSS for this job.

Jeremy's argument that pseudo-elements are basically event handlers is true. However, they are event handlers that only affect how the page looks. If you feel that all :hover styles should be handled by javascript, then you could argue that you shouldn't have style sheets for "print" media either. If changing the look of a page when hovering over an element is an "event", then changing the look when switching display modes is just as much an "event."

6 Posted by Jacob on 22 April 2005 | Permalink

IMHO, pseudo-elements in CSS should (of course) be used for things like link hovers etc - it would be stupid to use JS for that (usually... there are exceptions), however for things like menu systems and other more complex events, I would say that Javascript is a better solution - it gives a level of control over the operation of the menu that pure CSS cannot provide - for example timed stuff, complex conditional test etc. There's no harm in providing a rough-edged CSS backup solution to the problem however, in case the JS isn't enabled / supported for example. I would say that it would be important to do so. Also, it goes without saying that the site should still be useable without either solution :)

7 Posted by Philip Hazelden on 22 April 2005 | Permalink

I guess I'm all alone in that I see nothing wrong with using CSS when CSS is easier than the DOM. I know it's intended for presentation rather than behaviour, but it's easier to use and easier to implement - lightweight browsers are more likely to implement CSS than Javascript. There's also no delay before onload (but more on that later), and it's far more deferrent to the user's wishes if they don't like something (better integration between the two would help). You get less control, but if you don't need that control, who cares?

As to the onload, I think I've thought of a solution. It's only theory, but I figure you could scan the DOM for the elements you want while the page loads and assign behaviour if it's there:

function assign () {
setTimeout(function () {
if (document.getElementById('foo') {
/* Assign behaviour */
} else {
assign(); // Aah, the wonders of recursion. :-)
},100);
}
assign();

8 Posted by Freddie on 22 April 2005 | Permalink

I agree with the articles, :hover and :focus are just 'shorthand' for onmouseover="change_element_style()", which is not what CSS is made to do and I see that as a job for JavaScript and any support for these 'pseudo' elements in browsers should be taken as 'good-will' by the developers and no something to expect every browser to support, and class ones which do not support it as bad browsers.
I think that JavaScript does still have a place in the web design world (unlike a few years ago when I would have said something along the lines of "JavaScript, the devils unsupported and annoying child").

9 Posted by Filthy_Pervert on 23 April 2005 | Permalink

Ok, let's start using DOM scripting instead of CSS to handle 'hover' and other events.
In that case, to highlight links when cursor is over, you should write some piece of JS-code. But what should that code do? Change style like this: "element.style.backgroundColor='#000000'"?
Or dynamically change element's class name?
I think that it would be really bad structure-presentation-behavior mess.

So I don't mind using :hover and stuff when it works and moving to DOM-scripting technics when browsers fail to provide CSS2 support.

10 Posted by Fuzztrek on 23 April 2005 | Permalink

I agree with supporting all browsers if you are a serious web developer. However, I would encourage all developers to drop bad browsers like a hot potato on their personal sites. Let those bad browsers know that they're bad - most especially if they are an old version of any type of modern browser, good or bad.

As for the DOM & JavaScript, I know many tech-savvy people (or at least those who claim to be) who fear JavaScript themselves - how absurd is that? JS has gotten such bad publicity, which I think is quite unfair and has probably scared many developers away. But then there are people like me, who tried to get crap to run on all the minor versions of Netscape 4.x.

I think that the W3C should take scripting more seriously. CSS is going to start suffering from feature creep (if it hasn't already) if someone (I realize now that it probably won't be the W3C) doesn't put it back in it's place and shove JS back out into the spotlight.

11 Posted by Small Paul on 23 April 2005 | Permalink

Because it's a fully-fledged programming language, JavaScript has a much steeper learning curve than CSS or HTML. I enjoy writing JavaScript, but while loops still scare the bejeezus out of me :)

HTML and CSS were meant to be as simple as possible. Taking the example of :hover styles, what you've got there is a very popular effect. People could write a small JavaScript function to achieve it, and then write another JavaScript function to assign the function to the onmouseover event on every link on every page. And then, if they want any other events on any links onmouseover, write another function that negotiates the different advanced event models of WinIE, Mozilla et al...

Or, they could just write a:hover in their stylesheet.

I guess you could argue that if people arn't up to a bit of programming, they shouldn't be doing HTML or CSS for money either. I can see the force in that, but it may put otherwise talented people off getting involved in all this.

And besides that argument, isn't a:hover computationally more efficient than assigning a hover style function to every link on every page via JavaScript?

I understand the point about not trying to make CSS do everything, but the real world is very happy with a little muddying around the edges of the conceptual waters (hmmm, nice sentence) when it makes things easier.

12 Posted by Richard York on 24 April 2005 | Permalink

I think I'm certainly guilty of saying "ew, javascript", which isn't for lack of javascript skills but for simply looking at the stats. One site that I work on has 10% of users with javascript disabled. That's nothing to scoff at. I agree somewhat that sometimes interactive means scripting, but if CSS can do it too and not alienate that 10% group, why then go with scripting? Of course this argument is completely meaningless if you need something like Dean Edward's IE7 to fix broken CSS support. But, regardless, that's why I'd seek out a CSS solution over a scripting one.

13 Posted by Jeremy Keith on 24 April 2005 | Permalink

PPK, you're very kind to say such nice things about what I wrote but you're also being very modest.

Let's face it: I'm not saying anything new. You wrote about the very same thing last year:

http://www.digital-web.com/articles/separating_behavior_and_presentation/

As usual, it's just taken the rest of us some time to catch up with you ;-)

14 Posted by Nolan Clark on 26 April 2005 | Permalink

I agree that, in principle, certain :pseudo classes shouldn't be the domain of pure CSS. Thinking abstractly for a moment, CSS is supposed to allow us to map visual presentation onto document structure. :first-child is a structural psuedo class, but :hover isn't.

I've never written a browser, but it's pretty clear to me that supporting :hover properly means implementing an entire DOM-based dynamic layout system, at which point you might as well throw in complete javascript support because you've already done all the work.

Of course the big mainstream browsers already have powerful dynamic layout engines, so what's the problem? Well, it's a design issue, from both the perspective of the browser implementor and the website builder. Keeping a clean separation of functionality is crucial in the long run.

To see what I'm getting at, imagine something similar to CSS, but rather than mapping presentation onto structure, it maps scripted behavioral event handling onto document structure. This probably doesn't sound like a new idea - because it's not. Several different things come pretty close, for example the :hover class or microsoft's behaviors. I would just like to see the notion formalized, probably as an OPTIONAL extension to CSS.

We really need something like this. The reason :hover is so great is because you can apply an event handler to 20,000 links with a single chunk of CSS. To do the same thing with javascript requires access to the root element where you register a catch-all event handler and then poke around every time it fires to see if you should do something to the target. What a mess. But, on the other hand javascript gives you way more power to handle the hover event.

Just think about how useful it would be to have a syntax for binding javascript event handlers to elements using CSS selectors. Then, if you want to get really carried away, howabout including the ability to bind CSS styles to elements from javascript without needing any space-delimited className ugliness?

15 Posted by ppk on 27 April 2005 | Permalink

Jeremy, thanks for the praise. I did say something along the lines you sketch in my column, but you've taken it one step further than I did at the time. You clearly stated that the fault lies with web developers who don't know JavaScript, while I merely suggested it.

As to catching up with me, sometimes I do have that feeling, too . Then again, sometimes I have some catching up to do, too, so the honours will even out in the long run.