I went to the inaugural meeting of the Refresh Baltimore group last night and, in the early minutes of the meeting, a short discussion broke out around the adoption web standards. I have to admit that I was a little surprised to hear more than one person express at least some level of apathy with respect to implementing standards in their own work. The primary reasons for this apathy seem to have something to do with the avoidance of blind adherence to arbitrary standards, a perceived limitation on design and/or the level of difficulty.
The first is a specious argument at best and can be dismissed as such. I’m not espousing blind adherence to anything. Additionally, I don’t believe that web standards are arbitrary in any way. The standards being discussed have been identified, considered, collaborated on and documented by other web professionals. These are (for the most part) very smart people who have put a lot of thought into such things and have provided a logical foundation on which the standards are built. If they were anything less, the adoption rate as it stands today would be far lower. We, as a community, are not lemmings. One statement I heard was that, “we should be creating the standards.” I would argue that we did. The collective we of web professionals, that is.
That discussion prompted me to more methodically consider my own reasons for adopting web standards and for driving that adoption in my own workplace.
What are Web Standards
To introduce this topic, I should define the key term. Here, I’ll be using the term “standards” in many ways to reflect the ways that I use it and hear it used depending on the context. Prefaced that way, the term “standards” will be employed to mean:
- The use of CSS layouts rather than table-based layouts
- The use of semantic markup
- Adherence to a defined language specification or doctype
Arguments For Employing Web Standards
I’ve heard a lot of reasons for adopting web standards over the last few years. Those reasons range from the simple, “everybody’s doin’ it, doin’ it, doin’ it” which can be construed (and occasionally misconstrued) as blind adherence, to the esoteric. The former is probably more accurately classified as an appeal to authority fallacy, but there is an argument to be made that this appeal is blind by its very nature. I’d like to believe that my own reasons sit somewhere firmly in the middle. Hardly blind, but I’m not smart enough to over-analyze things. I’m a simple guy.
Arguments Against Employing Web Standards
Similarly, I’ve heard a number of real reasons to ignore web standards. Although I disagree with them, the arguments are thoughtful and worth considering. As I mentioned above, in almost all cases, these boil down to one of the following:
- Standards have a negative impact on design
- Employing standards is difficult
- The “old way” works
No. And yes. And argh. Respectively, of course.
Negative Design Impact
Within the standards community, there seems to be a certain degree of preference for a simplified design aesthetic, but that’s nothing more than an aesthetic preference shared by a like-minded community. It’s hardly a limitation imposed by the use of standards. The fact is, standards don’t even come into play until a design is implemented. Bring it, designers. It can be built. It may be harder – complexity in design is harder to build than simplicity whether standards are employed or not – but it can be done.
Level of Difficulty
I have no means of negating or even mitigating this argument. It’s true, standards are hard. CSS is not easy. Sure the syntax is easy, but that’s where the simplicity ends. In addition to -browser implementation differences there are also limitations within the 2.1 specification.
The beauty of the first concern, browser implementation issues, is that standards, once widely adopted and employed, will all but negate the concern. In other words, the creation and adoption of standards will mitigate or even eliminate one of the primary reasons given for not adopting them. Efficient.
The limitations are a bit tougher. They exist and they’re real. Ever tried to create two columns of equal height regardless of content? Ever tried to create a page with a header, footer and body whose height should not extend beyond the height of the window area? Ever tried to vertically align one element in the middle of a parent element? These things are hard. In my opinion, much harder than they should be. They are, however, limitations of the language itself and the language can be “fixed” with each subsequent version of the specification.
It’s hard, but take heart. It gets easier. Trust me.
The “Old Way” Works
So did Internet Explorer 5. Times change.
With all of that said, I still choose to employ and evangelize standards.
Why I Prefer Standards
Finally, we come to the real question that kicked off this thought.
Separation of Concerns
In my mind, this is the most important reason for developing to standards. Standards – in this context meaning the use CSS layouts – allow for the separation of presentation from content. This is not a new concept. OOP developers have been practicing this separation of concerns very effectively for a very long time. CSS allow web designers and front-end developers to employ the same technique in a different setting.
Use markup to structure the information contained within a document and CSS to present that information. Done properly, this separation makes it remarkably easy to update a site’s “look & feel”. The efficiency of this kind of structural discipline is highlighted during later maintenance phases of the project. Any time cost created by the learning curve is quickly negated by the long term maintenance savings.
Another benefit of standards is streamlined markup. Fewer tags, fewer attributes of those tags. The document’s markup is no longer responsible for dictating its presentation once that burden has been delegated to its style sheets. Take it a step further by separating behavior for content and the markup gets even simpler.
When faced with the choice, I’ll (almost) always prefer readability to performance. Simplicity, as mentioned above, offers one measure of readability. Less is easier to read than more, right? Another measure is provided by the use of semantic markup. If every element within a document is properly identified, the structure of that document is easily discernible.
As a developer, this is the end game. I am, of course, assuming the obvious – that the code does what it needs to do. If this is not the case, then the developer won’t be a developer – or at least an employed developer – for very long. When all is said and done, by whatever means I choose to employ, my goal is to produce better code.
My standard of choice, with respect to doctype, is XHTML 1.0 Strict. I made this choice not because the language spec is perfect (it isn’t) or because browsers handle it better (they don’t; IE, I’m looking in your direction). I made that choice because it forces a valid, well-formed XML document. The boundaries of XML offer a measure of clarity – no more questions of where an element ends – and dictate a certain measure of consistency across documents and projects. Consistency is good.
As an individual developer, all of the reasons listed above add up to increased efficiency. As the leader of a team, there’s an extra benefit. Code reviews are much more effective when rules are in place. When more of those rules are dictated and enforced by the tools and methods chosen, then reviews can be less subjective. The rules are documented and become inherent to the project itself. If the document validates then, at its most elemental level, the code is “good”. Reviews don’t end there, of course, but it’s a hell of a start.