With the greatest pleasure let me present you this article written by the very first guest blogger at Inspiration Bit:
Andrew Rickmann.

Wow, well where to start. This is my first guest spot on anyone else’s blog and it is a little daunting to try and write for someone else’s audience, especially as I think Vivien writes so engagingly. So here goes.

The suggestions for what I should write about were quite original and I must admit to having been slightly stumped by Simonne’s suggestion, “Why are animations so infrequent in blog design?” It has certainly made me think but I’m not sure I have answer, or even a good guess, so I will leave that for you all to ponder some more in your own time.

Vivien also had a good idea, that I write about how I come up with and execute ideas for site design. I may well cover this on my own blog in the future but better designers than me have covered it before and I’m not sure how much more I can add.

What I am going to write about are Ronald’s suggestions which I thought were very original and for some of them something I needed to go away and think about.

When to break the rules regarding standards?

The quick answer to this is simple: Whenever you need to. Following the rules is important but it isn’t the end of the world if you don’t, honestly. It is so much more important to follow the principles than the rules.

Andy Rutledge called it ‘Web Quality’, or ‘web craft’, I have written about it as ‘Treating Users Fairly’ and what it all boils down to is this:

What matters most is the quality of the product you produce. The people that use your website, whether they are paying for it or not, are your customers and they deserve to be treated as such. Web standards are one way to measure quality but that is all they are, so if you need to break those rules in order to provide a quality product, then do it.

Of course, whether you actually need to break the rules or not is another matter and the answer is almost certainly that you don’t, but if you do need to then you don’t need to feel too guilty about it.

How do I convince back-end developers to use standards?

This is a question that I have never come across before so I needed to give it some thought.

Most of the reasons for using standards apply to anyone that is manipulating the content that the user sees — perhaps this is why I haven’t seen it specifically raised before — but they can take on added meaning when you are dealing with a project that is split on a back-end front-end basis.

Assuming that professionalism, accessibility, and “it’s just the right way to do it,” haven’t made a dent in the developer’s armour what arguments do you use?

Using standards, not just web standards but any documented standards, in all aspects of a project makes sense. Knowing what you have to do, how you have to do it, what it needs to fit with, and finally that others are also working to the same standards can have significant cost, productivity, and team morale gains. Not to mention development time and customer satisfaction.

A developer who is happy to forgo any of those things is probably not someone you want to be working with in the first place, but if you have no choice but to try and bring them round what do you do?

The first, and simplest argument to use standards is to make life easier. When things don’t work as expected, and this usually happens at least once, validating the site is the quickest and easiest way to double check whether anything is missing. Given these three options which would you choose?

  1. Wade through a validation report with hundreds of unencoded ampersands, illegal attribute values, and missing closing tags;
  2. Hunt through the generated markup one tag at a time to make sure all the tags close properly and don’t have values that will cause your problems;
  3. Fix the two minor errors the validator has flagged up then proceed on the basis that the HTML is not the cause of the problem.

The answer seems obvious to me. When you use and get to know the standards most of the reasons for a page not validating simply stop occurring.

If that doesn’t work then you need to try appealing to the programmer in them.

Every programmer knows the pain of trying to figure out un-commented code and every book on programming ever written will suggest commenting as good practice. Standards are simply a short cut to commenting the code generation.

Programmatically generating HTML can be a pain at the best of times but if you have to come back in six months, a year, or even two years time to change something it will help to know what is going to work, and what isn’t. If a standard was used first time round then the precise rules regarding what you can or can’t do and the syntax you need to use are clearly documented already. This is the ideal situation and not particularly difficult to put in place.

The other side of standards, CSS, means that instead of having to create tables to keep the forms and labels in line, font tags to style headers and labels, and Javascript to handle focus you can simply add form elements and labels to a page and trust that they will work, be styled, and laid out, as they are supposed to be.

As a back-end developer you can leave the styling to the designer and just put the content on the page.

When it all needs re-branding two years down the line dealing with twenty elements instead of fifty is clearly going to be easier. In some cases the programmer might not even need to be involved at all.

Given those choices it is hard to see why the conflict even exists, but if you are still getting no joy then appealing to self interest may do the job.

It may not be as flashy as the graphic side but back-end developers are as vain and as proud of their work as anyone. The only part of a programmers work that will be publicly exposed is the HTML, would you really want the only bit of your work that you can be publicly judged on to be non-standard? How would you feel if the rest of the site was standards compliant and your bit stood out as the only non-standards based part of the site?

There is also that matter of future employment. Using standards is never going to hurt you when looking for a new post; failing to use them might.

If all that fails and there is no chance of the developer changing their ways then perhaps you need to consider the way the work is divided up.

With forms in particular a good answer may be to give the form to a designer. Designing a good form is an art in itself and possibly one of the hardest design jobs on a website so not only will the user thank you the back-end developer may be more than happy not to touch the design of the form at all. All the developer then needs to do is provide the data to insert into the value attributes of the form fields and tell you what name he needs applied to each field so the back end script can handle the output. That way everyone is happy.

I hope you all have found this useful. If not then you will be pleased to know that it’s over and things can return to normal again. I’m grateful to Vivien for giving me the opportunity to write here and to those who put forward topic suggestions. If you have any questions, comments, or criticism then I will answer them in the comments.

Recent Bits
Related Bits
Web Design Dissected Into 8 Bits
Who Are The Most Creative People?
Two More Contest Winners
Another Handy WordPress plugin
First Rule Of Writing On Inspiration Bit
8 Constructive Bits On Running Blog Contests
Famous Logos Converted to Web 2.0
Guest Bit
Comment Bits

5 Insightful Bits in response to “Web Standards – Breaking Or Enforcing The Rules?”

  1. Andrew,

    Thanks so much for taking the time to answer some questions the readers had. The answer you provided for back-end programmers was superb and something I’m glad you took the opportunity to answer.

    I now have ammunition for my standards so-to-speak. :)

  2. Thanks Ronald, I’m glad you liked it. It was very much helped by having some interesting questions.

  3. ibit

    I have italicized in this post two of my most favourite explanations about Web Standards by Andrew. This is a very well thought out article. Thanks again, for your contribution on my blog.

  4. “Every programmer knows the pain of trying to figure out un-commented code and every book on programming ever written will suggest commenting as good practice. Standards are simply a short cut to commenting the code generation.”


    Your article is great. As a beginner in this programming stuff, I’m impressed by people who follow standards, by people who comment their code, making it very easy to read (at least by me, but I’m sure that even experienced programmers have troubles in reading un-commented code).

    Briefly, at least one of the Inspiration Bit readers would be glad to see more of your posts featured here every once in a while.

  5. Thanks Simonne, I appreciate it.

Selected Bits





Hi, I'm Vivien. Thanks for visiting my Inspiration Bit. I often find myself scouring the internet looking for either answers to many questions I have or websites that inspire me, sites that I can learn from. On what topics you might ask — any topics that interest me, anything from web design to typography and art, from blogging to entrepreneurship, from programming to open source.
read more…
When I'm not blogging, I design web sites, teach, play with my daughter and try to balance family, work, friends and a somewhat active social life on