Burningbird Standards

The unbearable lightness of new

I’m still delighted with my new Linode VPS. I added one button backup to my plan, and that’s made all the difference in the world. Now, when I’m about to try something tricky, such as setting up a site firewall, I can make a snapshot backup first. Then, if my site gets toasted, I can restore a good copy with a click of a button. Lovely.

After five years I finally broke down a bought a new laptop, a Toshiba. Not only am I trying to find my way around a new machine, but also a new operating system. My current older computers are a PowerPC Mac, and an old Dell running Windows XP.

I saw the writing on the wall about getting a new machine when first, Google wouldn’t create Chrome for the PowerPC, then Microsoft released IE9, but only for Vista and up, and recently, neither Opera nor Firefox would continue supporting PowerPC. Plus, my keyboard is failing on the Mac—forcing me to pound the space key, then the comma, and now the C, V, B keys. You don’t how hard I had to type just to create that last sentence.

What I wasn’t expecting, though, is finding out that some of the open source software I use has not been ported to 64-bit Windows 7. I now have to consider what to use for editing photographs that won’t cost me more than my computer.

Speaking of new, Drupal 7 has released. As I wrote recently, I ported Just Shelley to Drupal 7, but I’m still not ready to port my other sites. My existing theme won’t work with Drupal 7, and I’m not sure if I want to port it, or just continue to use the default or other pre-defined themes. In addition, not all the modules I use have made their way over to Drupal 7.

My new site, Puppies @ Burningbird is based in Drupal 7. I’m happy about using Drupal 7, but less happy about having to create the site.

Unfortunately, bills have been introduced into both the Missouri Senate and the House of Representatives to repeal Proposition B, so the battle has begun anew. If you all like dogs and don’t like puppy mills, I hope you’ll stop by from time to time and leave an encouraging comment. I’m using Disqus to manage the comments, having enjoyed using the services at other sites. I figured if I end up turning off comment support, people still have their comments. Plus, Disqus provides some nice editing and other functionality. I may end up adding Disqus support to other of my sites, over time.

I’m also writing a new change proposal for the HTML5 Working Group. Yes, the more things change, the more they remain the same. I’ll post the proposal when I finish it. And I’m still working on books —no rest for the wicked.

Specs W3C

Responding to Opera’s TPAC Minutes

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.

HTML5 Specs

Opera’s TPAC Minutes

The annual TPAC meeting is when standards people involved with W3C specifications get together to see if they can more easily hammer out issue resolutions face to face, rather than in endless email discussions. I suppose we can liken the event to finally meeting that really hot person you connected up with on Facebook—it’s a big of a crap shoot whether anything useful comes of the meeting.

Opera was kind enough to provide company rep impressions of the different meetings, though the W3C is the only entity that can provide official reports.

Among the items I was glad to see was the decision—finally—to publish WebSQL as a Working Group (WG) Note. What that means, boys and girls, is that this spec is dead, and we can finally drop it from our list of HTML5 technologies. Of course it never was HTML5, but that’s beside the point.

The comment on Web Sockets doesn’t reflect the recent findings of security problems and browsers disabling support for Web Sockets. We can all learn from Web Sockets, and how the race to be first isn’t the same as the need to be best.

There was a discussion about redefining previously defined presentational elements such as <s>, <small>, and others as semantic elements. I was glad to see that this discussion happened, because it makes little sense to talk about backwards compatibility, and then redefine a presentational element for semantic use. However, no conclusions was reached, which I guess means that the group broke up and went off to have a beer.

Sometimes I think “semantics” is used as a sort of all purpose lubricant to stuff whatever some folks want into HTML5.

I was not happy seeing the following statement, about accessibility and HTML5:

The a11y Task Force made a list of user requirements (about 100). During the meeting Frank Olivier from Microsoft went through the requirements with the HTML WG and we organized them. It turns out about 10 of them are applicable to the HTML5 specification and are not addressed yet. The HTML WG Co-Chairs as well as the W3C Interaction Domain Lead put their foot down with respect to accessibility potentially delaying the HTML5 Last Call. It was made clear that HTML5 is time driven, not feature driven. So if the work on these requirements is not complete by May next year, it will not happen.

One area of major failing at the W3C is how accessibility has been handled. The W3C initiates working groups that create specifications such as Accessible Rich Internet Applications (ARIA), but even before this spec has a chance to be rolled out as a finished work, the W3C undercuts the work by demanding native implementation of most of the ARIA features in HTML5.

New semantic elements are added to HTML5 with the underlying reasoning being these are necessary for accessibility, but then the elements are not mapped to ARIA or to the accessibility API, leaving them basically worthless lumps of still not implemented technology—none of which can be styled, modified, customized, and few of which come anywhere close to what we have in existing JavaScript/ARIA/CSS implementations today.

The HTML5 Accessibility WG people seem to be spinning their wheels and dragging their feet, but the problem really is that the HTML5 editor keeps tweaking, adding, and removing things that impact on accessibility, forcing the group into a constant state of motion, just trying to stay in step with what’s going on.

The focus is on the “cool” stuff, like HTML5 video and captioning, at the expense of the more mundane, like alt, longdesc, table summary—yet the majority of web pages will never use any of the cool stuff, but will make use of the mundane. What makes this all even more fun is that because we don’t support that old thing deprecation in HTML5 working land, when something like longdesc is pulled, it’s just plain gone. End of story. It is now obsolete. There is no period where the attribute is deprecated, which not only would give folks a heads up about coming obsolescence of the attribute, but also provide an alternative for the attribute’s functionality.

However, seamless transitions are old fashioned—abrupt changes and disconnects are so much more hip.

The HTML5 co-chairs, rather than ensuring all voices are heard equally, have somehow managed to drive all useful discussion out of the HTML5 WG email list to bug reports, which has the advantage of being out of sight, out of mind. They’ve confused the Last Call commenting with bug reporting, encouraged outsiders to comment, but only if they become insiders for the group. They created a working group procedure that ties the working group up in procedures so that procedures are not discussed in the working group email list—which has now become an archive for bug reports, including some really cute ones that come in from the commenting form in the WhatWG HTML5 document, typically consisting of words like, This damn thing has broken my browser….FIX IT!!!!

So to participate in Last Call commenting you kind of have to become some kind of insider, though the whole purpose of Last Call commenting was to get comments from those outside the group…but hey, the majority of insiders in the HTML5 are outsiders, anyway, because the HTML5 WG co-chairs more or less just gives the HTML5 editor whatever he wants because, as we’ve come to find out, the HTML5 specification is being held hostage by a handful of browser vendors who really don’t give a damn what we need or want, because they’re too busy outdoing each other with cool stuff. Like Web Sockets.

Personally, I can’t wait for the official W3C reports on TPAC. Then I can really tell you what I think.

HTML5 Specs W3C

Correction to the HTML5 review procedure

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.

HTML5 Specs W3C

Review and comment on the W3C HTML5 specification

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.