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.

HTML5 Standards

Strategic designs in a strategy-less environment

Still no updates on my issues at the W3C HTML WG, but the co-chairs did decide on the fate of longdesc, the focus of another issue:

the HTML Working Group hereby adopts the Change Proposal to not include the longdesc attribute in the language. Of the three Change Proposals before us, this one has drawn the weaker objections.

This is a highly controversial decision, not the least of which because the HTML WG Accessibility Task Force had recommended longdesc be kept, and the HTML WG co-chairs have disregarded the recommendations of its own task force. In addition, other standards documents in the W3C, as well as elsewhere, not only recommend longdesc use, but also mandate its use (if appropriate) if a site is to conform to law.

The argument for dropping support for longdesc I found to be most disconcerting is the following:

The weakest proposal was the one that makes longdesc conforming but with a warning. The primary rationale given for this proposal was that a few sites may be using longdesc properly. Many of the objections to both of the other proposals also apply to this one. Additionally, there was a strong argument which is unique to this proposal: if longdesc is conforming, user agents will be required to support it; if there is a validator warning, users will be discouraged from using it. This combination is the worst of all possibilities. Eliminating this proposal early made the process of coming to a resolution simpler.

The existence of implementations was found to be a weak argument for inclusion, the quantify of bad data was found to be weak argument against inclusion. External references (standards, laws, etc) was also found to be a weak argument for inclusion.

The strongest argument against inclusion was the lack of use cases that clearly and directly support this specific feature of the language. The fact that longdesc has little observable uptake amongst users reinforces this: all the evidence indicates that users don’t see this feature to be compelling, and the lack of user demand has been noticed by implementors.

This entire section is extremely confusing, for multiple reasons. The first is that the section is describing what happens when a component of a language is deprecated—a concept that has been successfully utilized in technology for as long I can remember. The whole purpose of deprecation is that an element that has been previously supported is no longer, suddenly, not supported. The sudden cessation of support of an element between two releases of a language, library, or API causes confusion, as well as potentially introducing a great deal of breakage as people advance their applications from the older language or library, to the new.

In a mature, thoughtfully designed language or library, what happens, instead, is that the element is supported in the next version of the language, but a warning is given about its use. The warning instructs the user that they may use the element this one last time, but support for the element will most likely be pulled in a future version of the language, or application. The warning should also inform the individual about the preferred approach to take in the future. The use of deprecation ensures that people can gracefully advance their applications to the new release, and still have time to modify existing uses of the previously supported elements.

So the fact that the one of the proposals recommended deprecating the element rather than just making it suddenly obsolete, was considered a weak argument leaves one to wonder: what could possibly be a strong argument?

Of course, one of the primary problems with deprecation in HTML5 is the fact that deprecation isn’t supported in HTML5. No, we now have the new concept of obsolete, but conforming. Whereby deprecation is long known to be a way of gracefully moving a people from the use of one component to another more preferred approach, obsolete but conforming seems to be a way of saying—well, frankly, I don’t know what it’s supposed to be saying. Something profound and extremely clever, I’m sure.

Another reason I found the earlier quote from the co-chair decision to be confusing is that the existence of external laws and standards requiring support for longdesc is also considered a weak argument.

In what world, my friends?

To disdain external standards, not to mention government mandates, is extremely arrogant and incredibly short sighted. It is as if the HTML WG is attempting to undermine the credibility of the W3C. I don’t believe this is the intent but is, instead, a by-product of the obsessive focus, in both the HTML WG and the WhatWG, on meeting the interests of only one group when it comes to determining what’s in HTML5: the browser companies. The so-called Implementers.

Though it is true the browser companies—Apple, Google, Opera, Microsoft, and Mozilla—need to be on board with whatever is released in HTML5, it should also be a given that the browser companies, themselves, should be interested in meeting the needs of their community of users—and this includes the accessibility community, in addition to web developers, designers, other tool builders, and so on.

The HTML WG co-chair decision was, frankly, poorly reasoned. That people will formally object is a given. That the formal objection will succeed is also a given because the W3C has no choice but to reject this decision. The W3C cannot afford to be so cavalier as to arrogantly pronounce itself above government and other organizational mandates. The browser companies may deem themselves to be above such consideration, but the W3C cannot be so short sighted, and thoughtless. The W3C also cannot possibly afford to undermine its own credibility by introducing conflicts between its own recommendations: to recommend longdesc in one of its documents, while, at the exact same time, making it obsolete in another. The whole point of deprecation is to prevent such anomalies from occurring.

Folly. Pure folly.


November is HTML5 Month

I’m not particularly good about compartmentalizing my interests. They say we women are good at multi-tasking, but I must be an exception to the rule.

I have sent off my first half of JavaScript Cookbook to my editor, and I hope to try to salvage an article I was doing for A List Apart, though I’ve run into some bandwidth issues that may be related to the technology covered. But my hope is to spend all of November working on HTML5: writing bugs, escalating bugs to issues, writing comments or change proposals, and, ultimately, going over every last bit of the HTML5 specification.

I can always sell my car to pay my bills.