Will HTML 5 validation be worth the candle?

tags:

html
html5

views:

3827

answers:

+9 Q:

Will HTML 5 validation be worth the candle?

It's widely considered that the best reason to validate ones HTML is to ensure that all browsers will treat it consistently and predictably.

The HTML 5 draft, however, contains two specifications in one. First an author spec, describing the elements and attributes that HTML authors should use, and their interrelationships. Validation of an HTML 5 page is based on this spec. The elements and attributes included are not directly drawn from HTML 4, but have needed to be justified from first principles, which means that some HTML 4 features, such as the summary attribute on <table>, longdesc on <img> and the profile attribute on <head>, do not currently appear in this draft. Such features are not considered deprecated, they are simply not included. (Their absence from the draft remains a matter of dispute, although their inclusion any time soon does not seem likely.)

Second, the draft defines a browser processing specification that seeks to define exactly how a browser's parser will treat any byte stream it's given, regardless of how well formed and valid the HTML. This means that when the browsers fully support HTML 5, it will be possible to predict how any browser will treat HTML for a much wider range of inputs than merely those that pass validation.

In particular, because HTML 5 is defined to be 100% backward compatible with today's web, all valid HTML 4, and all invalid but commonly used mark-up, will continue to be processed exactly the same as it is today, regardless of whether it is HTML 5 valid or not.

Therefore, at the very minimum, anyone using any feature from HTML 5, HTML 4, or any previous version of HTML, plus many proprietary extensions, can be confident that their HTML will get consistent and predictable treatment across all browsers.

Given this, does it make any sense to limit ones HTML 5 to that which will validate, and what practical benefit will we get from doing so?

+5 A:

Given this, does it make any sense to limit ones HTML 5 to that which will validate, and what practical benefit will we get from doing so?

Yes, of course. You forget that the future is not fixed. In particular, you implicitly assume that HTML 5 specs will never change, and never deprecate any features. This, of course, only cements the status quo. It is definitely desirable to remove support for some features in long term, to make it easier for new developments to take place (in particular if these might conflict each other).

There may be no immediate benefit in producing valid HTML 5 (except that it still makes validation and thus development easier). But there may be a long-range benefit if most websites improve in quality because it makes moving on beyond the current technologies and standards much easier.

Konrad Rudolph 2009-01-11 13:57:20

There's an implicit assumption that features won't be dropped, yes. Browsers only ever drop features though if a) they won't break the extant web - which is extremely rare; or b) the feature is shown to be a security vulnerability - which can apply to valid and invalid HTML alike.

Alohci 2009-01-11 15:41:09

This is very optimistic of your part. I fervently hope that this will not be the case because it's ultimately stupid and just means that future browser versions have to carry around more and more useless ballast.

Konrad Rudolph 2009-01-11 23:20:41

+3 A:

It's a good question.

The primary purpose of validation (for me at least) is to help me catch errors in my markup, and to give me a good base on which to build when testing pages in different browsers; if the markup is valid, and the page is borked in IE6, it's an IE6 issue.

The fact that browsers should all still behave in a predictable manner even if your markup includes technically invalid HTML5 such as a table summary, or an anchor accesskey, muddies the waters somewhat.

As a general rule of thumb, I'd always want my pages to validate, for the aforementioned reason. However, if (for example) an attribute was dropped from the HTML5 spec without an apparently suitable replacement being added, I might be inclined to continue using the deprecated or obsolete attribute, and accept the validation errors.

As ever, I think it's a case of knowing your craft.

If you know what you're doing, and have made a conscious decision to build a page that doesn't validate for sound reasons, it's not a problem. If you're just writing code that doesn't validate because you don't know any better, that's another matter entirely.

Stephen

2009-01-11 21:49:44

+1 A:

This is, indeed, one of my quibbles with HTML5. There's no point defining a subset of streams as 'valid', if a browser must handle all streams in the same way anyway. The eons spent on the WHATWG list debating fallback mechanisms is a massive waste of everyone's time, especially when XML should already have solved all the parsing issues.

It would have been an useful idea to produce a best-practices document on parsing legacy invalid documents but this has no part in a web standard, it's just another ingredient to further muddy the waters around HTML5, which can't decide whether it wants to be codifying existing behaviour (like HTML 3.2 did), redefining a cleaner platform (like HTML 3.0 tried) or adding new extensions piecemeal.

Anyhow, the question may be misplaced because there will never be a browser that "fully supports HTML5". There is just far, far too much of it: browser manufacturers could not implement absolutely everything down to the minutiae even if they wanted to, which at least Microsoft explicitly do not. Instead, obviously useful features will be cherry-picked from it by vendor and meet wider acceptance.

HTML5 is not a coherent HTML specification, it's Hixie's sprawling, unreadable and unfinished recipe for every random thing he thinks a web browser should do. It will fail. And W3's alternative approach, XHTML2, has already failed. There is no coherent future direction for web standards. We have dropped the ball.

bobince 2009-01-11 23:43:41

@bobince. The WHATWG is dominated by the browser manufacturers (other than MS). Hixie doesn't put stuff into the HTML5 draft if the browser manufacturers say they won't implement it. Indeed, that's probably his number one reason for not including stuff.

Alohci 2009-01-16 09:55:01

There is lots in HTML5 that has little-to-zero vendor buy-in. It's not as bad as it used to be - some of the early drafts read like little more than "the year's most popular suggestions from fools on alt.html" - but there's still a lot of spurious stuff...

bobince 2009-01-16 12:11:13

...luckily some of the worst features, such as data binding (which we should have learned from IE was a terrible idea) and repetition templates (which is the ugliest proposal I've eer seen in a putative standards document) have recently bit the dust.

bobince 2009-01-16 12:12:41

Sounds to me like a drafting process that's working well. HTML 5 raison d'etre is to document the web as it actually is, rather than how people would have liked it to have been. I don't see any possibility that unimplementable features will remain by the time it reaches W3C recommendation.

Alohci 2009-01-16 16:33:09

If HTML5 really was just that, catching up to reality, I'd be happy. Unfortunately, it's adding reams of features and requirements at the same time- none of them unimplementable, sure (neither was even repetition templates) but some of them ugly. This should have been done as a two-stage process.

bobince 2009-01-17 22:57:48

+3 A:

Validation has never really been about getting consistent results across browsers, even before HTML5 began. That's a myth propagated by those who don't understand what they're talking about, even if they think they do.

The real reason for validation is and always has been purely an issue of quality assurance. It's just a way of detecting errors, which . Even though results for any given error may be, or may soon become, consistent among browsers, it's still possible that the result itself is not as intended.

It's important for authors to be able to catch errors in their code because cleaner, error free markup is easier to work with and maintain, especially when working in a team environment. While most individual errors may end up being benign and not cause any major problems, there are some that can give unexpected results. e.g. Incorrectly, overlapping or unclosed elements can cause unexpected layout problems in some cases, and letting a validator tell you where the error is, helps in rectifying the problem. But if the results are filled with dozens of otherwise benign errors, it can make the detection and process more difficult than need be.

2009-01-12 12:07:38

+29 A:

First there’s the layer validity corresponding to “parse errors” in the in the HTML5 parsing algorithm. This layer is similar to XML well-formedness. The foremost reason to avoid having errors in your documents on this layer is that you may get a surprising parse tree. If your document is error-free on this layer, you get fewer suprises to debug when writing JS or CSS that works with the DOM.
As a special case of the above-mentioned layer, there’s the HTML5 doctype: <!DOCTYPE html>. The reason why one would want to comply here is getting the standards mode in the easiest way possible. It’s something you can memorize unlike the HTML 4.01 or XHTML 1.0 doctypes you need to look up and copy and paste each time. Of course, the reason why you’d want the standards mode is fewer surprises on the CSS layer.
The main reason to care about validation on the layer higher than the parsing algorithm is catching your typos so that you spend less time debugging why your page isn’t working like you are expecting.
The previous point does not explain why you should care about validation when a given element or attribute that you did not misspell is supported by browsers as a matter of legacy but the HTML5 spec still shuns it. Here’s why HTML5 has obsoleted syntax like this:
- HTML5 uses obsoletion to signal to authors that some features are a waste of their time. These include longdesc, summary and profile. (Note that people disagree on whether these are, indeed, waste of time, but as currently drafted, HTML5 makes them obsolete.) That is, if you have limited resources to improve accessibility, your limited resources are better spent on something other than longdesc and summary. If you have limited resources for semantic purity, your resources are better spent on something other than making sure you have the right incantation in profile.
- HTML5 obsoletes some presentational features that can be duplicated in CSS to guide authors to use CSS for their own good. This way, authors who don’t consider maintainability on their own are supposed to be guided to more maintainable code nonetheless. Personally, I’d prefer making more of the legacy presentational stuff conforming and leaving it to authors themselves to decide which way of doing things works for them.
- Some things are obsoleted for political reasons. The <font> element is obsoleted, because making it conforming would make anti-<font> standardistas think that the HTML5 people have gone crazy, which could lead to bad PR. <applet> is obsoleted mainly as a matter of principle of not giving special markup to one particular plug-in. The classid attribute on <object> is obsoleted, because it’s in practice ActiveX-specific.
- Some things are obsoleted on the basis of language design aesthetics. This includes the name attribute on <a> and the language attribute on <script>.

(I develop the Validator.nu HTML5 validator which is also the HTML5 validation engine used by the W3C validator.)

hsivonen 2009-01-15 13:35:22

Thank you Henri, for a very considered and detailed answer.

Alohci 2009-01-15 14:12:31

Great answer. I think parse errors are the main reason to validate. It's just fine to use some html5 in xhtml right now. Why not use an email field instead of a text field. It will just revert to a text field if the browser does not know this field type. This might make the page invalid but it gives a better result.

Keyo 2010-09-13 02:31:06

Nother thing here: OpenID adds its own headers which are not currently supported or allowed by HTML5 spec. I am trying to think on the alternatives - but just cannot compe up with anything...

Any ideas?

2009-11-11 02:50:58

For the record, Yadis is the right way to go anyway, not link tags. That has been the preferred way of doing things according to 'best practices' even with OpenID 1.0.

Nicholas Wilson 2010-05-06 21:14:28

ansaurus

tags:

views:

answers:

Will HTML 5 validation be worth the candle?

related questions