Basically, I’m considering starting to use HTML5 markup soon and I was wondering if there’s any downside for users of older browsers. For example, if I’m using the <header>, <section>, <article>, <nav> and <footer> elements, will they fall back to emulating <div> on an older browser, or will they just fail miserably? I don’t see a whole lot of point in using them unless there’s adequate support, and a quick Google isn’t really giving me the answers I’m looking for.
I’m not touching html5 or css3 for commercial work until they become “officially released” recommendations from the w3c and after that only after they are at least close to fully supported by the major browsers.
until then, especially with browser manufacturers being able to doing their own thing, using htnl5 and css3 could be more problematic than it’s worth imho.
As kma said you won’t be able to style those new elements in IE unless the JS runs first.
In PHP you’d probably use object buffering to modify your markup before it’s output.
I work for a large retailer and we are already using HTML 5 with success (started using it around January). Getting started is as simple as changing your doctype (you can continue to write valid HTML 4 markup instead of using the semantic tags). This site has excellent info on what HTML 5 is and the challenges/workarounds related to using it: http://diveintohtml5.org/. By changing your doctype, you have the option to progressively enhance your site with the new features. For example, we don’t use the semantic tags at work but we are starting to use the Geolocation API.
I don’t really see why anyone who is starting a new website wouldn’t use HTML5 and CSS3. As Alex said it provides progressive enhancement. Fair enough if you don’t want to use the new elements (header, footer etc - though I personally do) but future proofing your site is a good benefit to have.
I do like the sound of the date and time inputs, placeholder text and autofocus, but it’s all stuff that we can do with JS now and we’ll still need to validate it at server-side. I’ve just had a look at some examples using Chrome and it fails miserably with a lot of fields, so I’m not entirely convinced that there’s any point at all. it seems that Opera may be the only browser that supports any of these inputs properly. However, some virtual keyboards like on iOS appear to detect the type and give you the appropriate layout, which is nice. Not nice enough to convince me though
Perhaps because they are still in draft and will probably change a lot before they are finished.
The last time this happened was when IE5 started supporting some of the CSS 2.0 draft and then the released standard was different - that’s where quirks mode originated as quirks mode was the way the draft read at the time Microsoft first implemented it. So you could consider the current HTML 5 draft as a new variant on quirks mode rather than necessarily being what will end up in the new standard.
I’ll say something about the new input types and the “we still have to validate on the server side”… you ALWAYS had to validate on the server side, this isn’t extra work of any sort. The possible benefit of the new inputs is, it may help steer users into inputting the correct info or type of info in the FIRST time, rather than them submitting and getting an error message. I can get behind the idea that inputs expecting a very limited type of data can be semantic and therefore more specific tags in the markup can make sense.
One reason I would NOT use HTML5 (and I don’t mean the doctype on top of HTML4) is the way screen readers are fumbling with the new elements. Sometimes it’s the fault of the reader. Sometimes it’s the fault of the browser. None of the browsers have implemented their accessibility to deal with HTML5, even the browsers who are claiming to “support HTML5”. There is a whole layer of additional information browsers send to any (possible) accessibility software that may be interacting with the browser or the computer’s windowing system and that needs to be built for all these new elements and attributes. Understandably, AT vendors are being slow and cautious since, as Felgall pointed out, this stuff is still in DRAFT. Things that are very unlikely to change such as <header> tags are getting addressed by browsers and AT but stuff like the “required” attribute in form controls or how to deal with the <canvas> tag’s API are still not done and won’t be any time soon.
If you are building a site that must pass some level of WCAG or section 508 or that new ammendment they want to add to the ADA or a commercial site in any of the countries that have started making demands on that sort of thing, you will probably want to stick to HTML4/XHTML until things settle down.
I agree completely, I hope you didn’t misunderstand my earlier statement