tags:

views:

5947

answers:

11

Is it time to start using HTML5? Someone has to start sometime but is now the time?

Is it possible to to use the new HTML5 tags and code in such a way as to degrade gracefully?

+8  A: 

Comparison of Layout Engines (HTML 5)

So, No.

While this is a valid point of view, there are subsets of HTML5 that are perfectly usable right now. (Read: Supported by current browsers.) So, in many cases, Yes.
zoul
There's a difference between layout engine and styling presentational elements. You can most certainly use any html5 element and style to your liking. The majority of browsers support styling "unknown" elements and there's the HTML5shiv for < IE9 (http://code.google.com/p/html5shiv/) HTML5 is also backwards compatible since the doctype forces standards mode so really there's **no** reason to not use it. This is not a good answer.
Typeoneerror
A: 

Firefox 3.1 should support the <video> tag, and the next version of Safari will support that and the <audio> tag - but there will be no way to degrade gracefully (Edit: I've seen some Javascript libraries that allow for this). As always, we are bound to the browser support when designing, and it may still take a while (not to mention user upgrade paths...).

Raithlin
+7  A: 

See also: http://stackoverflow.com/questions/5629/any-reason-not-to-start-using-the-html-5-doctype

Various features already work, e.g. <canvas>, but you'll need to add some JavaScript library for Internet Explorer. There are also libraries around the web that implement Web Forms 2.0, the forms chapter of HTML5. APIs such as postMessage will soon be in every browser (including Internet Explorer) and the same goes for localStorage/sessionStorage.

Disclaimer: I'm a member of the WHATWG and the W3C HTML WG that jointly develop HTML5.

Anne
+2  A: 

HTML5 is a collection of features with different status:

  • Some features are already widely supported, like the window object, embed-element, editing module (desingMode/contentEditable) and so on. The HTML5 spec just specifies what is already de-facto standards supported by all major browsers. You can use these features safely.

  • some parts of the spec like parsing and error handling and so on are only relevant for browser implementors, you can ignore those (hopefully you are not relying on error handling behavior!).

  • the semantics of some elements like i and b have been changed. You can probably use this safely, because it wont make any difference for the common user agents.

  • some features like canvas, video-element and so on are not yet widely supported. You cannot use those yet (if ever!).

JacquesB
+25  A: 

Yes and no. There are HTML5 features that you can use today, but it would be wrong to say than you can use all of HTML5 today.

When a given feature has two interoperable implementations among Firefox, Opera, IE8 and WebKit, it is OK to use that feature. If a feature hasn’t been implemented yet, you probably shouldn’t try to use it speculatively.

Examples: <canvas> is ok. <article> is not ok. (<article> is expected to be sensitive to client-side navigation tools—don’t let it become a new <div>.)

The WHATWG copy of the spec has feature maturity annotations in the sidebar.

Two things to be extra careful about:

  1. Don’t lock out future browsers. If you opt to emulate a given feature with a JS library in browsers that don’t support the feature, please sniff the existence of the feature and not browser identity. Be sure that you test in a browser that already has the feature natively that the library properly shuts itself off there.

  2. Don’t lock out current browsers that aren’t your development browser. True story of what not to do: I added a pattern attribute to the Document input field of Validator.nu to check on the client side that the URL the user entered is an http or https URL. The pattern attribute is supported in Opera. If you do this kind of thing, you should continue to test your site in a browser whose advanced features you are using. I forgot. I added support data URLs, but that day I only tested with Firefox and Safari neither of which supports pattern, yet. The result was that Opera users were locked out of the new data URL feature (until the bug was reported to me and I fixed the regular expression to allow data URLs).

And yes, HTML5 features are generally designed to be authorable in such a way that they degrade gracefully in legacy browsers. For example, new form controls degrade to input type=text and <video> allows you to fall back on <object> or <embed> in browsers that don’t support <video>.

hsivonen
A: 

<video> implementations currently in browser builds don't do hardware acceleration. The videolan plugin playing a theora video totally wipes the floor with <video> performance-wise. This means that video is useless unless you have a fast computer. No getting by with older computers like you can with flash.

If youtube for example was to start using only the video element now, they'd lose a lot of visitors. What this means is that for now, the video element is just something nifty to play with and far from a solution. Hopefully, by the time HTML5 is finished, the situation will be better.

What would really help is if the videolan plugin supported an HTML5-compatible media api. Then, either through JS replacing the video element with an object element or through a browser setting, you could make <video> work with the plugin to get better performance. EVen now though, you could wrap the videolan plugin's current api to make it somewhat HTML5-compatible. (The videolan plugin needs to be more stable though too.)

Shadow2531
<video> should participate in CSS/SVG compositing in a more versatile way than windowed plug-ins on Windows and Gtk+.
hsivonen
+11  A: 
Just read an article on the HTML5 plans today. What really shocked me is the timescale. 2022 for completion!? I'll probably be retired by then!

I don't have enough reputation yet to vote you down, but this is a commonly made mistake. It probably would have better for Hixie to just never have mentioned it.

The 2022 date is the expected date to have two browsers consistently, interoperably implement 100% of HTML5. This is an extremely strict criteria. HTML4 hasn't yet reached this, and it's been out for a decade.

HTML5 is expected to ship as a complete spec at the end of this year.

Xanthir
may you let me see the article you just read? is there any url?
Morteza M.
That was a quote from someone else's comment. I didn't read any article, I was responding to someone else who did. However, just search for "html5 2022" and you'll find plenty about it.
Xanthir
A: 

Looks like the new Chrome version will have a lot of HTML5 support... so I think we are getting much closer. Though it will probably remain like other recent improvements, where backwards compatibility for your site will still be needed for a long time to come and may negate and real improvement that HTML5 can give us.

IPX Ares
Yeah, chrome is awesome.
Pierreten
Firefox is better!! chrome is good for javascript performance not html 5 support.
Morteza M.
A: 

According to the WHATWG the HTML5 specification will be W3C Candidate Recommendation during 2012. I think is so much time, but is a sure date. I was using text-shadow when was part of CSS 2.1 working draft, and suddenly it was removed just like the Opera support. So I think that for production is better wait.

Tae
A: 

http://caniuse.com has comprehensive reports on what's supported vs not supported. Seems like if your target audience is using a webkit browser (Chrome/Safari) you're in reasonable shape depending on what you want to use.

Most of the semantic tags like will degrade fine in older browsers but things like SVG graphics, tags, will not.

Same thing with the newer features like offline storage, cross-tab communication or workers will be tough to implement any kind of degrade strategy for.

Hope that helps, -fs

Francis Shanahan
A: 

You could use some HTML5 features such as extra optional features to your application, but not the actual core. Most people are still using browsers that don't render HTML 5 either completely or in high portions.

There could be some exceptions however. For example, if you're building an intranet application that requires a specific browser that is pre-HTML5 compatible, you can adopt the supported HTML 5 features if you can force all client machines to run the browser in question.

I'd avoid for now. But keep up with the technology.

SiN