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.
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.
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.
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.
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.
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.
With non-IE browsers and versions of IE past 6,
: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.
In an ideal world, then, ignoring browser compatibility, here are some things to consider when choosing what language to write a feature:
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:
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.