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:
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.
The upper atmosphere of the Earth will be set on fire and everyone in the world will see this. It will be set on fire by the U.S. military using their H.A.A.R.P. (High-frequency Active Auroral Research Program) climate control weapon.
Four heads of state will die within a week of each other and within one year of these deaths WWIII will start.
Anyone caught within 50 miles of a hydrogen bomb detonation will suffer damage to their soul, even to the point of the total destruction of their soul, which would release their spirit in energy form back to God, and they would cease to exist as individual spirits.
Extraterrestrials will land and assist the survivors of WWIII in the establishment and construction of a new civilization based on God’s Commandments and Spiritual Principles.
In addition to all these calamities, Kurt Cagle predicts that if you use boolean attributes in your HTML5 (so selected instead of selected="selected" for example) you will
require special HTML processors to handle them. This makes them a pain to store in XML databases (you have to store them in text, losing a lot of the indexing goodness that comes with having XPath compliant XML), a pain to parse, a pain to transform…
We’ll be back to the days of the late HTML 3 spec, where web designers despaired of having their web pages act even remotely consistently between browsers, where coders will continue to learn bad habits that not only create more headaches for other coders but also contribute to the overall cost of products.
The future ain’t bright, chums.
Might as well give up now. I’m off to smoke heroin and take up alcoholism.