Quality Assurance of an HTML

photo credit: suchitraprints

How do you put value on an pure HTML design? How can you tell if the HTML is good or if it sucks badly?

Those are the questions I was asking myself for some time now. In one of my current projects I do QA of all designs that are thrown at us. So basically I decide whether the code is acceptable, whether it is production grade or whether it should be rewritten.

So how do I can tell that? Well, there are couple things you have to keep an eye on. Let me go into more details and list what decides if the code will sink or swim.

• Valid HTML - this is a nobrainer: it is an equivalent of a code that compiles. If you don’t have a valid HTML this is your priority.
• Unobtrusive JavaScript - all the scripts should be placed in a separate file(s) and wrote in a clean light manner.
• Proper style handling - this one is quite vast subject. Styles should be also in separate file(s), styles for alternative viewing devices should be provided (mobile, print).
• Reduced additional files - although both CSS and javascript should be in separate files, you shouldn’t create too much of those. Every file is additional request to the server thus loading times get longer. Also, there is a lovely IE6 bug that doesn’t allow you more than 33 CSS files (I think it is 33)
• Semantic Markup - this is also a trait of a quality HMTL. Proper class naming, using right elements to do the job, all this is required  for your code to shine.
• Organized code - this goes to all the javascript coders out there: if you write a code be sure to comment it. Make it readable. Use variable names that mean something. This is very basic stuff but it needs to be said. You need to do this. Otherwise in some time your code won’t be readable to any one (yes, even to you)
• Loading Time - this is also pretty basic stuff but since not everyone has a 6MB Internet connection, in order to view your site users need to be able to download it. Quicker it does so, better user experience you create.
• Cross browser issues - this is fairly basic but has to be said also: If you create a project in HTML, be sure to check it in various browsers. Just to be sure. What browsers? IE6, IE7, Firefox2, Firefox3, Safari, Opera. This should suffice.

Wow, that is a handful. This should be more than enough to get you going. There is only one thing missing from the list, one thing that lets you decide whether the code is OK - it is your own expertise and experience. Bottom line: you need to know your stuff before you will judge someone else’s.

Hopefully this was helpful. But what about you? How do you tell if the HTML sucks or not? How can you grade it as production ready code? Care to share?