What I didn’t know about HTML5
(Plus a little bit of CSS3).
Bruce Lawson from Opera software came to Skillsmatter on Wednesday night to talk about HTML5 (video here). What follows are my notes. I’m not an HTML5 boffin, but I did start to code a client site in the new doctype recently. Here are the bits I thought were interesting. To read it properly you need to understand more about HTML5. I’d recommend the HTML5 Doctor website or tentatively (I haven’t read it) Bruce and Remy’s book. Sorry for any typo’s etc in the following.
Opera did their own study of the top twenty class and ID names because Google wouldn’t share their results (the HTML5 spec was built on the results of Google’s research). Google looked at 1000 million web pages. You’d wonder why was this important, but e.g. The ID and class names are really important for screen readers. HTML5 gives 28 new tags (or 29 because one’s still being decided).
There’s no version number in the HTML5 doctype because in implementation it never really mattered, bowsers will render what they can, they don’t care whether the tag’s in HTML4 or whatever. All the HTML5 doctype is designed to do is send the browser into standards mode. Therefore it’s the shortest string possible.
Interesting, if you don’t declare a character set, Internet Explorer (IE) has a small but real security risk. The character set declaration must appear within the first 512 bytes of the document. Browsers also never cared whether you closed your tags, they didn’t care whether you used upper or lowercase tag names. The validator did, but the browsers didn’t. The browser also doesn’t care (in HTML5) whether you put in the <head> and <body> elements, the browser puts them in if you don’t. He demo’ed Opera doing this. However Internet Explorer (I assume before IE9) won’t style up a page unless the body tag is present.
He recommends http://html5.validator.nu since it’s the validator that tends to be most up to date.
I forgot you don’t need to close tags in HTML5, that’s just weird, surely the browser has more to guess? Surely the rendering will become less predictable?
* Actually, I spoke to Bruce about this afterwards. He said 70 pages of the HTML5 spec are devoted to telling browsers what to do when elements aren’t closed properly. Therefore any guesswork (not really guesswork if it’s in the spec) on the browser’s part will be consistent across all UAs. The only thing I didn’t ask about is what happens in browsers that use the HTML5shiv and don’t support HTML5, e.g. if IE reads the page, is it still rendering in HTML4? Do I still need to use closing tags to help it along?
The <small> element has been redesigned in HTML5 to mean ‘copyright’. It’s designed to isolate legalese from the rest of the content.
When thinking of <article> don’t think of a newspaper article (one per page), think of an article of clothing. If the content is discrete and could be pulled into another website it’s probably an article.
HTML5 can be styled in IE without JavaScript but you must know the DOM throughout. Bruce will post a link about this on Monday.
Forms
In HTML5 the browser implements standard error messages for forms. What I didn’t know was using JavaScript, you can intercept these messages and replace with your own. HTML5 is potentially more accessible since “built-in beats bolt-on”, if a slider etc are already built into the browser it’s better for you and accessibility. At the moment the date picker doesn’t work very well with screen readers. It currently depends on the browser and the operating system. NVDA and VoiceOver both work quite well with HTML5 forms. The leading commercial screen reader vendors don’t appear to be interested.
Video
HTML5 video controls are keyboard accessible. You can use a still image to represent a video on screen but there’s a bug in Mobile Safari that doesn’t show the default image. Supporting Ogg and H.264 at the same time is possible! For Safari you put in a second child video source that’s coded in MP4. It means you have to encode your video twice to be cross browser compatible (three times if you use a Flash fallback). Put in an Ogg <source> for Opera, an H.264 <source> for Safari, then a Flash <embed> for IE (before IE9). There’s a bug in iPad that means it only recognises the first source element, so where you want to include H.264, Ogg and Flash fallback, you need to include them in that order. Bruce plans to post his code examples for all of this on Monday, or you can review the video at the top of this post.
CSS3
There were lots of snippets of information on this. All I wrote down was the following: if using vendor prefixes in CSS, Bruce always includes all for the major browsers e.g. -moz- ,-ms-, -o-, -webkit- and the unprefixed statement, e.g “transition:”. Use these features with caution, you don’t know if proposed CSS declarations will be modified in implementation or dropped from the spec entirely (as “box-shadow” apparently has been, but it may come back).
Posted on Wednesday 18 August 2010.
2 Responses to “What I didn’t know about HTML5”
Leave a Reply
Categories
- @media
- accessibility
- Ajax
- apple
- BeBettr
- books
- browsers (UA)
- charity
- cognitive
- creativity
- css
- css3
- design
- development tools
- education
- employment/experience
- gadgets
- health
- html5
- images
- iPad
- iPhone
- layout
- marketing
- notes
- politics
- privacy
- security
- social
- typography
- Uncategorized
- usability
- wtd2010
Archive
- February 2011
- January 2011
- November 2010
- September 2010
- August 2010
- July 2010
- February 2010
- January 2010
- October 2009
- September 2009
- July 2009
- June 2009
- May 2009
- September 2008
- June 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- April 2007
- March 2007
- February 2007
- January 2007
“three times if you use a Flash fallback”
Flash should be able to use the same h.264 encoded video that you are sending to Safari/iDevices. So you can keep it at just 2 encodes. (Of course if you want dynamic bit-rate, which lets be honest why wouldn’t you, you will need lots more encodes ;)
Thanks for the write-up Nick. A few clarifications:
“Internet Explorer (I assume before IE9) won’t style up a page unless the body tag is present.”
IE9 developer preview requires the body element.
“70 pages of the HTML5 spec are devoted to telling browsers what to do when elements aren’t closed properly. ”
I was exaggerating. Here’s the 10 pages that define HTML5 parsing: http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html
“In HTML5 the browser implements standard error messages for forms.” – the spec is silent on how errors are reported. Tha’s entirely up to the browser. (WebKit doesn’t report an error at all, just replaces the cursor in the erroneous field).
“you have to encode your video twice to be cross browser compatible (three times if you use a Flash fallback)” – nah, Flash can play the mp4 you made for the royalty-encumbered browsers: see http://camendesign.com/code/video_for_everybody. (I was using a YouTube embed to show that embed is valid, and to avoid having a SWF of a video player on my server.)
Here’s a link to the demos and resources http://my.opera.com/ODIN/blog/london-html5-user-group-html5-and-css3-101