This week in HTML5…in verse.
So <time> is saved though it may be changed, and <data> is on the horizon. <hgroup> is going, you can hear it moaning, as HTML5 continues to wizen.
Category: W3C
The standards organization for all things web
One of the still open issues with HTML5 is the lack of a verbose descriptor for an image, since the longdesc attribute was made obsolete.
The longdesc attribute used to take a URL to a separate page or page fragment that contained a long text description for a complex or highly nuanced image. Typically, the only ones made aware of the attribute were screen reader users, though some browsers, such as Opera, provided access to the long description via the the right mouse button menu.
However, longdesc was made obsolete because, supposedly, there was no justification for its continued existence.
There is no better justification for a verbose descriptor/longdesc, though, than political cartoons, as I demonstrate over at Puppies @ Burningbird.
The argument that the material describing the image can be repeated in the page just doesn’t fly. To repeat the image data textually, just before or after the image, not only detracts from the image, it lessens the impact the political cartoon intends.
At the same time, political cartoons are highly sophisticated bits of imagery, which can’t be described in a small blurb in an alt attribute. They also provide essential information, because political cartoons are created specifically to convey important arguments about ongoing political and other activities.
It’s just plain asinine to fight against such a valuable aid as longdesc, or any equivalent, with the vehemence that the WhatWG participants in the W3C HTML WG have displayed.
Well, thank goodness HTML5 no longer exists and we live in a time of a versionless, living standards HTML. Since HTML now exists along an unbroken continuum, from the beginning to infinity, and since longdesc was a valid attribute at an early point in this continuum, longdesc remains valid…now, and forever.
TPAC is the W3C annual meeting where the various working group members gather in bloody battle to see who emerges victorious…and who then has to buy the beer.
I’ve just published my response—in my usual quietly thoughtful manner—to Opera employee notes from the meeting at RealTech.
In my earlier writing, I suggested that after October 1st, people with comments should send emails to the public-html-comment email list, as I thought this would be where Last Call comments would be addressed. Evidently, I was incorrect.
According to a clarification I received, all comments should be submitted to the Bugzilla database. In addition, any arguments should be presented in the Bugzilla database. The HTML WG will be tracking using the Bugzilla database, unless the resolution makes people unhappy, in which case the item will become an issue. When an item does become an issue, then the only way you can continue to participate is basically become a member of the group. Oh, any comment in the public email list is supposedly addressed, but discussion will most likely happen in the members-only email list.
I’m not sure how comments from other W3C groups will be handled—perhaps by Ouija board; maybe strips of paper tacked against a wall, and thrown darts.
If you get from my comments that I don’t like this process, I don’t. A bugzilla database is not the place to handle concerns or suggestions that aren’t editorial or corrective in nature. It’s difficult to follow the discussion, and most of the discussion takes place out of the public eye. In addition, you can’t thread the replies, which means everything gets smooshed together linearly, with a lot of message copying, and references to “Comment Number 14”. Bugzilla is also not the most accessible software in the world.
Relying on Bugzilla to manage Last Call comments sucks. It’s also demonstrative of a group that has not effectively dealt with conflict. Instead of dealing with the major issues—such as the continuing split of the document across W3C and WhatWG, or the disquieting trends reflected in accessibility bugs—the HTML WG has, instead, tried to get technology to take care of the problem. And you know something? Relying on technology in this way never works.
You can track Bugzilla Tracking, or you can subscribe to the email list, but I’d do so warily—it is going to get busy.
The IE Blog recently posted a guide to the W3C process of taking HTML5 to Last Call (LC). The writing included a call to those not currently involved in the W3C HTML Working Group (WG) to review the HTML5 specification and file bugs and LC comments.
The HTML WG has good representation from the browser companies, other major vendors, and the accessibility community. However, the participation from web developers, designers, and smaller tool and utility builders is a little sparse (and further representation from vendors, browser developers, and those working with accessibility issues would always be welcome). Since HTML isn’t just a browser specification, and impacts on more than just Firefox, Chrome, IE, Opera, and Safari, it’s important all groups evaluate the HTML5 specification—to ensure that all web community interests are represented in the final effort.
I join with the IE Blog team in recommending that everyone take some time to review HTML5. However, I also realize that the HTML5 specification isn’t a document for the faint of heart, or those short of time. In order to encourage wider review, I’m posting this as a guide through the labyrinth of processing algorithms, new elements, and cat-featured examples that we know as HTML5. First, though, I want to expand on the HTML WG Last Call process introduced in the IE Blog post.