tags:

views:

758

answers:

7
+11  Q: 

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 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?

+2  A: 

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)

John Weldon  2009-06-19 06:00:32
+1  A: 

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 111[1], 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.

eed3si9n  2009-06-19 06:04:18
This is a good principle too. (but how are we ever going to improve the state of the technology if everyone is conservative in what they do?) I would counter though that this principle applies specifically to core architecture pieces that have to be very stable... just like my second point :) +1 for a good answer though.
John Weldon  2009-06-19 06:06:30
@John Weldon, I think historically there were variance among TCP implementations from different vendors. So being conservative in this context refers to being conservative in following the spec. I'd think this principle applies to anything that requires cross-platform interoperability, including html with many browsers.
eed3si9n  2009-06-19 06:17:57
Good point. I agree on one hand, but on the other hand that seems to be a bit limiting for *every* situation. Maybe yes on a corporate site, or on a government web page, but what about other less rigorous environments? Good discussion :)
John Weldon  2009-06-19 06:27:49
+2  A: 

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.

Jon  2009-06-19 06:11:45
+1 for server side validation!
Treb  2009-06-19 06:28:20
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
TM  2009-06-19 12:40:09
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.
Jon  2009-06-19 13:03:38
+9  A: 

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.
Thomas Broyer  2009-06-19 10:33:15
“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.
Paul D. Waite  2010-07-14 15:21:54
+1  A: 

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.

hsivonen  2009-06-22 12:28:02
+1  A: 

I will not implement new features from HTML until at least they have support from all major browsers.

Clients don't care if your page is valid, they care much more if it works cross browser. Even if we fight to implement the latest standards there will be still clients and companies that will never shed their IE6, and IE6 will be on their browser requirements list for still a while.

The new form types are welcomed, nevertheless the forms have to be checked in the server side.

Passing to HTML5 existing documents will require a lot of effort and adaptation and in my estimate will not happen overnight. Expect at least a 3 years until it will hit the mainstream.

Elzo Valugi  2009-07-09 18:18:16
A: 

I would use HTML 5 just for fun and learning, but definitively I wouldn't touch any of my production code (existing code) with this new standard, at least by now and until I have a valid reason to support this move.

Abel Morelos  2009-07-09 18:24:46

related questions

How can I modify HTML Canvas colors using an interval loop?
How does the live, real-time typing work in Google Wave?
Capture HTML Canvas as gif/jpg/png/pdf?
Javascript Canvas Serialization/Deserialization?
iPhone WebApp cache
Limit text to the width of sibling image / auto width in CSS
HTML Anchors with 'name' or 'id'?
How do I fix shocking/lagging movement in this ajax based multiplayer example?
Why are (X)HTML 5 and XHTML 2 separate standards?
HTML 5 Reference Implementations
Will HTML 5 validation be worth the candle?
Is there an alternative of ajax that does not require polling without sever side modifications?
[JAVASCRIPT/HTML5] Howto equal Microsoft.Matrix filter to canvas rotate?
Canvas rotate from bottom center image angle?
Howto avoid image cutoff with <canvas> rotate ?
XHTML - Is writing self closing tags for elements not traditionally empty bad practise?
Does my page have to have the HTML5 doctype to access sessionStorage
Can HTML5 sessionStorage be written to disk?
Does Internet Explorer 8 support HTML 5?
HTML 5 versus XHTML 1.0 Transitional?
Is it time to start using HTML5?
Where can I find some good information about how the new canvas HTML element works?
Which browser has the best support for HTML 5 currently?
What's the key difference between HTML 4 and HTML 5?
Any reason not to start using the HTML 5 doctype?