Is it worth the development time to output valid HTML?

Question

Developing websites are time-consuming. To improve productivity, I would code a prototype to show to our clients. I don't worry about making the prototype comform to the standard. Most of the time, our clients would approve the prototype and give an unreasonable deadline. I usually end up using the prototype in production (hey, the prototype works. No need to make my job harder.)

I could refactor the code to output valid HTML. But is it worth the effort to output valid HTML?

Answer 1

It is only worth the effort if it gives you a practical benefit. Sticking to standards might make it easier to build a website that works across most browsers. Then again, if you're happy with how a website displays on the browsers you care about (maybe one, maybe all), then going through hoops to make it pass validation is a waste of time.

Also, the difference in SEO between an all-valid html website and a mostly-valid html website is negligible.

So always look for the practical benefit, there are some in some situations, but don't do it just for the sake of it.

Answer 2

Yes. It's hard enough trying to deal with how different browsers will render valid HTML, never mind trying to predict what they'll do with invalid code. Same goes for search engines - enough problems in the HTML may lead to the site not being indexed properly or at all.

I guess the real answer is "it depends on what is invalid about the HTML". If the invalid parts relate to accessibility issues, you might even find your customer has legal problems if they use the site on a commercial basis.

Answer 3

Probably not if you have a non-complying site to begin with and are short on time.

However, and you won't believe me because I didn't believe others to begin with, but it is easier to make a site compliant from the start - it saves you headaches in terms of browser compatibility, CSS behaviour and even JavaScript behavior and it is typically less markup to maintain.

Site compliance (at least to Transitional) is pretty easy.

Answer 4

Producing compliant HTML is similar to ensuring that you have no warnings during a compilation - the warnings are there for a reason, you may not realise what that reason is, but ignore the warnings and, before you know where you are, there as so many, you can't spot the one that's relevant to the problem that you're trying to fix.

If you use Firefox to view your web pages, you'll get a helpful green tick or red cross in the bottom right hand corner, quickly showin you whether you've complied or not. Clicking on a red cross will show you all of the places where you goofed. Some of the warnings/errors may seem a bit pedantic, but fix them and you'll benefit in many ways.

1. Your page is much more likely to work with a wider range of browsers.
2. Accessibility compliance will be easier (You'll have 'alt' attributes on your images, for example)
3. If you choose XHTML as a standard, your markup will be more likely to be useful in an AJAX environment.

Failure to do this results in unpredictability.

One of the biggest problems with web browsers is that they have perpetuated bad habits (And still do, in some cases) by silently correcting certain markup problems, such as failure to close table cells and/or rows. This single fact has resulted in thousands of web pages that are not compliant but 'work', lulling their developers into a false sense of security.

When you consider how many things there are that can go wrong with a website, being lazy when it comes to compliance is just adding more problems to your workload.

EDIT: having read your original post again, I notice that you say you don't bother with compliance when working on a prototype, then you go on to say that you usually use the prototype in production - this means that it's not strictly a prototype, but a candidate. The normal situation in such circumstances is that once the customer accepts a candidate, no time is allocated for bug fixing or tidying up, thus strengthening the argument for making the markup compliant in the first place.

If you won't be given time later, do it now.

If you are given time later, then you had the time to do it anyway.

Answer 5

If you want your sight to be accessible to people with and without disabilities, as well as external systems, then yes, you should definitely make sure you output valid HTML.

It's easy to test your HTML with automatic validators.

I'll add to what Mike Edwards said about legal ramifications and remind you that you have a moral obligation too :)

Answer 6

Why not write the prototype in valid (X)HTML in the first place? I've never found that to be more of an effort than using invalid HTML. Producing valid XHTML should be a trivial task. (On the other hand, producing semantically meaningful XHTML might be more taxing.)

In short, I see no advantage whatsoever in using invalid HTML for prototypes.

Answer 7

I honestly dont know why it is extra effort to do standards based HTML. It's not as if it's hard and you should be doing it as a matter of professionalism.

If you paid someone to build you a house and he cut corners out of laziness, that you didnt notice at the time, but in 10 years cracks appeared in your walls, would you be happy?

Answer 8

Valid HTML just to be able to have a badge on your site - no.

Having "valid HTML" in the sense of "HTML that works on every major browser or browser engine" - yes.

Answer 9

Absolutely. Invalid code can cause all sorts of weird behaviors, and errors which don't obscure those that do when you get a validation report.

Case in point:

A yellow background was spilling out of a list of messages and over the heading for the next list of messages - but only in Internet Explorer.

Why? The background was applied to a list item, but the person who wrote the page had written it as a single list with a heading in the middle. Headings are not allowed between list items and different browsers attempted to recover from it in different ways. Internet Explorer ended the list item (with the background colour) when it saw the start of the following item (after the heading), while other browsers ended it when they saw the end tag for the first list item.

It was the only validity error on the page, so it took only a couple of minutes to track down the problem and fix it.

Answer 10

Because, if you stick to standards, your work will be compatible in the future. User Agents will strive for standard compliance and their quirks non-compliance mode will always be subject to change. This is the way is supposed to be.

Unless you're into that whole IE8 broken standards perpetuation thing that they want to enable by default. -- that's another argument.
Webkit, Gecko, Presto? (is that opera's engine?), and the others will always become more compliant with every release.

Unless your html work is in a IE embedded browser control, then there's really no reason to output valid html as long as it renders.

Answer 11

In my opinion the key criterion is "fit for purpose" - If your clients want something for a small/internal market (and don't care if that alienates potential customers who have disabilities or use less-common browsers) then that's their choice.

At the same time I think it's our (as developers) responsibility to make sure they know the implications of their decisions - Some organisations will be bound by legislative requirements that websites be useable by screen readers, which typically means standards-compliant HTML.

Answer 12

i believe making valid html outputs wont hurt your development time that much if you've trained yourself to code valid html from the start.

for one, its not that hard to know which tags are not allowed within an element
and the required attributes in a tag are sometimes the ones you'd really need anyway - i believe these are the main errors that makes your html invalid, so why not just learn them as early as now if you plan to stay on the web for long?
plus outputting valid html can help boost your sites ranking

Answer 13

There are two rules for writing websites:

1. The site must work for your users.
2. The site must work for your users.

To meet the first rule, you have to code such that your site renders correctly when using Internet Explorer. Unless you have the freedom to alter your site design to use only those features that IE renders correctly, this means writing invalid HTML.

To meet the second rule, you have to code such that your site renders correctly when using screen-readers and braille screens. Although some newer screen readers can work with IE-targeted sites, in general this means writing valid HTML.

If you're working on a small project, or you're part of a large team, you can code a site that outputs IE-targeted HTML for IE, and valid HTML otherwise. But if you're taking on a medium-to-large project on your own, you have to decide which rule you're going to follow and which one you're going to ignore.

UPDATE:

This is getting voted down by users who think you can always get away with valid HTML in IE. That may be true if you have the flexibility to change your design to get around IE's shortcomings, but if a client has given you a design and you have to get it working, you may have to resort to invalid HTML. It's sad, but it's true, whatever they might think.