Html 5 - Early Adoption Where Possible - Good Or Bad?

This question was inspired a bit by this question, in which the most upvoted answer recommended using a feature from HTML 5. It certainly seemed to be a good method to me, but it

Solution 1:

There are several things to consider:

1. First, validation doesn't mean that much, because an HTML page can very well be valid but badly authored, inaccessible, etc. See Say no to "Valid HTML" icons and Sending XHTML as text/html Considered Harmful (in reference to the hobo-web tests mentioned in another response)
2. Given this, I'd highly recommend using the new DOCTYPE: the only reason for having it in HTML5 is that it's the smallest thing that triggers standards mode in browsers, so if you want standards mode, go with it; you have little to no reason to use another, verbose, error-prone DOCTYPE
3. As for the forms enhancements, you can use Weston Ruter's webforms2 JS library to bring it to non-aware browsers
4. and finally, about the data-* attributes, it a) works in all browsers (as long as you use getAttribute()), b) is still better than abusing the title or class attributes and c) won't bother you with validation as we said earlier that validation isn't that important (of course it is, but it doesn't matter that your page is invalid if the validity errors are willful; and you can already use HTML5 validation in the W3C validator, so...); so there's no real reason not to use them either.

Solution 2:

Good question!

In short: it depends on your context, and risk tolerance :)

Slightly longer:

• I think it's always good to push the envelope on early adoption of technology. It gives you an advantage over late-comers in the commercial world, and also gives you much more leverage in influencing the technology as it emerges.

• If you don't want to have to re-write code, or update your source, then early adoption may not be for you. It's perfectly respectable to want to write solid, stable code that never has to change, but it's entirely up to you (and your business context)

Solution 3:

If your page relies heavily on search engine placement, it may be worth considering that some engines give priority to validating HTML (Source: http://www.hobo-web.co.uk/seo-blog/index.php/official-google-prefers-valid-html-css/).

Also, it is worth considering that relying on the new date input elements (such as those in Opera, possibly others) allows for more convenience on the part of the developer, it typically precludes including more complex Javascript controls which would better server older browsers (typically falling back to a simple text input field).

Of course and as always, don't rely on browser side checks and validate all input server side.

Solution 4:

Please don’t use the new features before you can test them in at least one browser. For example, if you use the now form features, be sure to test in Opera. Otherwise, you’ll likely do more harm than good by contributing to a poisoned legacy out there.

When a feature is already implemented in browsers and you are testing with those browsers, sure, please use the new features.

See also an older answer.

Solution 5:

See Robustness principle:

In RFC 761 (Transmission Control Protocol, 1980) American computer scientist Jon Postel summarized earlier communications of desired interoperability criteria for the Internet Protocol (cf. IEN 1111, RFC 760) as follows:

TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

So, imho, no.