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
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:
As a part of Microsoft’s continued commitment to interoperability and standards support, yesterday we submitted our request to join the Scalable Vector Graphics (SVG) Working Group of the World Wide Web Consortium (W3C). We’re excited to take part in ensuring future versions of the SVG spec will meet the needs of developers and end users.
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.
Many developers have assumed that only Gecko and Webkit browsers will ever render CSS rounded corners or transitions, so have only specified their CSS with -moz- or -webkit- prefixes—sometimes while simultaneously berating other browsers for not supporting these properties yet. Note that Microsoft has announced that IE9 will support border-radius but if you only specify Firefox and Safari in your code, your future IE9 users won’t see those wonderful rounded corners anyway.
So, to widen the reach of your super-sexy designs, please take a minute to add the -o- prefix to your CSS transitions and transform declarations, and to add border-radius and box-shadow without vendor prefixes.