Goodbye XHTML 2, though no-one ever used you at all
you had the grace to hold yourself when all around you had a fighting chance of getting implemented. And it seems to me that you lived your life pissing in the wind…
The W3C has pulled the plug on the XHTML 2 specification. This was a philosophically pure specification that was so backwardly incompatible that it nearly deprecated the img element. But this incompatibility, the draconian error handling that XML requires and the fact that XHTML 2 was for documents and ignored web applications doomed it to failure as a method for delivering content to browsers.
What does this mean to you?
Nothing.
Your current XHTML 1.x sites still continue working (except in IE, if you serve them as XML rather than HTML).
You wanna use XML? Then use XML. For those interested in HTML 5, I draw your attention to an article that I presciently wrote yesterday on XHTML 5, for those who worry unnecessarily that XML has been killed.
HTML 5 took some good ideas from XHTML 2 - the idea of deriving the “level” of a heading from its context, although it preserves using h1…h6 for backwards compatibility rather than a generic h element. XHTML 2 allowed “href anywhere” so anything can be a link, and HTML 5 has a similar idea, although it preserves backwards compatibility by allowing the a element to surround block-level elements. The XHTML 2 element nl for navigation list is doubled in the HTML 5 nav element that wraps a ul or ol.
The main side-effect of the end of XHTML 2 is that its resources will now be given to HTML 5. It also adds to the pressure to include RDFa into HTML 5 (Microformats, being elements and classes, “work” already). Given that Google (the employers of the HTML 5 spec editor, Ian Hickson) and Yahoo are starting to use microdata, it’s almost certainly untenable to claim there are no use cases for it, and RDFa is already a W3C specification, albeit ugly to write and opaquely documented.
So you’re making a site “optimised for the iPhone”. Hurray! I was starting to miss those “this site looks best in Internet Explorer 5 with 800×600 resolution” badges.
1. Don’t do browser sniffing. The iPhone is just a phone, and Safari is a web browser. There are other browsers out there capable of rendering your content. There are even other mobile devices out there!
2. Think very carefully about why you want to use maximum-scale on viewport or user-scalable=0/ no. Is it for valid application reasons (think of zooming in on something in a game, whereby the zoom event does an XHR to the server to show a higher-scale map or higher-resolution image) or is it just to protect your lovely design?
If the latter, then it’s just the iPhone equivalent of setting fonts in pixels for old versions of Internet Explorer, as it prevents a user with low vision zooming the screen to a magnification that they want. And that is, of course, evil selfish and stupid.
On Monday, Rich Clark, Jack Osborne, Mike Robinson, Remy Sharp, Tom Leadbetter and I launched HTML 5 Doctor, a resource with small tutorials and references about—guess what? That’s right!—HTML 5. I hope it become the resource that I wished I’d had access to when doing my redesign after Xmas.
Yesterday, Sitepoint published an article of mine they called Yes, You Can Use HTML 5 Today!. The changed title made it seem like much more of a call to action than my original title “A snapshot of HTML 5″, updating Lachlan Hunt’s 2007 A List Apart article A Preview of HTML 5, and earned me comments berating me that current HTML 5 support isn’t perfect, but never mind.
Dull meta-note: I’d more or less given up blogging small announcements and links like this, as Twitter seemed more the medium for it. But at the @media conference, a lot of people who work in Evil Corporates told me that they can’t access Twitter at work, so I’m making a conscious effort to announce here as well.
The video element is the one that seems to excite n00bz the most when I do introductory talks about HTML 5, yet it was always the element that seemed to me to be furthest away from cross-browser interoperability.
Originally, the specification (being an Open Standard) said
User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format.
Ogg is a free, open standard container format maintained by the Xiph.Org Foundation which claims that it is unrestricted by software patents. Firefox and experimental video builds of Opera support Ogg for the element.
However, there were complaints from Nokia (PDF) and Apple that Ogg formats are not good enough technologically and still within patent lifetime and therefore susceptible to submarine patents (unexpected future patent challenges).
Therefore, the spec was revised with the much more wishy-washy
It would be helpful for interoperability if all browsers could support the same codecs. However, there are no known codecs that satisfy all the current players: […] This is an ongoing issue and this section will be updated once more information is available.
Yesterday, Ian Hickson removed any mention of codecs from the spec because of impasse and non-interoperable implementations: there is no suitable codec that all vendors are willing to implement and ship. He writes
Apple refuses to implement Ogg Theora in Quicktime by default (as used by Safari), citing lack of hardware support and an uncertain patent landscape.
Google has implemented H.264 and Ogg Theora in Chrome, but cannot provide the H.264 codec license to third-party distributors of Chromium, and have indicated a belief that Ogg Theora’s quality-per-bit is not yet suitable for the volume handled by YouTube.
Opera refuses to implement H.264, citing the obscene cost of the relevant patent licenses.
Mozilla refuses to implement H.264, as they would not be able to obtain a license that covers their downstream distributors.
Microsoft has not commented on their intent to support video at all.
So does that end the dream of interoperable, no-plugin video in the browser? Perhaps not entirely.
The short answer is that we don’t know for certain, but we’re pretty sure we don’t. We haven’t employed armies of lawyers to trawl through the tens of thousands of video compression techniques.
is unlikely to satisfy those who are worried about submarine patents in Ogg.
Sun Microsystem’s announcement of their OMS Video format was exciting:
The Web needs royalty-free video and audio codecs.
…OMS Video seeks to bring an updated royalty-free variant from the h.2.6x video codec lineage to the open source / royalty-free community. With the open source / royalty-free codec community, the OMS Video initiative seeks to collaborate through shared interests and common royalty-free technologies, to unleash innovation, and to update outmoded RAND (”reasonable and nondiscriminatory”) standardization processes to Web speed.
I’m not pointing the finger at any other browser manufacturers because it’s entirely understandable after the EOLAS patent debacle that browser vendors are frightened of submarine patents. (I work for Opera which supports Ogg Theora/Vorbis but this is a personal site not the opinion of employers blah.)
What this sorry story really shows is that closed standards and proprietary formats are the enemy of an Open Web.
Corblimey what a week and no mistake guv. (Sorry, still getting the last Lahndahn molecules out of my system.)
The Meffys
Firstly, on Tuesday, I attended a formal event on behalf of Opera as our Opera Mini mobile web browser was up for Best Mobile Application at the Mobile Entertainment Forum’s Meffys awards. I’m not really a suit-and-tie business dinner type person, but duty called so I went along in my wedding-and-funeral suit for the onerous task of drinking free mojitos while listening to the host Hardeep Singh Kohli. (Lots of people said they found him too abrasive, but I thought he was a good choice.)
Lo and behold - we won! Feeling very proud and, forgetting my acceptance speech that our PR types had prepared, I clambered onto the stage and made an impromptu thankyou speech which would have the PR team having palpitations were it recorded anywhere, did a quick video interview for a journalist and took the coveted award home back for a couple of relaxed tie-less beers with David Storey and Chris Mills in the hotel bar.
@media
At media was primarily a great gathering of the clans—I thought that the line up was playing it safe (entirely understandable in the current climate). I [particularly enjoyed persuading 30 people away from some poncey overpriced South Bank bistro in favour of a Waterloo greasy spoon where they stayed open especially to serve us snake and pygmy pie with beans and chips and a pint of lager for under a tenner.
The best speech for me was Robin Christopherson’s, in which he discussed ARIA and CAPTCHA as well as phone accessibility. I made an unscheduled appearance on stage as the HTML 5 cowboy during Molly’s presentation and donated the backless faux-leather chaps to Chris Wilson of Microsoft who’s the co-chair of the W3C’s HTML 5 working group. He said that he would pass them onto Ian Hickson. I hope that they do the rounds of HTML 5 movers-and-shakers.
Standards.next
On Saturday the first standards.next informal emerging tech bootcamp took place. I was delighted how it went, having co-organised it with Henny Swan. We cajoled a stellar line-up of speakers to sit in a friendly (but very hot and sticky) atmosphere and really get under the skin of HTML 5. I humbly thank every one of them.
Me
I over-ran on time without finishing my slides, discussing some myths that are causing unnecessary FUD and doing a basic demo of markup for a blog.
For the first half of Dean Edwards’ HTML5.js talk, most people couldn’t grasp the magnitude of what they were seeing. Dean was showing his new JavaScript library that plugs the holes in browsers’ HTML 5 implementations. If a browser does do something natively, ther library does nothing; otherwise it fills that gap—so now you can have Web Forms with all browsers, canvas in IE. As a bonus, it’s all keyboard accessible, everything looks like native UI controls and it even inherits the native Windows themes. I’m looking forward to helping beta test this baby.
Martin Kliehm
Martin showed several demoes of the new canvas element that blew my mind. I’d rather assumed that it was just for wiggly graphics and maybe on-the-fly graphing but Martin showed some combinations of canvas interacting with video (because once everything is in the browser rather than plugins, they can all talk to each other).
There is real potential for new interaction models for people with learning disabilities, older people and kids.
Steve discussed the accessibility issues of the HTML 5 spec and its relationship with ARIA. I came away from Steve and Martins’ talks convinced that the biggest barrier will be the lack of real support for canvas accessibility and commend Steve for fighting this in the Working Group. I shall be standing with him in future.
I want to thank all the speakers who volunteered to share their knowledge, passion and expertise with us, and thanks to all who attended, and interacted with all the speakers to help us firm up our knowledge.
Although there were some problems (heat, pillars in the way), the event went exactly as Henny and I hoped: a relaxed pub (£1.95 a pint of bitter and you can take your own sandwiches in!), short focussed speeches of 30 minutes so speakers don’t feel the need to pad and a genuinely interested crowd who participated rather than passively absorbed the information. This lady is an excellent example:
HTML 5 Doctor
I plugged it at @media and standards.next (and forgot to give out the moo cards), and we’ve launched the bare bones of it today - HTML 5 Doctor (named in homage to an early Zeldman feature called “Ask Dr. Web”).
High Standards t-shirts
If you got a freebie High Standards t-shirt from us at standards.next, please post a picture of you wearing it to Flickr and tag it highstandards, because I want to remember how lovely you are.
For a while now there has been a battle raging between accessibility advocates and those who are most closely involved in drafting the HTML 5 specification.
I’ve bravely kept out of much of it as it’s been quite acrimonious and I am, as you might have realised, a delicate flower. (Actually, since I’ve been working from home on my own, I do take things much more to heart than I used to. Silly me).
The biggest arguments have been over the alt attribute for images. At some point, HTML 5 allowed alt to be optional; a huge flamewar erupted and now there is a massive lump of text in the spec discussing alternate text. I think this is wrong, and the spec should simply make alt mandatory (while noting that it may be blank) and point to WCAG for guidance; it is, after all, the authoring guide to accessibility from the W3C
On the debate on the summary attribute on table sees me side with my chums on the HTML 5 cabal. Now that we have ARIA attributes like aria-describedby, and HTML 5 elements like details (which “represents additional information or controls which the user can obtain on demand” - see the details element spec) I think there are better ways of doing it. (I feel the same about longdesc too.)
I’m suspicious of invisible screenreader-only elements. A long time ago, I worked with kids with learning difficulties—autism and Down Syndrome—and can’t help thinking that the information that’s usually in summary to provide a mental map of a data table to blind people would be as useful to those kids. (This discussion is taking place on Gez Lemon’s blog, in a very pleasant tone, I’m glad to report).
Anyway, yesterday Janina Sajka, the Chair of the W3C’s Protocols and Formats Working Group pronounced on the two matters I discuss above in a document called WAI CG Consensus Resolutions on Text alternatives in HTML 5 which is worth a read (it’s neither long nor complex). I don’t know what happens now procedurally but hopefully it’ll put an end to those battles and everyone can have a lovely big group hug and a sing-song.
Until we get started on the accessibility of the canvas element, that is.
More of my brilliant observations on HTML 5 accessibility:
You, dear reader, are almost certainly one of the most talented CSS experts on the planet. No, don’t blush; everybody says it.
So here’s a challenge for you. I have a defintion list. It’s a glossary—a collection of terms and definitions. Semantically, therefore, it’s indisputably correctly marked up as dt and one or more dds, all wrapped in a single dl. (It’s not a naughty dl in a form or any misuse like that).
I want to style it in a way that’s very common for glossaries—term on the left, and all the different definitions on the right. Each new term starts a new “row” for want of a better word. It needs to be robust; some terms are longer than their definitions; some terms have multiple definitions.
I can’t do it.
If I add a non-semantic (and invalid) div around each term and its definition(s), then float:left; clear:left;, it works perfectly. But without that meaningless extra element, it looks minging. (Colours and the classes used to add those are just for illustration.)
Whichever way I try (absolute positioning, using display:table-*, inserting generated content and floating and clearing that), I can’t get it to look as I want it.
It’s obviously a common problem. The HTML 5 group declined to add a di (definition item) grouping element to solve this, rightly saying
This is a styling problem and should be fixed in CSS. There’s no reason to add a grouping element to HTML, as the semantics are already unambiguous.
So, dear reader: can you do it? There’s free entry to standards.next and a snog with tongues for the lucky winner.
Rules: you can’t change the markup. This would be easy to do with multiple dls, but it isn’t a series of lists: it’s one list of multiple terms. And, yes, it could be marked up as a table, but it isn’t a table, it’s a list of definitions and we all know that tables for layout is evil.
(This isn’t me just being lazy; Molly is attending the CSS Working Group’s face-to-face PARTAAAY!! meeting, and we were discussing things to bring up there.)
Last week, I published an HTML 5 contact form Wordpress plugin that used the HTML autofocus attribute to put the focus into the first form field.
Marc Aplet commented about the accessibility of doing that, for which I am very grateful as it made me think more deeply about it. Thanks to those on twitter who helped me further with my thinking.
Note that potential accessibility problems are not restricted to the HTML 5 use of autofocus; current JavaScript ways of doing it cause the same problems.
I believe that autofocussing into a form is a usability win for most people if the purpose of the page is that form—for example, the Google hompage. So, I wouldn’t autofocus into the search box or comment field on this page because the primary purpose of this page is discussing this article which requires prior reading. Most people are lurkers, not commenters, so it’s against usability to autofocus into the comment form. But a contact form is the primary purpose of a contact page, and it saves users a keystroke to put the caret into the first field—particularly usable for mobile phone users.
However, screenreader users find themselves dumped in the middle of a form, potentially without context (athough it’s always possible to tell the screenreader to repeat the title of the page, and we all give our pages useful titles, don’t we?).
Moreover, many forms have explanatory or introductory information preceeding them. My contact form does, although that’s somewhat flippant. A better example is Salford University’s Online Staff Directory Quick Search Page. The explanatory information is correctly outside the form element, as JAWS and (I think) Windows-Eye ignore any text that’s not inside legend and label elements when they’re in Forms mode.
What we need, then, is a way to associate some explanatory descriptive text that’s outside the form with the form itself (in a similar way that label and input are explicitly associated). Then a screenreader user could be alerted to the presence of this descriptive material by this programmatic association, and optionally choose to have it read out to them.
An accessible description may be computed by concatenating the text equivalents for nodes pointed to by an aria-describedby attribute on the current node.
So, I recoded the plugin (download it; it’s at your own risk etc) so that the descriptive matter is enclosed in a div id="form-description". The form element has the attribute aria-describedby="form-description" (because the description is for the whole form).
I don’t know if any screenreaders offer a keystroke to query this information yet (it’s over a year since I’ve been near a screenreader), but as the vendors have worked closely with the WAI-ARIA authors I imagine it won’t be long.
I also amended the plugin so that it has a belt-and-braces approach to the form fields that are required. In addition to the HTML 5 required attribute, I’ve added aria-required="true" as this is probably closer to implementation by screenreader vendors.
Because there are already two programmatic methods of indicating that a field is required, I’ve removed the traditional method of including an asterisk in the markup, as it’s possible to style the form fields with CSS—I’ve used a thick black border. (I tried to use attribute selectors to generate the string “required” immediately after the form field, but that gets surrounded by the field border rather than living outside it. The result is minging, even by this site’s low design standards.)
I’d been looking for ages for a decent plugin for WordPress that would give me a contact form that was easy to configure and didn’t use a CAPTCHA.
I eventually found Easy Contact which fulfilled those criteria. With a little jiggery-pokery, I hacked around the code so it produces an HTML 5 contact form featuring
autofocus to put the cursor in the first form field
in-browser validation of certain input types using input type="email" and input type="url"
the required attribute on fields that can’t be submitted blank (name, email, message and challenge question). I’ve styled these a foppish pink using input[required], textarea[required], while retaining the clunky asterisk-for-required-fields convention until screenreaders automatically tell users that a field is required
