Hans Sprecher

Separation of Church and State

Hans Sprecher, @honzie


I was cruising along a highway in Hawaii with my entrepreneur buddy Max, explaining some CSS3 UI experiments I was playing with. He had only one thing to say:

“This makes me angry.”

What he meant was that the web stack had, up until all this CSS3/HTML 5 nonsense, been relatively easy to understand. There was a simple set of guidelines that, when followed, led to semantic websites that were easy to maintain and of a sound architecture.

Max is an astoundingly talented backend coder who often dabbles in the front end. Since CSS and HTML now have stepped up to handle some portions of style and interactivity, we need new talking points and new models for thinking about content, style, and interaction.

Interactivity in your HTML

The basic piece of interactivity on the web is much the same now as it has always been: the anchor tag. That's right, the simple <a> tag drives, by far, the most amount of interactivity. Today, links are best coded in HTML, rather than in JS. There are several reasons for this:

As a general rule, if a feature can be done easily with a browser-native implemenation, I believe it's best to code it that way. Browser native implementations tend to be faster, less fragile, and have all the invariants and interactivity patterns thought out by people more clever than me.

In any case, the link goes to show that interactivity on the web, at its heart, can and should happen in HTML.

Web Forms

Only clicking around a website can get boring. So, we need some more robust interactivity patterns. Beyond links, web forms offer a deeper level of interaction. Historically, as today, forms are a series of HTML elements (text inputs, radio buttons, checkboxes, etc) that allow the user to enter information. This information is usually submitted to the server for processing. The server can then decide what to do with the information. Most often, it saves the information and sends the user to an appropriate page.

At their heart, web forms are pure HTML assisted by some back-end server technology. However, today, we have two common patterns where JavaScript can be used to offer better form interaction.

Client Side Form Validation

The first pattern for using JavaScript to help with form interaction is to validate the form as the user enters data. When a user pauses in a text field, or—more often—blurs away from a field, a JavaScript function can be invoked to validate that the data is correct, or roughly correct.

Since forms are easy to tamper with, any JS validation should be redone on the server side. Therefore, client side validation is done to give the user a tighter feedback pattern, alerting them quickly if they enter something incorrectly.

However, HTML 5 offers some provisions for client side form validation. In the near future, HTML will allow for some small amount of client-side validation. However, more complex validation, particularly pattern matching or AJAX validation (e.g. is this username already taken?) may remain in JS forever or for quite some time.

AJAX Form Submission & Saving

Another place where JavaScript comes in handy is submitting or saving the form via AJAX. This can be nice, since it can be used to save the user's progress as they move through a complex form with many steps, or allow them to submit the form without having to move on to another page.

Interactivity in your CSS

With the release of CSS 2's psuedo classes and their application to both links and (post-IE6) all elements, we started mixing interactivity into our CSS.

Link Colors

By default, links act like they do on Craigslist: blue and underlined for normal links, purple for visited links, and red for active links (a link that's currently being clicked on). However, once the color, background, and text-decoration (read: underlined or not) could be controlled by psuedo classes, we started adding interactive controls into CSS.

CSS could dictate: when a menu link is hovered over, change its color, add an underline, or change the background color or image. This practice is now extremely common in CSS. Writing the hover/focus/active CSS styles is far easier and less fragile than writing the similar code with JS. In fact, the JS would either be manipulating the styles directly (which is a poor practice) or add and remove classes, which is essentially the same as using psuedo classes.

Dropdown Menus

With non-IE browsers and versions of IE past 6, :hover, :focus, and :active could all be applied to non-a elements. This opened up a whole new world of possibilities. Suddenly, it become possible to change the display of a child element when the parent was hovered over.

This means that hover-actuated tooltips, popover dialogues, and dropdown menus (remember the Suckerfish demo?) were possible in CSS. The addition of hover interactions in CSS allowed for a slew of possibilities to add interaction that was once only possible in JS.

Shades of #666

Things aren't as clear-cut as it would initially appear. In the current state of affairs, we have a great deal of interactivity in our HTML and CSS. In fact, HTML and CSS have evolved to meet the needs of developers. HTML and CSS have faithfully expanded to include things that once required JavaScript or plugins to do. In the future, this trend is likely to continue. Looking at much of the HTML 5 spec handles around adding semeantic value with new elements and interaction patterns with new attributes.

Now that we've looked at the present state of interaction on the web, we see that things are quite more complex than the naive suggestion of encoding all interactivity in JavaScript.

Where this Leaves Us

Taking the evolution of HTML and CSS to its logical extent, all simple and oft-done features will likely be moved from JavaScript to HTML and CSS. There is one main caveat to this: JavaScript is a Turing complete language, while HTML is just a markup language and CSS is a declarative language. Therefore, anything that requires functions, recursions, or true variables (all this talk of CSS variables is really talk of CSS constants) must remain in JavaScript, unless the nature of HTML or CSS is drastically changed.

The Ideal World

In an ideal world, then, ignoring browser compatibility, here are some things to consider when choosing what language to write a feature:

The Real World

Finally, for the real world checklist. Here are a couple principles and guiding factors to help decide which of the three web languages to encode something:


You need to consider your user base, their technology, and your current team before stripping out vast swaths of JavaScript. However, HTML 5 and CSS3 are making many things possible that were once only possible in JS. In fact, the only things that will likely be tied to JavaScript in the future are things that require a full programming language. Some data manipulation, browser APIs, and data transfers are likely to remain part of JS, but much of our other simple interaction may be best left to HTML and CSS as it becomes feasible to do such.

Max may still be angry about all this, but hopefully this article offers some direction in order to figuring our what goes where in the web stack.

Have further considerations about where interaction belongs on the web? Drop a line to @honzie.