HTML 5 - Early Adoption Where Possible - Good or Bad?

Asked 19/6, 2009 at 5:55 Answered 9/7, 2009 at 18:24

Solved html cross-browser w3c-validation

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 made me curious about using features from a future spec in general.

HTML 5 offers a lot of nice improvements, many of which can be used without causing problems in current browsers.

Some examples:

// new, simple HTML5 doctype (puts browsers in standards mode)
<!doctype HTML>

// new input types,  for easy, generic client side validation
<input type="email" name="emailAddress"/>
<input type="number" name="userid"/>
<input type="date" name="dateOfBirth"/>

// new "required" attribute indicates that a field is required
<input type="text" name="userName" required="true"/>

// new 'data-' prefixed attributes
// for easy insertion of js-accessible metadata in dynamic pages
<div data-price="33.23"> 
    <!-- -->
</div>
<button data-item-id="93024">Add Item</button>

Many of these new features are designed to make it possible for browsers to automatically validate forms, as well as give them better inputs (for example a date picker). Some are just convenient and seem like a good way to get ready for the future.

They currently don't break anything (as far as I can tell) in current browsers and they allow for clean, generic clientside code.

However, even though they are all valid in HTML 5, they are NOT valid for HTML 4, and HTML 5 is still a draft at this point.

Is it a good idea to go ahead and use these features early?

Are there browser implementation issues with them that I haven't realized?

Should we be developing web pages now that make use of HTML 5 draft features?

Tomblin answered 19/6, 2009 at 5:55 Comment(7)

Depends on what browsers you need to support. If you need to make site work with IE, I'd say it's probably too soon. – Breathtaking 19/6, 2009 at 5:58

@Breathtaking as far as I can tell, none of these features break anything in IE, or any other browsers (although I might be missing something). – Tomblin 19/6, 2009 at 5:58

@TM Oh, you underestimate IEs ability to do really bizarre things in strange conditions. – Breathtaking 19/6, 2009 at 6:5

Some features of HTML5 break things in all browsers. – Inwards 19/6, 2009 at 10:53

@Ionut I am talking about the ones I mentioned, not ALL features. Obviously the new tags won't work. – Tomblin 19/6, 2009 at 12:18

TM, actually some of the new tags work almost perfect in FF, Opera and Chrome. By "work" I mean they can be styled via CSS. In IE however there's a little JavaScript hack that you have to apply. View source on this page: apple.com/safari – Inwards 19/6, 2009 at 16:30

Keep an eye at code.google.com/chrome/chromeframe :) – Family 24/9, 2009 at 15:29

There are several things to consider:

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)
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
As for the forms enhancements, you can use Weston Ruter's webforms2 JS library to bring it to non-aware browsers
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.

Burden answered 19/6, 2009 at 10:33 Comment(1)

“validation doesn't mean that much, because an HTML page can very well be valid but badly authored” — right, but just for your own development purposes, validation is an easy, automatic way to spot some errors. – Shogunate 14/7, 2010 at 15:21

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)

Inkstand answered 19/6, 2009 at 6:0 Comment(0)

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.

Patchouli answered 19/6, 2009 at 6:11 Comment(2)

Of course, I'd never go without serverside validation. Having client side validation in addition (never in replacement!) can make it a lot more user friendly however – Tomblin 19/6, 2009 at 12:40

Nothing quite like submitting an unchecked page and then getting it back either marked up in red or emptied with obscure validition errors, I must admit. – Patchouli 19/6, 2009 at 13:3

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.

Recommended topics

Hot tags