8

HTML5 defines a standard algorithm for rendering web pages, and this algorithm specifies how error handling should be performed. All in all, every single browser should render invalid markup the same way, or should fail the same way for tags they can't handle.

Right now I can still see validation as a means to ensure markup works hypothetically the same on legacy browsers. Excluding those (because hopefully they won't be around forever), since any kind of markup should have a defined behavior no matter how horrible it looks, does "valid HTML" still have any meaning? It seems to me that an input is valid if it has a defined output, and in this case it means that any HTML5 is valid. Is it still useful to validate markup considering that it won't impact compatibility?

As linepogl rephrased it in a comment, now that invalid HTML is standardized, has it become valid?

zneak
  • 134,922
  • 42
  • 253
  • 328
  • Just because HTML5 defines how error handling *should* be performed, that doesn't mean all browsers will manage to *get it right* in all cases. At least not for a while. – thirtydot Mar 10 '11 at 19:57
  • 5
    Rephrase: now that invalid html is standardized, has it become valid? – linepogl Mar 10 '11 at 20:01
  • I asked a similar question a while back here: http://stackoverflow.com/questions/432933/will-html-5-validation-be-worth-the-candle . Henri Sivonen provides a very strong answer there. – Alohci Mar 11 '11 at 00:36

4 Answers4

2

I imagine validators will remain a useful tool for HTML in the same way that lint and its descendants remain useful tools for general programming languages. That is, even if the compiler (the browser) behaves in a predictable way according to the language standard (which is overly optimistic anyway), it's still useful to perform a more thorough check for unsavoury constructs in your code.

John Bartholomew
  • 6,428
  • 1
  • 30
  • 39
  • Still, there's a difference between programming languages and markup languages. If you do something stupid in C, it's gonna crash, it might compromise the host computer, or do serious damage to the computer in general. You can't do any of the above with a markup language alone. Therefore, error recovery algorithms can operate just as they please in – zneak Mar 11 '11 at 00:08
1

To put it in terms of a car analogy:

In the UK we generally know the consequences of our actions if we break the speed limit while driving. We'll get a fine and 3 endorsement points on our licence. But just because we know the consequences doesn't mean that it's any less of an offence.

Same applies with HTML. Error handling behaviour has been standardised because it's such a common occurance, but that doesn't make using illegal syntax valid. Legal syntax is more efficient for browsers to render, and infinitely easier to maintain, so although the outcome of invalid markup is predictable, it's much better for everyone concerned if we stick to the rules.

... Stay in school kids! </preach>

Karl Nicoll
  • 16,090
  • 3
  • 51
  • 65
0

It is easier to get unintended behavior in invalid HTML, so staying as close as possible to valid HTML will make it easier to understand.

Also most developer tools will expect more-or-less valid HTML, because handling edge cases is hard and takes much developer time. You'll have less problems when your pages follows standards.

Browsers are forced to implement invalid HTML handling because of legacy. But developer tools not necessarily, as these tools usually help you create new pages.

liori
  • 40,917
  • 13
  • 78
  • 105
0

It may be an accessibility requirement to provide valid HTML.

Invalid HTML can be problematic to maintain. Amendments to a functionally tested yet invalid document may exhibit unexpected behaviour and be difficult to understand until the original mistake is spotted.

I don't think the HTML5 specification can cover every possible invalid scenario to guarantee robust cross-browser compatibility.

Lee Kowalkowski
  • 11,591
  • 3
  • 40
  • 46