Reasons not to Stick to Standards


Recently, I had a good rant about the importance of using standards. Today, I thought I’d present the other side of the coin: reasons why we should not stick to standards. I’m going to specifically discuss the case of XHTML compliance, but the concepts apply to any standard.

XHTML Compliance

XHTML compliance is an oft-touted phrase, usually used by developers as a claim of quality. Because of this, clients will often require XHTML compliance for their websites. This is understandable, and ensures that the code is well formed, so we can’t blame the client, but I’m afraid Black Square’s code is not XHTML compliant.

There are two reasons for that, but before I get there let me set some minds at rest. The XHTML standard is a very strict standard, and the benefits of adhering to this standard are many and obvious (see previous post about that). We at Black Square stick strictly to this standard, except where we quite deliberately choose not to. This decision is never taken lightly, but there are occasions when we feel it necessary.

Our mandate is to produce browser compatible, efficient, standards compliant code, and we prioritise those requirements in that order. We feel the most important thing is for a website to actually work on all the browsers we support. Within that requirement, we produce the most efficient code possible, in order to minimise download times and minimise the work the browser has to do (which produces faster sites). And within that, we strive to produce standards compliant code.

Browser Support

This hierarchy identifies the two reasons we might not adhere to the XHTML standard. The first is browser support. These days there are fewer and fewer situations where this case arises, but the fact is that none of the browsers currently available are themselves standards compliant. Sometimes this is because of a bug in the browser, other times because of a deliberate decision by the developers, but it is true of all browsers. Even your favourite one. This fact means that sometimes, we need to find work-arounds and hacks in order to ensure that the page looks the same on all browsers, and this sometimes requires us to step out of the standard. Fortunately, as the major browsers move closer towards being standards compliant, this will be less and less required.

Efficiency

The second, slightly more controversial reason is that of efficiency. This doesn’t mean that we’ll abandon the standard to save a line or two of code, but there are one or two cases where going beyond the standard brings efficiency benefits that far outweigh the dangers. For example, in our CMS the content editor exceeds the standard by adding non-standard attributes to tags in order to efficiently pass information to the browser that the standards authors never imagined might be required. This information allows the browser to identify what type of management tool will be required to edit each block of content, and to link that content to its place in the database.

We use the same technique in our new lightbox in order to provide a simple mechanism to pass complex meta-data and captioning to the lightbox control.

This may seem like quite a minor breach of standard, simply adding extra attributes, but it is the difference between compliance and non-compliance. I should maybe point out that it is not only Black Square who has taken this stance; many sites whose functionality has become too complex for the XHTML standard to support have taken the decision to exceed it. Facebook and Twitter both do this.

Standards are valuable, and very important, but, just as with any set of rules, you need to evaluate their usefulness before sticking blindly to them.

Comments are closed.