Of Men with the Brain on Both Sides and a Utopian Cult

Has it really been that long since my last post?

Nikhil Kothari updated his already cool site and I just had to leave a comment to compliment him on the great design work that he’s done. It is rare that a function person (i.e. software developer) has such a good handle on the form (visual presentation). In my experience, most people have either function side or form side developed. You are either a brilliant software developer who can only draw stick figures or a design genius whose eyes glaze over as soon as you hear the word “polymorphism“.

Unfortunately, the modern software development process outright requires you to possess both in order to be successful. Software design is half user experience. And the rising expectations of a quality user experience is what makes form suddenly so important. The users no longer find stark green-on-black TTY terminals acceptable — the PCs had spoiled them to point and click. They no longer want to fill out ten-page-length forms and type in dates — the expedias and amazons had made them expect to click once to get the reward. They seem to gravitate, sometimes subconsciously, toward professionally designed interfaces. The user wants to feel comfortable, and the bar of “comfortable“ slides up continuously.

Those who bridge the gap between form and function can keep up with this slide easier, simplifying the complexity of a development process by keeping both parties in the same brain. These types are the real gems that companies need to hunt for — if they want to stay in software development business. Soon enough, if you don’t have one of them, you won’t be able to keep up.

One other thing that I had in my comment is an offer to convert Nikhil to the “structural markup” religion. I neglected to mention that it’s actually more of a cult, where we share unyielding, radical beliefs about how HTML markup should be done, shave our heads and sing creepily monotonous chants. Well, we’re not yet doing the last two — the logistics of choosing the right chants are insurmountable, given our fondness for standards and the reputation for quickness that W3C has.

However, the “structural markup“ people do have strong beliefs about the markup. In its most abbreviated form, the idea of structural markup has to do with making sure that the HTML code reflects the structure of content, not its presentation. The presentation must rest entirely on the shoulders of CSS and client-side scripting. The markup is only there to reflect the logical structure of content.

For instance, my article about Piped Lists is an example of how you should only think of a horizontal list of links, separated by pipe characters in terms of its structure — it’s a list of links, which is expressed using UL, LI, and A elements. The parts about “horizontal” and “separated by pipe characters” is immaterial to the content structure and must be expressed using presentational means — CSS in this case. Similarly, the TABLE element should only be used to express two-dimensional relationships in content, not how the content is laid out. I am sure you’ve heard of “table-less” layouts before.

What are the benefits of structural markup? Well, quick googling reveals lots of existing articles attempting to list them. In my mind, it all comes down to separation of content from presentation. With structural markup, we have an opportunity to make a clean separation between the structure of a Web page and its look and feel, which is a requirement for any modern Web application, driven by the need for better maintainability of code, accessibility, and even performance.

Making your way into the structural markup world is not easy — the road, while marked, is quite bumpy. The uneven support of CSS and disparities in DHTML DOM implementation across browsers make for some hair-raising rides, frustrating enough to turn away even the stubbornest of the followers. Even so, the promise of the future where Web content is just content and nothing more is good enough for me to keep going.