I was browsing the popular links on del.icio.us today and stumbled onto Nifty Corners and (via that page) More Nifty Corners. I have to say that I am incredibly impressed with the scripting, but I fear there is something wrong with this picture.
Late…

Thanks for a long and thourough comment, and for contributing with your two cents!

When it comes to accessibility, it is a factor that someone have to consider, where to demand of the visitor to have JavaScript activated or making sure the web site works when JavaScript is off (or, of course, ommit those functions).

Regarding:

…I’m betting the odds are higher that this CSS is gonna work vs this javascript

As I (and Jeremy Keith) state, DOM scripting has a more wide-spread support than CSS 2, so, when done right, it should be guaranteed to work in most web browsers.

As you probably know by know, my personal belief is that one needs to be skilled in all three layers (HTML, CSS and JavaScript) to achieve the most structurally correct web interfaces.

While the 3 layers of separation is a good principle somewhere as a designer you reach that point of okay what are the trade-offs. CSS or Javascript? It’s kinda been drilled into our minds at this point that hey, “the user could have javascript turned off!”

You kinda of reach a point where you say okay I’m gonna jump around semantics or whatever because I’m betting the odds are higher that this CSS is gonna work vs this javascript. Not to mention the CSS is alot quicker to drop in to achieve the same effect-don’t have to be a programmer. Coming from a long ago (don’t laugh) COBOL background I’d much rather tangle with HTML & CSS (2 elements) than have to worry about Javascript as a third element.

I thought to myself this is wonderful I can achieve the mouseover/mouseout stuff without even programming–getting twisted and tangled in all of these states and extra quotes and apostrophes.

If you said DOM this versus standard (CSS) that…. pseudo codes (with some limits) wouldn’t trash the CSS too offly bad per se. Anyway, my two cents. 2 more cents… to heck with IE and it’s proprietary action x self–3 year plus Mozilla Suite user (some firefox lately).

You can join the party anytime!

It is a tough and interesting subject, but I think it’s good to have these kind of discussions to become aware of and see people’s different opinions and experiences about it.

I really like this subject and I haven’t made up my mind completely yet. Yes, I am a criminal and abuse the hell out of the :hover class (mind you that this is a 1 year old experiment, if not older).

The thing is, I am not sure where to draw the line. While reading Robert’s original entry and the comments and finally Faruk’s entry (implement comments already! ;)), I noticed Faruk’s first half of the entry basically says what I think. I don’t agree entirely with the second half though, mainly because I am not sure where to draw the line between presentation and behaviour.

Hmmm, good stuff. Really good. More to think about while sitting in the train!

I think we’re reached some acceptable middle-ground here.

Problem is, just as with HTML, if something is allowed (avoid closing P tags in regular HTML, or doing all the interactivity through CSS and so on), then people will do it.

My belief is that it is easier to keep a firm and consistent standpoint, like all interactivity should be handled in another layer etc, instead of even making people aware of the exceptions to the rule.

We’ll see what the future holds…

But don’t worry, we will definitely find something else that we have different opinions about!

How’d you think we have different opinions, again?

Seriously though, if it’s purely visual, only a color/background change or whatever, then it’s CSS. It’s 100% style. But the moment someone does more with that, yes, it should be done with javascript.

Thank you for your answer.
I see your point and the difference you point out, but to me it is like handling interaction in the CSS file, which feels incorrect.

Faruk,

Thanks for the link.

As a reply to not belonging in the specification: As said above, it’s only the dynamic pseudo-classes I’m talking about. The other ones, like :first-letter should definitely be in the specification, no question about it.

I think you and I only have different opinions when it comes to replacing dynamic pseudo-classes with JavaScript when it comes to solely changing the look of something.

If that’s true, I think I can give in a little…
For instance, if :hover is only used to change the color of a link but not displaying another element or something similar.

What my rant was about is that people will use it for more interactivity, though, as soon as it is availible in more web browsers, hence I wanted to preach about separating it before it’s too late.

Mark my words, if/when IE supports :hover on any element, the web will be littered with CSS menus and their likes.

I think I’ve summed up my view on the entire thing rather completely, there…

Target is evil. Relieve us from it.

I think it’s an interesting aspect you bring up with dividing the pseudo-classes into styling ones and dynamic ones.
It was good that you clarified that. Of course, the ones like :first-line should definitely be in the CSS, it was the dynamic ones I was adressing.

I have also thought about the content ones, and I totally agree with you there: the content should be in the content file/-s, not in the CSS file.

“Target is definitely behaviour” ?

Correct me if I’m wrong, but I thought that the TARGET attribute was a gigantic mistake? It should be completely and solely up to the user (person using the browser) to decide whether or not a window should open in a new window (or tab), and at most the website author may specify what they PREFER to happen for the link, but the browser (user agent) should make it completely and easily possible to override such preferences on the user level.

Given that, the TARGET attribute seems to have no behavioural purpose or definition at all. It’s a browser behaviour, sure, but not website behaviour (it doesn’t change anything on the website, it ‘changes’ the browser).

As for pseudoclasses…

Robert:

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.

Pseudo-classes and pseudo-elements are nearly all completely visual. Their purpose is to access (style) elements in a more dynamic way, i.e. not via ID or CLASS selectors. :first-line is something that you can’t specify with a class or id attribute, and separating it in the markup is an even worse idea.

My point is, the pseudo-classes have a very distinct and valuable purpose, and the only thing that they do (except for the dynamic pseudo-classes, being :hover, :active, :focus) is allow you to add visual styling, which is what CSS is for.

That said, I do question the need for dynamic “content-styling” done through CSS, and with that I’m talking about the pseudo-elements (:before and :after) in conjunction with Generated Content. The name itself, to me, indicates that it is content — obviously — so, shouldn’t it be in the actual content, then? Thus, in the structure layer that contains the content: HTML/XHTML/XML.

But I’m not sure what your conclusion is. :hover is something that can be discussed for a long time, but regarding other pseudo-classes, would you encourage using them or using JavaScript?

I just fear that the CSS will we riddled with pseudo-classes in the future that does just about anything.

If a site uses a hover effect that makes it hard to use for someone, e.g. due to a disability, they can simply override it with a user style sheet. You can’t do that with JavaScript, even if I think Opera 8 now supports user JavaScript as well as user style sheets.

So from an accessibility point of view, CSS is more appropriate.

While I do understand how you think, I’d say it’s going way overboard, like marking up sentences as ordered lists of words.

Thank you for your input.
I’d avoid labeling hover as state or behavior, rather as an event. And events, IMHO, belongs to the programming, not presentational, code.

This sounds easy in theory and almost impossible in practice, but I think the security issues are the web browser vendors/OS vendors problem, that shouldn’t affect good coding practice (I know, I know, in a perfect world…).

It is a tough question, but I’m just afraid that too much functionality will be added into the CSS file because of lazy developers/those who don’t know JavaScript and those few, like you, that bring up the security aspect.

I can forgive hovers (I sin with them too…), but generally, I think it’s better to draw the line now before CSS becomes the new bloated HTML equivalent.