Why Web Standards?

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.

Simplicity

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.

Readability

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.

Better Code

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.

Efficiency

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.

Subscribe6 Comments on Why Web Standards?

  1. Bill Mill said...

    hmmm… I’ll post a response by Tuesday. Until then, a few basic points:

    1) CSS is a poor standard that is implemented amazingly inconsistently across browsers, relies on wicked hacks to function, makes many simple things difficult and ignores brilliant prior art in the area. (Knuth? Anyone?) Finally, with CSS 3.0, it’s getting somewhere near usability, but who can actually rely on CSS 3.0? Hell, can I really rely on CSS 2.0 to work?

    2) The web works because of the looseness of HTML tag soup, and refusing to render a page because of a missing / at the end of a tag is terrible for users. It makes developers feel good to raise themselves up to the bar of XHTML compliance, but it’s intentionally fragile for no particular reason. In fact, that’s what I’ll call XHTML: web developer pullups.

    (Not that it wouldn’t be nicer for me if all pages were valid XML!)

    I give you Mark Pilgrim, who is much smarter than me, with his classic on XHTML: http://diveintomark.org/archives/2004/01/14/thought_experiment which was so good that it changed John Gruber’s mind on the matter, in another excellent article: http://daringfireball.net/2004/03/dive_into_markdown .

    Semantic markup rocks though, I won’t disagree with that.

  2. Rob Wilkerson said...

    Yeah, I completely agree with your point #1 except for the ability to rely on it. You can rely on it, you just have to do a lot more work to make it reliable. That sucks mightily, no question about it.

    Can’t agree with #2, though. The fact that the web ever worked with that kind of “looseness” is actually disturbing to me. Should C, PHP, etc. work without a closing “}”? Should Python work without proper indentation? Personally, I think not. Languages, whether programmatic or structural should have rules and should enforce those rules. Anything else opens the door to ambiguities that in turn force systems to make assumptions. In my mind, that’s never going to be a good thing.

    I understand that this is more problematic for users when dealing with interpreted languages, so C (as a compiled language) was probably a bad example above. C users would never see the error caused by the lack of a closing “}” since the compiler would catch it, but I still think the principle applies.

    That said, I’ll dig into the URIs you posted later tonight. I have a lot of respect for both of the authors. Perhaps I’ll have my mind changed as well.

  3. Bill Mill said...

    I’ll leave off #2 until I write more later – I think there’s still a lot to be said about that.

    As for #1 – eh. I guess I’m just bitter about how bad CSS sucks. I do use it, because semantic markup really rocks, but the fact that you need a wizard who knows the quirks of seventeen browsers and how they improperly render comments (!!) in order to get a layout possibly maybe correct is very frustrating.

    I’ve actually been having a pipe dream of implementing a better web layout language that aggregates the best parts of LaTeX and Postscript and PDF into something designed with the web in mind instead of print. What a cool project that would be!

  4. Rob Wilkerson said...

    I’ll wait to hear to continued thoughts then. I think we’re pretty much in agreement about the suckage of CSS and, more specifically, of the browser adoption/adherence to the spec. I mentioned the limitations and will forever hate them until they’re fixed, but its the cross-browser issues that are the root of this particular evil, I think.

  5. Bill Mill said...

    Douglas Crockford must have been reading your comments section: http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=777

  6. Rob Wilkerson said...

    Hmmm. Can’t (and won’t) argue with his CSS complaints. It’s all of those. If there were a decent alternative to CSS, I’d be happy to travel that path.

    I do think that the “many forms of presentation” he references are more than “theoretically interesting”, though. It’s pretty powerful stuff and, frankly, the web is not a traditional application platform. It’s part application, part marketing brochure (for better or worse). It’s also public-facing and, as a result, often the first impression of a company (or whatever) on a new customer (or whatever). That dual-purpose demands a certain amount of flexibility and produces a need for visual freshness.

    CSS, albeit flawed in implementation, offers that. Now sites can make small or even wholesale changes to their presentation with minimal effort and without touching their structure or content. That’s a pretty cool thing, I think.