Digital Web Magazine

The web professional's online magazine of choice.

Separating Behavior and Presentation : Comments

By Peter-Paul Koch

May 19, 2004


Sam Newman

May 20, 2004 2:13 AM

You raise some interesting points. I completely agree that where possible only one technology should be used (CSS or Javascript) however I think there can be some value where you use both. On my website for example, I use Javascript and CSS to generate prinatble views of all my pages. I use a normal CSS page to change the layout in the normal fashion, and use Javascript to extract links and generate them as footnotes. If the user doesn’t have CSS support the page will be fairyl printable anyway. If they dont have Javascript by do have CSS they just don’t see the extracted links.

Where a behaviour relies on the presence of both CSS and Javascript to work at all – that is the absence of either causes a website to just not plain work, well in that case I agree 100% with the points raised.

Shaun Inman

May 20, 2004 7:28 AM

Excellent point about redundant coding PPK.

One thing to note is that your statement that no one had ported image replacement to JS isn’t entirely accurate. A List Apart ran this article on JavaScript Replacement in November of last year. There’s also my own Flash Replacement which was created for my site which launched in February with an article on a refined version of the technique published in April.

Sound logic abounds otherwise.

Chris Heilmann

May 20, 2004 8:03 AM

One thing about the whole discussion about foldout (dropdown) menus that is often forgotten is to question ourselves how they should behave? Foldout menus are historically used in application design (hit alt now to see that), and they function in most applications that way that you need to CLICK on them (or press cursor down) to make the sub-menu appear, not hover over it. This can be easily done in Javascript, however might be even impossible in CSS (:active might work though).

Another point for Javascript in that case.

Another thing is that I can check in Javascript if images can be loaded at all (and this is where ppk’s script is superior to mine), something that is not possible in CSS.


May 20, 2004 1:49 PM

I couldn’t agree more with this article, and I am glad to see the concept of separation of structure, content, presentation and behavior finally catching on. While I find the latest ALA article a bit daft (which I wrote about on graphicPUSH), I think PPK is dead on. Excellent work, and I look forward to implementing the ideas into my own work as well as my client’s work.


May 20, 2004 4:22 PM

Shaun, you’re obviously out of it:

Your Flash Image Replacement thing is daft (you can’t spell your name right, either; it’s Sean).

I’m currently writing an article about Image Tab Rollovers, using Javascript to replace the images and CSS to create rollover effects (currently the technique only works in the best browser ever, Opera 7.23).

PPK, another excellent article.

Jimmy Cerra

May 20, 2004 10:37 PM

Unfortunately, browser compatibility interferes. Explorer on Windows only supports :hover on link elements, and not on any other. Therefore the pure CSS solution can

Chris Heilmann

May 21, 2004 12:22 AM

Jimmy, this actually complicates things even more: When I turn off activeX then your dropdown doesn’t work at all. So to say, the great idea of behaviours could also be flash.

Dante, please keep things on a professional level, repeatingly telling people their releases are daft and they are too stupid to spell their own name is not a good plan.

Also praising the article and plugging an own idea that violates one of the ideas of it (mixing CSS and JS behaviour is bad – suckerfish dropdown) is a bit off.

Jimmy Cerra

May 21, 2004 12:41 AM

I forgot to test with different security settings. Thanks Chris! My script uses an ActiveX control to download the stylesheets for reparsing. I’ll try to find another way to do that in pure javascript.

Patrick Griffiths

May 21, 2004 7:42 AM

I don’t quite get it. What are you trying to say? That there should be a definite split between technologies and what they do (JavaScript for behaviour and CSS for presentation) or that personal preference is actually ok and that it’s all right to use CSS for behaviour and JavaScript for presentation as long as they’re not mixed?

Me? I unashamedly declare my love for CSS. If CSS were a shapely lady I’d marry it and have strange mutant CSS/human babies with it. I’m not afraid of JavaScript. I’d even say that if JavaScript was a shapely lady I might even consider a brief fumble, but at the end of the day I don’t think she’s relationship material so I only turn to her when I need a quick romp.

And in the same way that you seem to think people are afraid of JavaScript, you seem to be positively infatuated by it – is this your personal preference?

Amongst all of the right-technologies-for-the-right-job talk you slot in your JavaScript image replacement technique. I like it, but in your own words (talking of an ideal), “Any effect that takes place after a user action is behavior. Any other effect is presentation.”. So that would make image replacement presentational – a job for CSS. But that’s kind of okay because when it comes to the practical rule of “Use the technology that requires the least amount of code.” you say you actually “like [this] a lot more”.

The logical conclusion of separation suggests that the :hover pseudo-class shouldn’t belong in CSS. But this allows us to “Use the technology that requires the least amount of code.”. Doesn’t it?

As for dropdowns, I would prefer to use the CSS-only method because it’s so damned sweet. And light. Unfortunately they’re impractical due to the lack of support for :hover. So what does Suckerfish do? It helps. It’s not any more complicated than any other dropdown method, in fact, all it does is mimic the :hover pseudo-class. There isn’t one method for one browser and one method for another – the :hover selector is grouped with the Suckerfish class selector to apply the same declaration blocks. And guess what? It takes advantage of CSS and JavaScript and “Use[s] the technology that requires the least amount of code.”.

One last thing, I’m not quite sure how Suckerfish Dropdowns are ‘psychologically dangerous’ (do they stress people out, reveal repressed memories or play crazy mind games?), but when it comes to accessibility, they’re as accessible as any other dropdown method. Behaviours tend to lead to inaccessibility not only because they usually rely on JavaScript but because they often rely on pointing devices too. So you need some kind of backup, such as having sound information architecture and making the top links on a dropdown lead to genuine pages. It’s not just a consideration for Suckerfish Dropdowns, it’s a consideration for pure CSS dropdowns and pure JavaScript dropdowns. We never did “forget the issues”. In fact, this was covered in the original ALA article.

Dan Webb

May 21, 2004 7:58 AM

“As you see, mixing the behavior and presentation layers is a bad idea.”

I’d just like to get a handle on your reasoning behind this statement. From your article, you basically say that you a) don’t like the idea of it and that b) it doesnt work for IE browsers with no script. So the only real problem is that it doesnt work for IE no script. This is a problem for all dropdown techniques. You could put stuff in a tag etc. etc. but this is always going to be messy and as we said in our original article the best solution to this is to link the top menu elements. What’s better than that?

So, back to point a, you don’t like the idea of it because it “mixes presentation and behaviour” well yes, in theory, it does but if you take a step back it makes sense.

By what I gather from your article you prefer it if we just dropped the use of :hover and made every browser work using JavaScript. Fair enough, that’s a 2 second job. In fact that was what we thought of first. But then we thought “hang on, most browsers already know how to do this…why not let them just do their thing using :hover?” That way, minimal amount of code, minimal amount of browsers that code needs to run on, minimal compexity and impact on the page overall. Makes sense, yes?

All we are doing is adding and removing a class name on mouseover and mouseout. It’s not rocket science or complicated in any way. I think in actual practice suckerfish is a really compact and reliable technique and I don’t see how making a whole load of JavaScript do the job that CSS already does in most browsers makes it anymore valid.

I’d really like to know what your approach to this problem would be as it’s alot easier to critise than to actually be contructive.


May 21, 2004 1:39 PM


You say:
One thing to note is that your statement that no one had ported image replacement to JS isn’t entirely accurate.

Though you’ll find that this article was written by Peter-Paul Koch, and from the article you quoted…

“That’s why Peter-Paul Koch came up with the idea to use JavaScript to replace plain text with image-based text (on the css-discuss mailing list), and that’s where the technique explained here comes in.”

Back on topic: I am personally starting to take a second look at JS. I used it before CSS design was on the radar, which was a long time ago, but have not seen the need till recently.

But, so far, the only JS I’ve used was to swap around some class attibutes. This means that the behaviour layer depends on the presentation layer. No CSS, the JS does nothing. If there is no JS, then the CSS “degrades” a little.

At the same time, as with your additive forms demo, there are things you can do in JS which are independant of CSS. Both sides of the coin are important. JS controls the presentation layer in much the same way that it can control the structure and content layers.

All I can really say, is that you (or someone else) needs to come up with a nice name for the modern, unobtrusive JS. I’ve seen people go “wow” when they discover that JS isn’t just onClicks anymore.

Preferably a name with an X in it, in much the same way that Xhtml is carrying CSS :)



May 21, 2004 4:12 PM

My Img tab rollovers do not mix JS and CSS as Suckerfish does. Javascript does one thing, CSS does the other. In Suckerfish dropdowns, the JS is only there for Internet Explorer (in mine it’s there for all browsers).

I know the whole idea of my plan is silly, but once I get the article finished you’ll see what I mean.

Sorry I called your thing daft, Shaun (though I still retain that it should be spelled Sean).

David Smith

May 21, 2004 5:47 PM

I enjoyed reading your article and the way you approached it. However, I am slightly confused over your handling of the Suckerfish Dropdowns method. You say that they have made a mistake, reasoning that,

We have to separate behaviour and presentation, ...

yet your conclusion implies that they haven’t really made a mistake,

... we cannot yet firmly separate behavior and presentation. ... In practice, separating behavior and presentation today wholly depends on the personal preferences of individual Web developers. ...

Sorry for pulling you up on this, but we are talking about methods that people, like you and me, expend their energy on. To dismiss it on the grounds of an ideal is poor.
Clearly the way forward would seem be the use of JavaScript alone for menus. However, I’m sure you’d be the first to agree that if it hadn’t of been for Explorer, then you would be using CSS for that purpose. In fact you said,

... the pure CSS solution can

Chris Heilmann

May 22, 2004 1:28 AM


xHTML has nothing to do with CSS...

The name for the “new” Javascript that is commonly used is unobtrusive javascript.

Stuart Langridge at kryogenix used it, and I liked it so much that I even created
a course on it for my junior developers.


May 22, 2004 9:17 AM

One can avoid all the special casing in CSS image replacements by putting both the :normal and the :hover state in the same image file and shifting its position. Thats how its used to be done in games/application programming eg.


May 22, 2004 10:11 AM

example of css-rollover at – takes just 5 lines and three classes, it makes server side scripting much more comfortable too; Disclaimer: I didnt invent this :)

Jimmy Cerra

May 22, 2004 10:28 PM

On Browser stats:

“The sharp decline makes me distrust these figures. I do not believe that 5% of all WWW users turned on JavaScript in recent months,”

Of course, there are many ways that statistic may reflect reality. Nowadays there are few reasons to disable JavaScript. I suspect that most of those people who are worried about popups, ActiveX exploits, invasion of privacy or annoying Flash probably use one of the many modern browsers which are immune from those problems (i.e. Mozilla, Safari, Opera). Furthermore, many of the most popular web sites are now starting to require JavaScript (i.e. Hotmail). Finally, new web surfers have little reason to disable JavaScript (because of the knowledge of either what exploits exist or the knowledge of how to disable JS); that will lower the percentage of js-disabled users even if the total number remains constant. Thus that percentage should decrease.


“When I turn off activeX then your dropdown doesn’t work at all. So to say, the great idea of behaviours could also be flash.”

I’ve been thinking some more about this comment. The CSS based solution- even with the requirements of Flash – offers many other advantages. Flash is generally overkill for such uses. Each Flash file has to be written explicitly for different web pages when the menu changes; however, the CSS solution is more general. It is also generally easier for users with special needs (i.e. voice or brail user agents, text browsers, Google). The text as plain markup can be searched by the user or indexed by search engines too. There is also more control over the style for user themes and printing styles. Granted, Flash files could be programmed with such extensibility in mind; however, it takes much more skill to write them than the average CSS file.

Oh, and the reason ActiveX is required is that the behavior uses a “download” control to reparse the style sheets as text files. This is commonly thought to be impossible in regular JScript by design (security, etc). If you know of a solution, please enlighten me.


This is off topic, but… Shaun and Shawn are alternative spellings of Sean in the United States. It’s sort of like “behavior” and “behaviour.” (Although, they are all distinct names.) I have many friends with names spelled all three ways!


May 23, 2004 1:18 PM

My Idea of hell is that 20% of users have Javascript turned off (could be worse, it could be that 20% of users are using Netscape 4…shudders).

I know that Shaun and Shawn are spelt like that in the US (I live in San Francisco), but the correct way is Sean (Sean is Gaelic/Irish for John). But let’s not argue about spellings, since Americans can’t spell (behaviour is the correct way).

PPK recognizes that people won’t listen to him and will still use pure CSS menus. This shows that most web developers aren’t interested in standards if it means writing extra code. Interesting.

I myself have only used an ActiveX Object in Javascript once, to import an XML document.

Chris Heilmann

May 23, 2004 9:25 PM

About Active-X in behaviours:
I just mentioned the problem, as it does bring another technology in the whole separation issue. I don’t know another way, and I am not too sure about behaviours being a good thing, as the more we fix IE, the less people will even consider ditching it.

Talking about flash, I encountered real frustrations in our latest projects with flash accessibility. Just adding plain HTML as the fallback inside the OBJECT is not enough, as Opera and Safari display the content AND the flash movie. If you try to find an article about this, you are lost, as most deal with accessibility in flash. The only one is Flash Satay on ALA (Clever title, how about calling it “Flash and Standard Compliance”?), but that means another small flash file loading the other, which was blocked by our proxy. Anyways, this is not what this article is about, but at least technical whereas the spelling of Sean/Shaun is rather irrelevant here, go watch Shaun of the dead instead, that makes good evening entertainment.

Jimmy Cerra

May 24, 2004 12:40 AM


Thanks for your input. I used an ugly hack to get my demo to work with ActiveX disabled. The changes allows it to download some css files with the proper delimiters. Note that there is a delay before the parsing loads; but that’s expected since this is ALPHA code. UTS for more details, if you’re interested.


May 24, 2004 1:45 PM

Don’t get me wrong: I like the standards (no matter what I may have said before, I’ve changed my mind now), but if I have to decide between valid code or code that works across all browsers perfectly I’ll take the latter.

The Flash Satay article gave me a very wrong impression about standards, I thought standards were about making sure things only work in a few browsers. That aside the flash problem is only a minor problem in the whole scope of standards.

Jimmy Cerra

May 25, 2004 11:59 AM

Dante, if you don’t code to the standards, then you can’t reliably predict how any piece of software will interpret your web pages. That’s the point of standards after all! In practice, nothing but the most trivial or niche applications work perfectly across all browsers because of bugs and compromises. However, I think you should know that modern standards combined with valid code can be used for moderate consistency across most of the general browser population. The invalid parts of popular web sites like ESPN are due to old automation software (i.e. for advertisements) and not any fundamental flaw in using standards. Don’t be silly.

Besides rumor has it that MSIE 7 will be much more standards compliant (think Safari or Mozilla) than earlier versions. Do you want your web pages to break in it?


May 26, 2004 4:50 AM

Shaun: I admire your Flash Replacement. If I’d seen it before I submitted this column I’d certainly have mentioned it. I’m not really happy with the ALA JavaScript Image Replacement article, though, for
reasons you can read here.

Dante: please grow up.

Patrick: I’m not quite sure how Suckerfish Dropdowns are ‘psychologically dangerous’, but when it comes to accessibility, they’re as accessible as any other dropdown method.
I explained why they are psychologically dangerous in my column. It’s right in the same paragraph.
As to accessibility: Suckerfish Dropdowns is inaccessible in IE Win without JavaScript. Saying that any other method is inaccessible, too, is true but not very helpful.
Dropdowns should be accessible. A true implementation would work in any circumstance.

David: So, even in your own eyes using CSS menus are the future. Therefore it would make sense to use a CSS method for menus now.
No, because it doesn’t work in all circumstances.

Bobby van der Sluis

May 26, 2004 7:16 AM

Interesting discusion. If we cannot answer the question if it really matters to use one technology over another, people will choose the method they personally prefer the best. Arguments like discussed in this article will help designers to choose the best fit.

The people from Opera and Mozilla state in their combined Position Paper for the W3C Workshop on Web Applications and Compound Documents ( ): “Scripting is here to stay. But should be avoided where more convenient declarative markup can be used. Scripting should be device and presentation neutral unless scoped in a device-specific way (e.g. unless included in XBL).”. However I think you just proved that one theory just doesn’t cover it all and that there are still a lot of open ends. New technologies as the CSS3 Generated and Replaced Content Module ( ) will even make this situation more complex.

For now it is best to use a common sense approach and determine from case to case which overlapping technology can be used best. With this we maybe could define a set of best practices that will help us all.

As an additional read for the people that missed it: Presentational JavaScript ( ).


May 26, 2004 4:26 PM

I apologize for the whole “Shaun/Sean” argument. Let us never hear of it again and pretend it never happened.

Besides, even if you do code for the standards you cannot reliably predict how browsers will handle your code. For example, I’m coding the pages for Yerba Buena Web Design and using XHTML 1.0 Transitional, but still I get problems (Mozilla not accepting margin: auto on the UL, for example).

I think I was too quick on the Flash thing. I didn’t like it because in Opera 7.23 the text goes away for like, 5 seconds then is replaced. I hated the idea of an image replacement technique that took 5,000 milliseconds.

For Yerba Buena I use PPK’s technique.


May 28, 2004 5:50 AM

Spot on. The FIR vs JIR thing is a perfect example – so many people were prepared to make an accessibility compromise when it was clear from the start that scripting cold solve this nicely. I think a third rule that I like is Use the technology that degrades the best.


May 28, 2004 8:56 AM

PPK wrote:

Defining a theoretical border between behavior and presentation calls for the abolition of the :hover pseudo-class.

What about :focus, does that pseudo-class also mimic a behaviour similar to onFocus?

Good article PPK!


June 1, 2004 9:51 PM

nice article, but you’re only voicing what you think is the correct/common sense use of JS/CSS.

it comes down to the designer. If i want a hundred lines of CSS to do something that would take 20 lines of JS, vice-versa, then that’s my choice.

i feel that you’re just complaining that everone’s using CSS “the way you think isn’t right’ nowadays.

I mean if it gets the job done..who cares.
I don’t see nothing in the W3c spec to say that i should use JS for IReplacement rather then CSS. comes down to as you say ‘personal choice’.

enjoy :p

Chris Heilmann

June 2, 2004 7:06 AM


that works in your own little environment, but as soon as you share the project with other developers 200 lines of CSS can be a lot more annoying than 20 lines of nicely commented JS code.

Think of the next one to alter your code beforehand and you have more time to create something new, as you make maintenance easier.


August 1, 2004 11:52 AM

Brilliant article =)

A minor point:

(It would be very easy to set up, though. Compare the amount of requests for a page with the amount of requests for its style sheet and you

Joel Finch

August 21, 2004 12:59 AM

ppk wrote:

Dropdowns should be accessible. A true implementation would work in any circumstance.

I have to disagree here.

It’s patently impossible to have dropdowns work “in any circumstance” – a text-only browser has no facility to display any kind of dynamic changes, and a browser where the script or css support is deliberately disabled is no different.

Of more value is to choose an implementation which doesn’t make the site impossible to use when the dropdowns don’t function.

I see dropdown navigation as a useful convenience for that segment of the browsing population whose browser supports it, but I recommend to my clients that if they choose to use dropdowns, they also ensure that the main navigation (available whether dropdowns work or not) leads to pages which include the same options as the dropdowns.

Whilst making the site as a whole accessible is an important goal, I think it’s perfectly acceptable to include conveniences which are available “only” to the majority of people who are using visual browsers with script and css enabled.

Just don’t forget to include alternatives for those without these abilities, and there is no problem.


February 2, 2005 6:03 AM

A dream comes true…
Here is the solution to the separation of behavior and presentation :

Phase 1 : Code your site without any presentation !

Your site should work with no presentation at all. If it works fine, you have XHTML pages “The Structure” (without any javascript into it) and some JS files which represent “The Behavior”.

Then, when behavior has been coded, you should :

Phase 2 : Code your site presentation (CSS+JS) without any behavior (the JS files you’ve already developed in phase 1)

Presentation is dynamic, so you should use the better of both worlds (JS and CSS) to develop it. The important point is to seperate JS scripts representing “The Behavior” from JS scripts used in conjonction with CSS representing “The Presentation”. The 2 phases above should ensure it.

Peter Hancock

May 14, 2005 12:10 AM

I’m not convinced that the suckerfish dropdowns are mixing presentation with behaviour. Really – they’re just styling up a list. Pretty simple. The list contains anchors, which – without the suckerfish styling, just displays like a website map.

Sorry, comments are closed.

Media Temple