Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Javascript Bonsai Tree

May 04, 2004

I had an interesting question put to me the other week: what about making use of the null <script> element in the Zen Garden’s markup (so placed to avoid the flash of unstyled content IE bug) and open that up for submission as well?

The idea goes like this: separating presentation from structure is a good thing, and makes for better accessiblity (and all the other benefits of standards-based code, of course). Taking this separation a step further, and filtering out the behaviour as well should surely be a step in the right direction.

Peter-Paul Koch advocated just this in a recent Digital Web article that details the process, a practice I find myself compelled to. If it’s important to separate the style layer from the structure layer, it stands to reason that the same separation applies to the behaviour layer.

So I think there’s merit in the idea itself, and after I pressed, Rares Portan (the asker of the original question) put together this demo of how it works and what it can do. Since the behaviour is truly separated, you can see that it still works with strange results by applying it to some of the other existing designs.

Adding this extra feature to the Garden is dead simple. Administering it is a bit trickier — there are no automated tools to validate Javascript, and my knowledge of the standard DOM isn’t nearly solid enough for me to start making judgement calls. Should adding a design with script enhancement put the design on the same level as existing (and future) designs sans-script, or should they be featured separately?

But the main problem isn’t really administration. It’s focus: this changes the scope of a pretty well-established project. The Zen Garden has a nice and succinct mission statement: to highlight the beauty of CSS design. It worked out well in large part because people didn’t know what CSS could do; by now, most are aware of what Javascript is capable of. Are we proving something new with this?

Along the same lines, what new worlds would this open up? The test example adds animation, which is nice, but is that all a bit of scripting will buy us? I know there are applications I can’t even think of, but the behaviour layer is usually there to add functionality which is more hidden than visual.

So I’m opening this up for discussion. I’d like to get some reactions, but please note that today’s comment thread will be high-level: I’ll liberally delete off-topic and useless comments. Thanks, looking forward to the feedback.

Reader Comments

May 04, 01h

I agree that the general sentiment that the CSS zen garden should remain just that: CSS oriented. Javascript has been around for years, and while it’s use seems to have diminished to form validation and image rollovers, it’s not a technology that needs an increase in visibility like CSS does.

A good point that has been raised however, is the CSS styling of forms. I think that either adding a form into the current base xhtml document or creating a new sub-section to the zen garden specifically for styling forms would be exciting to see. Even *I* put together my own form for fun: (although, it could use some javascript functionality to make it really punch! :) ).

jgraham says:
May 04, 01h

It sounds like what you’re really looking for is XBL, which allows one to attach pieces of script to an element in the same way that CSS allows one to attach pieces of style. It’s probably the most interesting technology currently in the works at the W3C (well SVG is pretty exciting but I get the impression that the working group’s gone cukoo ( ) - and distressingly they seem to be taking both XBL and CSS down wiith them).

Anyway. Javascript is A Good Thing, if used correctly. It can solve a bunch of issues that CSS struggles with (e.g. you can’t do proper on-click menus with CSS, just on-hoover menus. Hover menus are much harder to use than click menus, and probably moreso if you have less than ideal motor control). So, if people were going to be using Javascript to enchance the behavior of elements on the page then I’m all for setting up a specal subsection of the garden to demonstrate the possibilities.

If they’re just going to use javascript to provide cheap animation tricks, it’s not worth the effort.

If you do decide to go with a Javascript-allowed sectiion, I would suggest getting someone more familiar with web scripting to assess the incoming entries.

May 04, 01h

The things I love the most about CSS Zen Garden are its focus and limitations, which clearly show the power of CSS based designs. With this new idea you could loose a big part of the focus and limitations, which obviously will change the identity of the current Garden.

Still I think there is room for extending it, as long as you keep focussed on the presentation layer. Zen Garden is about separating structure and content from presentation, and that is where a possible expansion should be.

DOM based scripting could add value to the presentation of a web page on places where CSS currently lacks support. Like many others in this discussion I believe that there is something called ‘presentational JavaScript’. Why should JavaScript by default be behavior? A script that positions a container on load or on resize like I described in my Exploring Footers article ( belongs more to the presentation than the behavior layer.

Fixing IEs shortcomings is another good example, so are scripted mountain top corners ( and even Flash Image Replacement should belong to this category. Actually you already extended the Garden in this direction by using the htc hack in design 100.

Steve says:
May 04, 02h

Being a bit of a javascript-head, I have to say that I find the notion of adding a behavior layer to zengarden designs very intriguing. Lots of interesting ideas come to mind…

I don’t see it as an intrusion on the CSS promotion effort of the Zengarden - javascript must rely on CSS rule manipulation to effect the DOM as well. All of the experiments on my site rely heavily on CSS as well as javascript.

The only rule I would implement is that any behavior added via scripting should degrade gracefully into something usable if javascript is disabled - and I think any site that uses a behavior layer should be clearly marked as such to avoid any confusion.

May 04, 02h

At first this sounded like a good idea, and I was initially excited. However, simplicity in the garden has been the focus. I think the ideas of either an alternate domain, or alternate set of sites linkable by some other manner present the most consistent and productive form of allowing this. It also would allow you to make some changes to the HTML that you have mentioned [somewhere, but I don’t recall where - I could be completely attributing to you something you’ve not said].

You may also consider setting a boudary on what can be done with the JavaScript. Functionally speaking a javascript could create a whole secondary set of HTML, thus rendering the page a totally different way because the HTML is NOT the same.

Thanks for asking for opinions!

May 04, 03h

as has already been noted, i think this would go against the original idea of the *CSS*zengarden. i’d say this could be a good time to start a new sister project, which includes both css and javascript submissions. otherwise, i can’t send people to the garden anymore to just show them how powerful css is, without having to mention “oh, no, don’t look at that…that’s javascript driven”

oh, and yes, the concept of separating all behaviour out of the xhtml is a sound one. i’ve been using it in quite a few little experiments and projects. it’s a very powerful thing being able to: a) work on a cleanly structured and accessible xhtml document; b) style it beautifully; c) add interaction (and also use javascript to rewrite/move/etc parts of the page for increased usability without damaging accessibility)

May 04, 03h

This will be little more than an extra echo, but one of the compelling things about the Garden is indeed its limitations. The prescribed bounds of what can and can’t be done actually help foster creativity. It’s also easier to sum up the Garden when presenting or describing it: “All that’s different is the style sheet.” So I feel that allowing the addition of arbitrary JavaScript would dilute the message and intent.

Cultivating a separate garden that did allow arbitrary JS as well as CSS might be interesting, but it should be just that: separate.

I say this with the full acknowledgment that “15 Petals” ( uses an HTC file—which is a lot like JavaScript—to get PNG alpha-channel support in IE/Win. At one point, I was going to have the ZG entry use a GIF and explore the PNG approach in the book (, and if you want to take it back to that in order to re-purify the submission, and thus the Garden, I’ve no opposition. On the other hand, if IE7 ( reaches a stable release point, perhaps linking that in would be a worthwhile step. Thus the HTML and JS/behavior file would be untouchable, but the CSS would still be open for designers to go crazy.

May 04, 07h

As Eric noted, probably the one element that is the essence of the Zen Garden is limitation. You cannot touch the structure of the document in any way, only the CSS, and this provides a powerful example of what CSS is capable of.

Allowing JavaScript, on the other hand, would not be a demonstration of what is capable within limitations, but what is capable with unlimited power.

I could validly code JavaScript which says:

document.geteElementsByTagName(“body”)[0].innerHTML = “Everything is gone”;

An extreme example, but such content replacement places no limits on what can be done to the Web page, not even short of replacing the entire page. This would truly destroy the point of what I believe the Zen Garden is trying to achieve.

May 04, 09h

“Same goes for CSS, though.”

This is true, and I should have pointed it out. Both CSS and JS can be applied in a manner that is document-independent. For JS, it’s something like extracting the “title” attributes of images and adding it to a paragraph in the DOM. For CSS, it’s limiting yourself to selecting non-ID’d elements (and, to a certain extent, non-classed elements) and styling them.

“Maybe in this case animation isn’t a ‘behaviour’ but that’s getting semantic; the point is more adding extra effect through script that CSS alone won’t afford you.”

I agree. This is the reason why I don’t think JavaScript can really be called an independent “behavior” leg so much as a way to add behavior *as well as* presentation and even content (although I don’t think adding content via JS is a good idea in almost any case). JS can be applied to everything, and it just so happens to be *the* way to add behavior.

May 04, 10h

Strange results indeed. It makes one wonder how much behavior can really be separated from the structure, because to achieve the desired effect, certain structure *has* to be present. The exception are scripts which, say, make the title attribute of images visible on the page. Things like that.

It seems that the effect being achieved by the example script, while stunning, is still part of the presentation layer. To me, “behavior” comes into play when user interaction is concerned. Perhaps behavior and presentation have close ties. But it seems this particular “behavior” could be achieved equivalently by image-replacing a (large) animated GIF.

JavaScript used to create menus, form interaction, etc, could be classified as behavioral. However, this use of JavaScript is still presentational in my mind.

Ranting aside, I agree that this would sort of blur the focus of the Zen Garden. Perhaps it would be good to keep scripted entries on a separate, but still prominently visible list. Of course, the nightmare comes when you have to add this list to existing designs…

Keith says:
May 04, 10h

While I’ve got to say I find the theory very interesting as well as the examples you provided – I’m not sure how much value there is in it as far as the Garden is concerned.

As you say, we already know what Javascript can do. And this is about CSS.

But then again, it might be an interesting adjunct to the Zen Garden…It might be nice to see what people came up with.

Maybe the JavaScript Zen Garden?

Dave S. says:
May 04, 11h

“It makes one wonder how much behavior can really be separated from the structure, because to achieve the desired effect, certain structure *has* to be present.”

Same goes for CSS, though.

“To me, “behavior” comes into play when user interaction is concerned. Perhaps behavior and presentation have close ties. But it seems this particular “behavior” could be achieved equivalently by image-replacing a (large) animated GIF.”

Sure, but so can most Flash effects, given multiple megs and a lot of bandwidth. It’s about using the right tool for the job. Maybe in this case animation isn’t a ‘behaviour’ but that’s getting semantic; the point is more adding extra effect through script that CSS alone won’t afford you.

“I’m not sure how much value there is in it as far as the Garden is concerned. (…) But then again, it might be an interesting adjunct to the Zen Garden… It might be nice to see what people came up with.”

More or less what I think right now. I’m hoping to see a few good arguments either way.

Rares Portan says:
May 04, 11h

“If they’re just going to use javascript to provide cheap animation tricks, it’s not worth the effort.”

This hurts, you may be right, but this is not the point, my theme was just a proof of concept, nothing more. I’m sure that out there are people that can create remarkable CZG themes with both CSS and javascript.

If people don’t know or don’t care about javascript it’s allright, if they never dreamed about translucent PNGs in IE/Win, please, just ignore it.

But way discriminate others, who dare for more?

May 04, 11h

For one thing Dave, using a separate behavior would allow “This is Cereal” ( to work in ALL modern browsers. The drop-downs, the transparency–all of it.

It _does_ dilute the Garden’s message but…when do we get to play?

May 04, 11h

As far as I see, there aren’t any FORM elements on the zen example - however, I’ve read some interesting articles on CSS styling of FORM elements. The Zen Garden is all about the beauty of CSS based designs - isn’t a FORM (or couldn’t mind be a better word) be considered as part of a design?

Well, using a FORM element in the Zen Garden might prove to be useful, as there are some pretty horribly designed FORMs out there. Perhaps utilizing some javascript to process the form, whatever it’s function, and creating ways via CSS to show some well designed ERROR and SUCCESS messages. Or, being able to visually show the user what FORM elements they’ve missed, or filled in incorrectly.

Being that I work on eCommerce websites most often, I’d really be interested in seeing some new FORM ideas that would make a FORM a) user friendly b) nicely designed (pleasing to the eye) c) and actually looks inviting so that the user would want to correct their mistakes.

mike says:
May 04, 11h

I feel that adding scripting to the csszengarden as it currently is will dilute its effectiveness and purpose. It would be a better project for someone who knew valid and appropriate JavaScript and could, at the bat of an eye, say “Yay” or “Nay” to a particular implentation. Furthermore that site should be javascriptcsszengarden, to seperate the purpose of each site, and increase the effectiveness of each.

May 04, 11h

I don’t like the idea. The good on CSSZengarden ist that I can show people what ist posible without scripting and with to some extent good markup.

What about ? This domain is still free!

Terrence says:
May 04, 11h

Having the freakish combination of an artist’s hand and a scientist’s mind, I believe the experiment that is CSS Zen Garden should have controlled and constant parameters. The Garden showcases CSS superbly. It’s one xhtml file with varying stylesheets. Simple yet flexible.

So should it showcase CSS AND all it’s cousins? This javascript addition looks intriguing, but, as stated above, an animated gif or even Flash movie should be less cumbersome. The above examples show a sliding element, what else can be done?
Doc Ozone Doc Ozone has always impressed me with his js acrobatics, are these the caliber of features that could be integrated into CSS/JS Zen Garden?

May 04, 11h

The demo is really beautiful, but I agree it’s more presentation than behavior. Such effects should be used on cssZenGarden to show how it can be used for presentation.

I think that behavior only uses of javascript should not be published on the garden, but I’m sure there is room for a new behaviorZenGarden somewhere … ;)

May 04, 11h

Personally, I’d like to see the Zen Garden remain how it’s always been. Over the last year it’s been wildly successful, and it seems like a shame to add a new ingredients to the mix now. I say if you do decide to add the ability to use scripting, at the very least there is a separate section for it. I like being able to look at the designs, and know it was all made possible with CSS alone.

May 04, 11h

must agree with Shaun. js should only be allowed within csszg when it empowers IE’s css… as in whatever:hover, svend tofte’s maxwidth, etc… maybe when dean’s-IE7 is available it could be a default for the garden…

I find it’d would lose focus if you turn it into a ‘layers-you-can-put-over-xhtml zen garden’

on the other hand, it would bring a whole new world of possibilities (and people) to the garden… dunno…

tim says:
May 04, 11h

Why not doing some “zengarden enhanced” where the goal is to show what designers can achieve with all those modern ways of standard compliant webdesign? JS, CSS, XHTML and maybe even Flash.
With different, yet simple (just like the garden’s) rules: Everything is OK, as long as the site validates, uses a list of important elements (a form for example), is accessible and seperates style and content.

Jimmy C. says:
May 04, 11h

What about XSLT? That can-of-worms combines the power of JavaScript with the philosophy of CSS. Should it be allowed?

Personally, I believe JavaScript should be allowed to compensate for browser bugs with CSS. This means Microsoft’s DHTML Behaviors and Mozilla’s XBL. It doesn’t mean JavaScript menus or onclick attributes.

P.S. I wonder when the first Flash-replacement designs will start show up (as opposed to FIR).

Dave Cunningham says:
May 04, 12h

Mike had it right on in his above comment, but I’m going to elaborate.

You should not allow JavaScripting in the CSS Zen Garden for one simple reason: you do not know enough about JavaScript to properly administrate it.

On a contrary note, few people know JavaScript’s capabilities and its relationship to the W3C DOM; that much is obvious by the comments on this site alone. Even fewer people understand that it is possible to use JavaScript to enhance usability and design without sacrificing accessability nor having to touch the markup of a page any more than CSS (Shaun Inman can tell you a little about this). Even fewer people beyond that know about both the brilliance and shortcomings of JavaScript’s design as a language. With all this in mind, educating web designers on JavaScript the way you’ve educated them on CSS would be a boon to the web.

Regardless, however, without someone like Peter Paul Koch to help you tend to the Garden, letting artists add JavaScript to their designs would be not only a hazard to the Zen Garden, but a hazard to web development as a whole.

Besides, you’ve kind of trapped yourself with the Garden’s domain name in the same way that the UPS have trapped themselves with their name.

Terrence says:
May 04, 12h

I could go along with the idea of a sister site to CZG. (Maybe JS Coy Pond) But if that were to happen, I should think that it wouldn’t be the same xhtml structure, but another markup with content detailing the fusion of JS and CSS.

Could be promising…

May 04, 12h

While the idea is interesting, I believe that the Zen Garden should remain as it is. It’s really great that you can separate behavior from everything else, but the purpose of the ZG is to showcase the power and beauty of CSS. Keep things simple and avoid delving into unnecessary features. Which is more popular – the Mozilla suite or Firefox? :)

Dan says:
May 05, 01h

You can’t change the rules halfway through the game!

May 05, 01h

Dave - You might remember that about 6 months ago I wrote directly to you with some examples of adding Js to the garden. My idea was to dynamically switch stylesheets based on the browsers window size, so that the designer had the ability to make better use of white space where it was available, and perhaps even address the fixed vs fluid debate which was raging at the time.

I agree with others that perhaps the garden should remain CSS only, but I do think that there is a place for JS enhanced designs. It does introduce the risk that designers are not programmers, but did the rules ever say that CSSZG submission could not be team efforts?

Reading the other comments here it seems that many of the ‘designers’ think that JS is naff - they can do all they want with CSS. But then I’d argue that is all the reason you need to create another showcase for JS enhanced sites. One of the big challenges would be to ensure that JS enhanced sites are still accessible - now thats what I call a challenge!

Tom says:
May 05, 02h

Keep it with CSS, sure that javascript thing is nice but its the _CSS_ zengarden.

You should offically not ask for java, but if/when people do submit them, slap them in another section like “Java enabled” :\

Rimantas says:
May 05, 02h

As many others I am for leaving zengarden intact.
I am not sure if separate procjec would suceed, though…
But I think behaviours should be promoted as a much cleaner way to add extra funcionality to webpage without cluttering it with “onwhatever” things.

jgraham says:
May 05, 02h

>>“If they’re just going to use javascript to provide cheap animation tricks, it’s not worth the effort.�

>This hurts, you may be right, but this is not the point, my theme was just a proof of concept, nothing more.

Sorry, I didn’t intend to disparage you personally.

My point was simply that, used correctly and selectivley, javascript can be an accessibility boon for sites. Typically, ‘correct’ usage in this sense will mean adding behavior to elements rather than adding content or style. I would be interested in seeing a zen garden where javascript was used to enhance the interaction between user and page whereas I wouldn’t be so interested n a zen garden where javascript was used to provide addiitional style.

ppk says:
May 05, 05h


Thanks, Dave. I’m very, very glad that one of the paragons of CSS design takes JavaScript sufficiently serious to take this step.

I agree with most commenters that the example script is only a matter of a minor presentational tweak. I feel that we should come to a definition of what JavaScript can do for CSS layouts.

Therefore I coined the principle of “Minimal CSS Enhancement”, meaning that we should write tiny scripts that tweak only one single style value to solve a CSS problem, and leave the rest up to regular style sheets.

As an example I wrote a Three Column Stretching script, . Note that this script is not yet ready for prime time because of browser problems. Instead, it’s meant as an illustration of the principle.

In addition, Bobby’s remark about “presentational” vs. “behavioural” JavaScript requires urgent attention. Does my Minimal CSS Enhancement principle solve this question, or do we need an extra round of fundamental thinking?

In any case, I’m very, very curious what will happen next.

May 05, 06h

thought i’d add my threepennyworth…

much as i love javascript and programming generally, it has no place in the garden. the exception to this, as eric and others have pointed out, is where it fixes known browser problems.

keeping the garden metaphor, we can use behavioral extensions (javascript) to fix the garden fence but NOT to make the flowers prettier…

perhaps publishing a list of allowed fixes (whatever:hover, png-behavior, IE7 etc) is an acceptable compromise?

May 05, 12h

I couldn’t agree with Cameron Adams more. I’m a jazz musician (and a future software engineer). When learning how to improvise, beginners are taught to keep it simple. As they progress, they can “spread their wings” and increase their musical vocabulary, using more tools as they pick them up. However, there comes a time in the maturation process where an accomplished soloist must use only a few techniques during a solo. It fosters the creative juices, and forces them to improve their technique while using those specific tools. Miles Davis did this in “Kind of Blue” and created a whole new genre of music (Cool Jazz) in the process.

It’s like using a limited palette. I’m sure you can appreciate that, Dave. There’s something to be said about creative works made with a subset of available tools.