Coding as craft
Serendipitously, a week after our latest periodic posturing about the importance of coding to web standards, Digital Web Magazine yesterday published Garrett Dimon’s must-read list of 21 guidelines for approaching Markup as a Craft. And I quote:
Markup is the technical foundation of front-end code. In one way or another, it influences or is influenced by design, content, accessibility, CSS, DOM scripting, and more. The quality of your markup will affect the quality of related code, and even the cost of implementing or maintaining that code. … Carefully crafting your markup is like making a lucrative investment in the future of your code base. It’s easier to create and maintain back-end code when it integrates with clean and simple markup. Your CSS can be elegant. Your DOM scripting can connect seamlessly. … It’s time to treat markup as a craft, and give it the love and attention it deserves.
All 21 points of emphasis in this article are worthwhile. A few jump out to the Webdogs because of our experience re-coding an earlier version of our beloved Pika. True, our re-coding was not remotely as optimal as it could be, but we are determined it will be with our next iteration. In our prior work there were a number of functionally adequate but less than stellar coding approaches we took, including too many semantically invalid form elements. That said, with Project Claire we proved among other things that you can build a UI without relying on semantically incorrect table elements to control layout and positioning (we stripped out every last table element in Pika that was not a data table); with due care, more often than not you can remove out-dated, deprecated structual elements embedded in scripts and replace them with up-to-date code in templates, where the structural markup belongs; and you can and should dramatically improve control of the presentation of the CMS by removing all — and I really do mean all — inline style elements from scripts and templates. (True again, our CSS for Project Claire is a bloated spectacle of redundancy and underutilization of the cascade, but as we were saying, our coding was valid but not optimal.)
Given the not inconsiderable work involved in re-coding things, it is understandable why long existing websites and CMS builds are not up to current coding standards. But what is the justification for launching new designs or rebuilds without conforming to now widely adopted coding standards?