selling html pt2

Earlier this week I talked about trying to sell html based on its actual merits, and more importantly, why this isn't working in real life. In this second part I'll try to list more practical arguments. None of them fool-proof, but definitely carrying more weight when used in discussions about the importance of quality html. Extra input is very much appreciated and can be listed in the comments section.

One little word of advise before I start. Do take care in using the arguments given below. There are always counter-arguments available and some might actually be hurtful to either your partners or clients. These are not arguments that can silence whoever you throw them at. But as a whole they form a well-developed arsenal of knowledge that will at least grant you some credibility in the discussion.

seo

Ah yes, the buzzword that made money flow like water for a good couple of years. Even us front-end developers loved the SEO hype, since we could tag along and demand proper html implementations as this improved rankings. Which is true, but only to some extent.

"Sadly", people grew wiser and found out that there are only a few html tags that will actually make a difference. True enough, good structure will help your ranking a little, but there's little difference between a clean div with one single class and four nested divs littered with CMS-specific classes. So even though you might have your paragraphs and heading tags, you still have no defense against the messy tangles of automatically generated CMS code.

SEO is still a valid argument in the battle for good html. Certainly with html5 being almost ready for implementation. html5 is a much richer language, which means you'll have more power to your disposal for marking up content and indirectly improving search-engine rankings. But for now, the scope of the SEO argument is limited to headings and paragraphs mostly. If the html code is truly horrible though, this is a good place to start.

future-proof, flexible, cost-effective in the long run, ...

I tried this one a couple of times before. It does work for big projects, sometimes. But when deadlines are nearing, money is running out and clients are breathing down your neck these arguments hold little weight. Suddenly html becomes a "phase 2" concern and all that matters is getting the site to work and look right in all (or most) browsers.

It's a shame, because well-planned html makes future updates so much easier. Especially when new parts are added to the site or complete redesigns are issued. It's the core of a website, so if corners are cut there, they will show themselves at later dates. These arguments will hold some weight when explained in the beginning of the process, though will find little support for improving any current implementation.

Also note that you are practically taking away work from those implementing the site. A complete redesign usually means work (and income) for the implementors too as there are usually quite some code changes. By implementing solid, future-proof html this work is brought back to a minimum. Good for your clients, but make sure you don't offend your technical partners in the meantime.

stylability

This is actually one of the most solid arguments out there. Badly implemented html makes it way more difficult to style a website. In several ways. For one, finding "your" class in a string of 6 or 7 badly-edited cms classes is not as easy as simply picking out a single value in the class attribute. Secondly, styling on cms-generated classes is usually quite dangerous as they reflect the inner kitchen of the cms and hold little to none semantic or structural relevance when it comes to the actual document. Who knows where else they might end up.

Missing classes or missing structural html elements will result is unstable css, creating problems cross-browser. And switching to default classes might (and in our case will) hurt predictability of the code. For example, at my current job we hardly need the html code to start styling the main navigation as structure and class names are standardized.

There's also a timing issue. After creating the html templates you could start working on the css. But only if the implementation of the html is (as) perfect (as possible). If not, most of the css work will be useless anyway. Waiting for the implementation on the other hand does add some extra time to development as css work and implementation can't happen at the same time.

The bottom line. Bad html will jeopardize the quality of the css, will jeopardize the quality of future updates, and even more importantly, might hurt the wallet of your client as this extra work needs to be paid. And best of all, there are very little counter-arguments against this argument.

analogies

Analogies! Always helpful when trying to explain a somewhat vague concept like html. And always someone who tries his best to find the differences with the analogy you are making. I've been looking for a good one to explain the importance of html, but found it rather hard. One analogy that's often cited is between building a website and a house, but html doesn't really fit in as front-end development is a step between architectural work and the actual physical work not (often) present in construction.

The best analogy I came up with is the difference between a golden object and a gold-plated object. This concept is understood by everyone and illustrates the difference between a web page constructed using correct html and one using crappy html. Even though the difference between both objects is not immediately visible from the outside, there is a definite difference in quality (and worth) between the two.

Gold-plated objects only have a golden shine. The top layer (css in the analogy) hides what's underneath, but over time the golden object will prove to be way more robust and thus valuable. It's also stronger and tougher, with a higher resistance to external influences. But there's more than simply the nature of the core material, there's also the texture. If the texture of the core material is rough, you need more coating material to smooth out all the irregularities. And the more coating you need, the more expensive the object will become.

Like all analogies not perfect, but still clear and understandable, even to non-tech people.

conclusion

And that's about all I have. If you can think of extra arguments that might help in convincing clients and technical partners they should invest time and money in good html, do list them below. The combination of all arguments above do hold some weight, but still don't ensure victory.