As I sit here in Austin, Texas munching a breakfast of bafflingly-termed foodstuffs like “eggs medium over-easy”, “white omlette” and incorrectly-pronounced tomatoes, I thought I’d update you on a few HTML5 tidbits.
The first is the news that Google will start indexing content marked up using microdata. No browser does anything with data it finds in pages, but the voodoo magicians that do SEO will presumably find the chance of extra googlejuice compelling.
I’m a lurking member of two W3C subgroups that work on the accessibility of video and canvas. We recently had two internal votes. The first was on what type of captioning format should be supported, and asked us to choose between the .srt format (a plain text file with time markers and text) or the W3C standard DXFP which, although minging, allows markup. (.srt seems to me to be as limited alt text on an image; it can’t contain markup or styling information). I voted for DFXP because, at its most basic it doesn’t need to be more complex than plain .srt, but has the potential for extensibility when browser implementations become more sophisticated. (My vote was a personal opinion and not an official Opera vote, by the way.)
The second vote that’s taking place is about extensions to canvas. There are two main proposals, one is for a new attribute called adom (for “accessibility DOM”) that constructs a “shadow DOM” for assistive technologies can hook into – and which the author must ensure is in sync with the visual rendering. I’m uncomfortable with this proposal for reasons that I’m not quite able to articulate at the moment (but its author is at South By Southwest so I hope to be able to catch up with him for a chat).
The proposal that I like is to extend canvas is “Improve image maps, don’t use @adom” which I favour because it uses familiar markup and reuses ideas from (and browser implementations of) HTML4. (Disclosure: the proposal was made by Chaals, Head of Standards at Opera, but that’s not why I prefer it.)
Anyway, gotta go and shower my pits before booth-bunnying the Opera South By Southwest booth. It’s in row 300 of exhibition room 4. Why not stop by a chat, especially if you’re a gorgeous Web Standards babe, or have a black coffee for me? Alternatively, I’m first speaker at an HTML5 extravaganza on Sunday from 2 to 6 pm.
Yikes. I remember when I used to blog at least once a week. I blame twitter. And the boss, for making me do some work.
Anyway, if you’re headed over to South By Southwest next week, and fancy learning about HTML5 on Sunday afternoon, please pop along for a three hour workshop with me and some lovely friends from the world of accessibility, Mozilla and Microsoft in Ballroom F (this is a rom change to one double the capacity of the origianal venue – gulp!).
The running order is
HTML5: Tales from the Development Trenches
2:00 PM – 3:00 PM
Me ‘n’ Martin Kliehm. An overview of how HTML5 came to be, why we need it, what it can do: new structural elements, intelligent forms, scriptable images with <canvas> and a brief introduction to <video>.
Wow, That’s Cool… Fun With HTML5 Video
3:30 PM – 4:30 PM
Chris Blizzard (Mozilla), Michael Dale
HTML5 Accessibility
5:00 PM – 5.30 PM
John Foliot (Unrepentant hardliner and lovely bloke), Cynthia Shelley (Microsoft)
I ain’t never been to South By Southwest but everyone done told me that it’s awesome to the max (I’m a-larnin’ to speak American – yee har!). I don’t know much about Texas; is it the law that you must wear a JR Ewing stetson?
If you can’t make the talks, hopefully I’ll see you at the Opera booth and get a chance to love you up like the gorgeous canoodlebot that everyone tells me you are.
A very good friend of mine wrote to urge me not to promote the jCap jQuery plugin to generate overlaid video captions from a transcript.
The reasoning was that my proof of concept is a hack and we will soon have real specifications for Media Text Associations and a Media Multitrack API. Of course, those specs need to be agreed and—here’s the rub—implemented in browsers.
My friend also worries that by propagating a hack, I might entrench worse practice and therefore discourage adoption of the proper way. This argument is compelling. However, this worries me because it basically means that HTML5 videos would be inaccessible today by design, waiting for proper accessibility jam tomorrow.
What do you think is the right way forward? Hacking for accessibility now, in a manner that’s acknowledged to be not “proper”, or waiting?
Last month, I wrote an article on Accessible HTML5 Video with JavaScripted captions and dreamed that some clever JavaScripters would take it up and improve it, making it more generic so that a developer could mark up a transcript with timestamps, call in a library and -hey presto!- there would be captions.
Those nice chaps at 360innovate have started work on a jQuery plugin called jCaps.
As it’s all open licensed, if anyone fancies participating, it would be jolly. Here’s a wishlist that I’d love to see, and would write if I were not so scripting-challenged:
It would be useful to point to the transcriptions via the aria-describedby attribute on the video element, the values of which point to the id of an element containing the transcript (which could therefore be an article, a div or whatever). You can have multiple values on aria-describedby (like you can with class) so that allows you to point to different translations.
This allows you to have transcripts anywhere in the source, so greater flexibility for laying out the page.
If there are multiple transcripts for a single video, they need to have a lang attribute, and the script should construct a select element so the user can choose the language they wish to see transcripts in. (The first one offered should be the transcript that matches the lang attribute on the html element; if there isn’t one, the default should be the first in source order.
I’d love to see a sexy (and stylable) skin around the video element that had a YouTube-stylee user interface that houses all the buttons for turning on captions, transcripts and the language picker.
Anyone up for the challenge, and generous enough to release it as a BSD-licensed library/plug-in?
Note that this technique will have a limited shelf-life. The HTML Accessibility Working Group have two specifications that will enable captioning etc to be done natively once the spec is agreed and (of course) implemented.
My hubcap-thieving Scally chum Jake Smith emailed, expressing concern about the the fact that the codec impasse means we have to encode video twice, once as Ogg and once as H264 to deliver in HTML5:
My concern is from that of a business. Encoding as OGG will only further questions from clients, rather than answering them. “So, this video you’re encoding… I can’t watch it on my Mac (safari)? And I still can’t see it on my iPhone?”
There’s the obvious “be damned with licenses” and encode as MP4 anyway, but then I have to encode twice, which is ok for the odd video, but could be a right arse long term, as that’s more cost to client, and as far as they’re concerned why not pay once for encoding to FLV?
From my (business) point of view, there is no point in chasing HTML5 for video. No matter how much I want to do the right thing…
I’ve only worked for quasi-public sector sites for whom profit isn’t an imperative, and I’ve been absorbed thinking about open-ness and standards, so hadn’t given Jake’s perspective much thought.
To me, the negatives are:
Double encoding is time, extra process and more storage
Flash “works” – change is expensive
The advantages to using open HTML5 video are
It’s (ultimately) a better user experience, as user doesn’t have to worry about plugins (a major source of worry for non-techy users)
It works on iPhones and (eventually) other mobile browsers
As a web designer, you can do fancy stuff with CSS etc as it’s native in the browser (this may not matter to business; depends what they want to do with the video)
The native video controls are keyboard accessible (in Opera; in Firefox, only when JavaScript is on; in Chrome and Safari, not at all)
You can have a textual transcript, which can be scripted into synchronised video captions: great for “Search Engine Optimisation” and “DDA compliance”
Any one care to wade in with some business reasons for or against double-encoding and using HTML5 video?
What? Two blog posts in one day? Not really; this is just a teaser for another article.
The HTML5 video element provides a fantastic way to embed video into web pages without relying on plugins, and it is now supported in Opera, Firefox and Chrome, so things are looking up. One burning question however is “how do we provide alternative content for users that either can’t see, or can’t hear the video?
Inspired by Shelley Powers who quipped “HTML5, it is a changing” on Twitter, I in turn said I was gonna write a Dylanesque song about HTML5. Of course, between that time and the time I got to the next available WiFi point, Jeff Allen wrote the song.
Opera’s Man in Japan, Daniel Davis, gave us a touching rendition on his ukelele:
In homage to the man known as “Ukelele-San” from Sapporo to Nagasaki, as well as to Molly, Shelley, Jeff, Hixie and His Bobness, I offer my rendition:
For a while I’ve been wondering how to demo the HTML5 mark element. It’s quite a funky little element, acting a bit like a highlighter pen, to draw attention to some text. The spec defines it
The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context. When used in a quotation or other block of text referred to from the prose, it indicates a highlight that was not originally present but which has been added to bring the reader’s attention to a part of the text that might not have been considered important by the original author when the block was originally written, but which is now under previously unexpected scrutiny. When used in the main prose of a document, it indicates a part of the document that has been highlighted due to its likely relevance to the user’s current activity.
Over the yule break, the answer came to me (as it so often does) as I was demolishing a bottle of red. For a couple of years now, this blog has used a script that highlights search terms if you’re referred here by Google or Yahoo. The script is written by flame-haired temptress Stuart Langridge, who describes how it works:
It checks document.referrer for a querystring with q=somethingorother in it (as Google does, and as do a host of other search engines), breaks that query up into words, and then recursively walks each node from the BODY down, once for each search word, looking for text nodes. When it finds a text node it checks to see if it contains the current search word; if it does, it replaces the current text node with three new nodes — one which is a text node containing everything before the search word, a span containing only the search word (and of class “searchword” — this is why the highlighting works!), and another text node that contains everything after the search word.
With Stuart’s permission, I simply amended the script to surround the search term(s) with the mark element rather than a span, although I’ve retained the class searchword in case you want to style these marks differently from others.
In my CSS, I just added the rule article mark {background-color:#FFC0CB;} to turn it a gentle shade of pink (my other New Year Resolution is to get in touch with my feminine side) and we have a useful demo.
Occasionally someone pipes up on the twitter #html5 hashtag asking why the nav element has a height and width of zero, or why browser X refuses to render a section properly.
Note that although the initial value of ‘display’ is ‘inline’, rules in the user agent’s default style sheet may override this value.
Browsers have default stylesheets. That’s where the “unstyled” HTML is styled. You don’t think it’s styled because it’s not using your lovely CSS, but actually there is a rudimentary stylesheet in the browser that sets things like div {display:block;} or the default fonts, margins and paddings for headings.
The browsers don’t “know” about most new HTML5 elements (except canvas and video), so they don’t define section, nav as display:block and thus they remain as inline, as the spec says.
The way round it is to define them all in your stylesheet. Simple as that.
This raises two vaguely interesting philosophical points.
The first is about CSS reset stylesheets. A true CSS reset would set every element to be display:inline. (Personally I see little value in reset stylesheets except as a debugging/ educational tool, however.)
The second is the question of what it actually means for a browser to “know about” an element. In the case of an element like abbr or input, there are certain inherent behaviours.
But with something like div or span, or even i and b, the only thing the browser needs to “know” is how to style it. Any arbitrary element is already findable by JavaScript getElementByTagName (whether it be a new HTML5 element or something entirely arbitrary like a cheescake element) because JavaScript can be equally used with other markup languages such as XML which can have user-defined elements.