Hi guys,
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.
Cheers
Older browsers treat all unrecognised thags as the equivalent of <span> so if you want them to be treated as <div> you’d need to define them with display:block in the CSS.
That’s all I needed to know. Thanks 
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.
I use some CSS3 selectors, for things like border-radius, RGBA (with fallback), box-shadow, etc. If they aren’t implemented by the browser, it’s not a huge deal.
The rest, or anything HTML5, I won’t touch.
Also, if you want to use HTML5 in IE <9, you’ll need to use Remy Sharp’s HTML5 Shiv : http://code.google.com/p/html5shiv/.
IE won’t honour your HTML5 elements unless there’s some JavaScript tinkering first - Remy’s shiv will do this for you; just place it in the <head> and away you go.
Of course, users without JS enabled will simply see a horrible mess as all your new block-level elements won’t render correctly. For me that’s the biggest roadblock to HTML5.
As kma said you won’t be able to style those new elements in IE unless the JS runs first.
I haven’t heard anyone else doing this, but you could have a server side script change the new attributes back to <div> (with a class name) for browsers that don’t support them. That way things would work for IE users with JavaScript disabled too.
In PHP you’d probably use object buffering to modify your markup before it’s output.
It all just sounds like too much of a ball-ache to me. HTML5 can wait
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.
Such as all the extra input types. If the browser supports it then you have the new input type else it’s just text. So you lose absolutely nothing by using it. And it means you don’t have to incorporate any messy javascript alternatives.
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’m normally the most pro-html5 person around and I say use the new doctype and new input types (it doesn’t matter if the new doctypes change in the future - it’ll just become a text type instead), but I’d say wait a few years for the new elements - IE doesn’t understand them and using javascript makes me feel uncomfortable…
Hear hear. I don’t get why so many people, even standardistas, are building sites that depend on JavaScript. And as felgall says, we could easily be heading for another generation of quirks, which is truly frightening.
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.
Here’s just an example of the kind of stuff going on out there. Yay, JAWS 12 works! Oh noes, you have to sell your grandson to afford the upgrade from JAWS 10! That kind of thing.
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
I agree completely, I hope you didn’t misunderstand my earlier statement
No, just wanted to emphasise it. For everyone who just points out that the new HTML stuff can’t replace server-side validation, there are others wondering if they have to do something extra (I guess if they haven’t been validating or relying on Javascript, yeah, they do! : )
I am not using html5 because in developing large size html5 applications there is a lack of good productive tooling and it has a limited support for media formats.