Changing (or rather re-educating) The Old Guard

I read an article today from the latest edition of A List Apart talking about web standards, their importance, and different approaches to them. The article, entitled Where Our Standards Went Wrong, talks about these two opposing mentalities about web standards:

• Standards must be adhered to rigidly. If you don't, then its just wrong.
• Standards are there as a guideline, and can be a barrier to commercial development. Be pragmatic and break them if you feel it necessary.

The article makes for a good read, and the inevitable battle of opinions that follow in the comments is equally enjoyable, and does seem to split developers into those two ranks. However, as I posted in my comment on the subject, I think we need to add another category to the mix - And this is a category that needs to disappear over time:

• Web standards should be followed. We know this because we are told so, but we are used to developing from our days before the semantic web, and so don't really understand the spirit of a great deal of it.

I happen to work with some people with this problem. They have been in the web development game for many years, and they keep up on what they need to in order to get work (as contractors, freelancers, or permanent staff). They haven't, however, really paid attention to the logic behind the rules. They have not adapted their methods of working from the days of table-based designs. Sure, the tags they use are different now... But that's about it; They have simply replaced trs and tds with divs and spans.

Symptoms of an old-guard coder should be fairly easy to spot mostly - Heavy, "tag-soup" style, non-semantic xhtml code and huge css documents are generally a giveaway. As someone being pulled onto a project half way through, and having to deal with this, it can make things slow and painful. It makes their pages heavy and slow, and eat up more bandwidth than they need to, too... But they don't know that they are doing anything wrong - Because the code validates.

It can be very hard to tell these "old-guard" developers that what they are doing is wrong. Often, they cling to the rules which they follow as an illustration that their practises are perfectly appropriate. They seem to struggle to understand that validation is not, in fact, the be-all and end-all that it can often be made out to be by "standardista evangelistas". In this sense, I feel that there being so much preaching about standards compliance has in fact harmed the quality of development from some of these individuals. It has made them short-sighted, and given them a set of rules to cleave to whilst they happily ignore the guiding principles that surround them.

Unfortunately, unless they are shown the errors of their ways, they will never change. They need re-educating in order to see what they have been doing wrong. But how?

Personally, I would start by sitting down and talking about semantics and their importance to us as web designers and developers. I am, in fact, hoping to run a series of "workshops" where I work to accomplish this goal, and this is where I intend to start. Using practical examples works well, too... If you can. I am in the (un)lucky position that I was handed a poorly coded UI and told to re-build it from the ground up as one of my first jobs when I got here... So I already have a "before and after" example that I can use to illustrate my points. Above all, I believe you have to be prepared for some level of resistance when trying to accomplish something like this - No one reacts well when they are told that they have been working the wrong way for the past 2 years, particularly when they firmly believe they have been following all the rules, and were doing just fine.

So from the old problem of "How do you sell standards to a business?", we now have a new problem: "How do you re-sell standards to the (badly) converted?" Again, it has to be about selling benefits - Both to the business (which is, after all, who they are working for, and who they have a duty to produce the best work possible for), and to them, as well.

For those of you who are reading this post and are feeling somewhat bemused as to the real nature of the problem (After all, they are following the rules, right?), then allow me to explain. This situation is quite similar to the old "letter of the law vs spirit of the law" argument: It is possible to follow all the rules to the letter, but completely ignore the reason those rules were set in place, and the intended effect. One of the primary goals of the xhtml standard was to separate content from presentation - Previously a page's content was surrounded by presentational markup: In-line styling, table rows and cells to dictate positioning etc. With xhtml the intention is to keep these things separate: The xhtml page should define the content, the sections that content falls into, what each section does etc, while the css that relates to those sections should define the look and feel of the page. When you start adding span tags all over the place to change the look of a link, and start naming classes "redtext" etc, you are destroying those boundaries. You are again putting presentation back into the html page.

Again, some people reading this may say "Why is that a problem?". Well, it's not... Unless you ever want to update the look of your site, make changes to layout or content, add or remove items - Basically do anything with the page once it is "finished". All the extra markup makes it much harder to find what you are looking for when wading through the html code, and classes and IDs that reflect the presentation of an item rather than its function can be extremely confusing if the style is changed later (Think of a class called "redtext" where the text is actually blue!).

On top of this, the extra code makes for extra data, and extra data makes for extra bandwidth costs. Businesses generally don't like to spend more than they have to. It isn't just the html that suffers from bloat with this antiquated approach, either - Usually you will find that you end up with massive CSS files, with several classes doing the same thing and no inheritance being made use of, making for heaps of redundant code. Once again, this will increase bandwidth, and also make the files harder to navigate (Trust me... I've had to work through a 4,000 + line css file before!).

There are other business benefits most of us know about, too, such as better accessibility, SEO (although this is far from clear-cut), future-proofing, more reliable rendering, device independence.... The list goes on and on. I won't go into these things here, because this post is already rather too large, I feel. Needless to say that if you look, you can find any number of articles talking about these important issues - And they are important. I'm just saying that they probably won't be quite as important to the developers in question as the direct benefits to themselves.

This is an important issue... No matter what you think, and it happens more than you might expect, too. It's something that needs addressing soon, as well, as every day these developers continue down this road, they are costing people money. Designers and developers need to know that whilst web standards are very important, it is the spirit of these standards that is most important. There is no point in producing valid code if you are not addressing any of the issues you are supposed to be.

technorati tags:web, standards, xhtml, css, semantic, markup, compliance, problems, educating, benefits