HTML5 Specs

HTML5 implementation experience

I disappointed folks with a recent email to the W3C HTML5 co-chairs, offering to withdraw my change proposals. The co-chairs nixed the idea, which is OK, but also have not provided a decision on these items yet. The unfortunate consequence of the new Decision Process is that the co-chairs have become the group bottleneck.

I do genuinely believe that after recent discussions related to figure and aside that the existence, or not, of details, aside, figure, progress, meter, and the hidden attribute (not to mention a dozen or so other elements), should be decided after people have a chance to play with a couple of implementations. I am relatively confident we’ll find that the implementation of the elements will drive home the points I attempted to make in my change proposals. It is easy to say, “Oh, we want these because they’re useful and accessible”. It’s another thing to actually make them useful, and accessible.

That is the problem with the current HTML5 specification. Some of the items are implemented, such as Canvas, audio, and video. In fact, the browser companies have tripped over their own feet in a rush to implement audio and video.

Other, shall we say, “less sexy”, elements have not been implemented, including most of the form input element types that actually formed the basis for the beginning work on HTML5, six years ago. Opera has done some implementation of form input types, and Webkit now supports progress and meter, but Firefox hasn’t started on these items, and neither has IE.

However, it is these “less sexy” elements that need implementation experience more than the cool items, because it is these that are more vaguely defined and introduce concepts into HTML that have the potential for negative repercussions.

Take figure, a seemingly innocent element. It started life as nothing more than a way to add a image caption, and now it compromises anything with a caption. Yes, this is semantically incorrect, if we’re following print semantics, but the HTML5 world marches to its own semantic drum.

Now the question becomes, in what way do we associate the caption to specific elements within the figure? For one, does it replace the alt text in the img elements? If we have a table in the figure element, which is allowed, can we use a caption for it, and the figure caption, too?

Supposedly figure can be located separately in the page or in a separate page, and is somehow associated with the content. How? Do we link the two? Do we have to use some form of magic pixel dust? There’s a gap in understanding between just writing in a spec that the figure is associated with its context but may not be physically located with the context, and the actual implementation. This has not arisen in the past, because previous elements are defined within the context of their containing elements, not some vague assurance of association by proxy somewhere in the web.

Figures in books and other printed material are linked by reference. We use in the text, “See Figure 1-a”, and the reader knows to look further in the book for Figure 1-a, or to check out the image in a special figures section. We have implementation experience, so to speak, with “figure” in the print world. We don’t in the web world. We’ve never really needed it, because we have a thing called a hypertext link that works marvelously well when it comes to associating one piece of content with another.

As for the “semantics” of figure—when anything is allowed in the figure element, there is very little meaning to the element, other than it being “something with a caption”. Actual implementation experience drives home this point, because if figure is anything with a caption, what use is it for something such as a search engine? If we returned to the original concept of figure, though, where it was a way to associate a caption with one image, many of the problems associated with the implementation of figure fall away. We can easily see Google pulling the image and associating the correct text with it in its images search page.

But then someone, somewhere, will dig through web pages until they find one example where someone associated the use of “Figure” with code or a table, or even a poem, and they’ll bring this up as a use case, with tut tuts of how can we prevent people from being free to use figure however they want—totally disregarding the whole meaningful part of semantics—and figure gets redefined and broadened, again and again, until we have something with a caption.

Maybe this is OK with the world. But we’re not going to know, until we actually try to implement it.

The same with the details element. Even now, there’s a bug on what component of this element gets focus—the element itself, or the summary label. There’s nothing in the spec that makes the element keyboard accessible, though. There’s little in the spec that talks about whether the user agents allow readers to control what are known as declarative animations: animations, such as the exposure or or not of the display contents based on a some action, that come about via the HTML markup rather than JavaScript. Readers can turn off JavaScript, they can turn off Flash, but there is no way to turn off declarative animations, and not every reader would probably understand exactly what a declarative animation is, anyway.

There are components of declarative animations in use today. Dropdown selection lists are another example of declarative animations, and we certainly don’t want to remove this. Then, we might be asked, if we want to keep declarative animations for some web components, why not add this type of behavior for others?

The reason why is that in the last ten years, we have had details-like collapsible page and menu sections, controlled with CSS and JavaScript. We’re used to these, and we’re used to them being controlled by JavaScript and CSS. We know that when JS is turned off, these items should be expanded by default. We make use of this for our print pages, which disable JavaScript, leaving the items expanded, and therefore printed.

This isn’t going to work with details, though it may seemingly look exactly like the JavaScript controlled elements. The details element works against expectations.

Again, maybe the benefit of the element will outweigh the disadvantages, but we’re not going to really know for sure, until we actually see a couple of implementations. We can’t compare what this element provides against the state of the art today while the element is still nothing more than an abstract.

Webkit has implemented progress and meter, and I talked about progress recently. The elements can’t, for the most part, be styled: what you see is what you get. In addition, the new meter element actually uses color to denote the element’s current value as compared to its optimum value. Doesn’t look like a gauge, which is what a meter is supposed to be—not like we’re used to with JavaScript libraries. And we don’t know what other implementations will look like with other browser companies. Or across different operating systems.

Even something as simple as an aside element can be complicated to implement. Consider that most of these elements have to be mapped to existing accessibility APIs, how does one map aside to, say, ARIA roles? Originally, it could have mapped to the ARIA note role, which is used with content in a main document that can skipped and returned to later. However, because people grasped the reference to “sidebar” when this term was used to define the element (but based on print sidebar, not web sidebar), we can now use aside for web sidebars, too. However, the ARIA “note” role is no longer applicable. In ARIA, sidebar content would be marked with a complementary role. In order to make aside accessible when it’s used as a sidebar, we have to override the semantics by assigning it an ARIA role of “complementary”. Or if it gets mapped to ARIA role of “complementary” by default, then we have to override the semantics of the item, setting it to “note” if used as a content note. Which then begs the question, What the heck use is the item when we can just use the ARIA roles now, and not have to worry about which to use when?

In other words, rather than provide cleaner semantics, aside actually makes things worse. But it’s only when you start implementing the thing that details such as this start to appear, making the element a whole lot less attractive.

The problem, though, when you wait to challenge an element or attribute until after it’s had a couple of implementations is that people assume the thing is real, and going forward. People become extremely reluctant to let something go after they’ve spent time on it. It’s a catch 22 situation, made worse because of the hype about HTML5, and the contentiousness in the HTML5 working groups.

By filing the change proposals to remove these items before implementation, I know people haven’t started using the elements in their web pages. However, the downside to filing before implementation is we’re talking about removing abstract elements, and the costs of the elements aren’t necessarily going to be apparent until we actually try to work out the physical implementations.

Once the items are implemented and in the HTML5 spec, if we decide later we made a mistake with them, it will take years, perhaps decades to remove them. Look how long it took just to eliminate blink? And I imagine at one time, even the blink element made an attractive sounding abstract element.

All of which brings me back to the offer I made yesterday: pull the change proposals now, with the understanding that we could re-visit these elements again when we’ve had implementation experience, and with the understanding that these elements could still be removed if the implementations demonstrate problems. By writing this email, though, I disappointed some folks.

I do apologize for suddenly springing this offer on folks, but I’m not going to apologize for the action. If the co-chairs do agree with any of my proposals, those who proposed keeping the items will not be happy and will, most likely object, at length and loudly. Why wouldn’t they? Right now, these elements are marvelous inventions of semantic goodness, and accessible to boot.

If the co-chairs don’t agree with my proposals, which frankly, I feel is the most likely outcome, then after we have some implementation experience with the elements, we could supposedly bring up the idea of removing some or all of elements if we run into significant problems with their implementations. If, that is, we can convince the co-chairs that “new information” has occurred to justify bringing up the issues again.

But by that time, the co-chairs will have “confirmed by decree” that we ware keeping the elements, people are assuming that these elements will be in the final release of HTML5, time will have been invested in the elements, and it would be the devil’s own work just to get people to consider the possibility that maybe, the elements are less than useful.

I do not claim to know if I’m right about these elements, or those who disagree with me are wrong. I believe I’m right, I’ve tried to demonstrate why I believe I’m right, but I know that doesn’t make me right. And I don’t know if filing the change proposals now was a mistake, the offer yesterday was a mistake, or a combination of both was a mistake—or not.

Regardless, what’s done is done.


Thousands impacted

The impact of the BP oil spill is only now being felt, and yet we have demands from the oil industry and Britain, not only to “lay off” our criticism of BP (because British pensioners could supposedly starve to death if we don’t), but to allow any and all new drilling (because Louisiana residents will supposedly starve to death if we don’t).

We are facing the prospect of the death of the Gulf, the destruction of entire species of animals, as well as the utter devastation of a way of life for many people in the Gulf, because we can’t take a moment to ponder these events without immediately demanding that we proceed, business as usual.

The state and federal governments could be using these events as a way to face the harm that our dependence on oil is causing us. They don’t though. They can’t even stop new oil wells from being drilled in shallow water, completely forgetting that more oils spills occur in shallow water operations than those in deeper water, such as the Deepwater Horizon. We mustn’t take time to understand how such a profound breakdown in safety can occur with one oil well, in order to ensure it doesn’t happen again. No, to do so would cost somebody somewhere, and our current crop of leaders—across both parties—doesn’t have the balls to take a stand if doing so might cost a vote.

What is the true cost of the current oil moratorium? Is it the Gulf’s fault that the British pension systems are too heavily invested in one company? A good pension is one that has a diversity of investments, just for contingencies such as this. And frankly, would the British people feel so sanguine if the oil spill were happening in their backyard?

As for those “thousands” of Louisiana residents facing unemployment because we’re not allowing new drilling—what employees? These wells haven’t even begun yet. We’re not stopping the existing platforms. We’re not forcing people currently employed in oil platforms out of work.

And what about the employees in Alabama, Mississippi and Florida that are dependent on tourism? Do they not matter? Or is Louisiana, frankly, playing a Katrina card in order to garner sympathy? Doing so rings hollow, because the oil spill is dumping one environmental disaster on another—if Louisiana politicians are really concerned about the state’s way of life and welfare of the people, they would be in the forefront of demanding the oil moratorium. Instead they call for increased oil drilling out one side of their mouth, while condemning the federal government for not doing enough to protect against oil spills, out the other. I can understand the hypocrisy of the Louisiana politicians; I just can’t understand why they continue to think we’re so stupid as to not see it.

Louisiana unemployment? Ask Michigan about dealing with unemployment. Ask Missouri. California. We are all facing deep problems with unemployment. Unemployment that, ironically, could actually be helped by the oil spill. Why? Because increasing the cost of oil increases the cost of transportation, and eventually those companies that moved their manufacturing overseas may see profits eaten up by transportation, and move the jobs back here.

I could wish our leaders would stand firm on this moratorium—even extend it to not allowing any new offshore oil drilling, period— but I have faint hope that any resolve will last beyond next Fall’s elections.

HTML5 Specs

Apple, Opera, and Mozilla: Why are you working against open standards?

I have a question for Mozilla, Opera, and Apple: why are you working against open standards?

Why do you still support an organization, known as the WhatWG, that has proven itself to be detrimental to an open and inclusive specification development effort?

Recently I wrote about a kerfuffle that happened within the HTML WG, when the editor, Ian Hickson, decided to insert snarky material in the WhatWG version of the HTML5 spec, and then point the W3C version to this snarky material. The material has since been removed but the problem still remains, because we still have two versions of HTML5. We still have confusion about which one is official. We still have divisive discussions, consisting of parties of them and us, rather than one group working on one document.

Two versions of HTML5—has there ever been anything more absurd? They’re not the same, either. When the W3C HTML WG makes a decision about changing the HTML5 specification, the WhatWG copy doesn’t reflect this change. And the HTML5 editor adds all sorts of unproven and controversial stuff to the WhatWG version of the document, but still pretends that it is an “official” copy of the specification. Excuse me, official future versionless version of HTML5, which only implies that you all plan on continuing this debacle into the future.

When web communities outside of the picked handful of browser implementers protest, we’re called names, accused of whining and various forms of skullduggerydisdainedmocked and made fun of, and generally, it seems to me that you three companies are forgetting one inescapable fact: we’re your customers. Yeah, sucks, doesn’t it?

Why does the WhatWG still exist? You have long had your way when it comes to HTML5. The W3C dropped work on XHTML2, and started work on HTML5; browser companies control two of the three co-chair seats; the implementers are given precedence when it comes to what’s in the document…I mean, what more do you need? Gold stars by your names? A lollipop?

If you’re expecting us to meekly allow one person to have absolute control over what’s in HTML5, forget it. There’s not a development team in the world that would give one individual the control you seem willing to give to the HTML5 editor.

You can’t blame this state of affairs on Microsoft, because it is actually operating solely within the W3C. The same as Google, though Google does employ the HTML5 editor. No, your three companies are on the so-called document copyright. You have claimed ownership of the WhatWG. You are the WhatWG.

So why don’t you stop? Why don’t you see the damage you’re causing by turning a blind eye to what’s happening in the WhatWG name? I would rather you do this then spend time, one upping each other by implementing one more cool, non-standard innovation in your products.

I know all three of your companies have good people who have done much for HTML5, and we do appreciate it. All three of you have people who are just as unhappy about the state of affairs regarding WhatWG. But the good stuff they do is frequently outweighed by the bad, when we have to once against stop moving forward because of WhatWG/W3C conflict.

Getting cool stuff is no longer enough. You see, we’ve grown up. We like cool, but we want solid performance and some sense of stability. We definitely only want one version of HTML5. So, Apple, Opera, Mozilla: why don’t you grow up, too?


The W3C bites back?

Recovered from the Wayback Machine.

This has been a long time coming, and not sure where it will go. It started innocuously enough: remove a paragraph associated with the alt attribute, about user agents using some form of heuristics to determine replacement text. It wasn’t associated with a bug—it predated the current decision process. It did have an issue, though, Issue 66.

Consensus was: remove the text. Simple, easy, and absolutely no impact on HTML5.


Except that Ian Hickson decided to do a little editorializing:

The latest stable version of the editor’s draft of this specification is always available on the W3C CVS server and in the WHATWG Subversion repository. The latest editor’s working copy (which may contain unfinished text in the process of being prepared) contains the latest draft text of this specification (amongst others). For more details, please see the WHATWG FAQ.” — <>, “Status of this document”.

And what does the WhatWG document now contain?

The W3C has also been working on HTML in conjunction with the WHATWG; at the W3C, this document has been split into several parts, and the occasional informative paragraph or example has been removed for technical or editorial reasons. For all intents and purposes, however, the W3C HTML specifications and this specification are equivalent (and they are in fact all generated from the same source document). The minor differences are:

  • Instead of this section, the W3C version has a different paragraph explaining the difference between the W3C and WHATWG versions of HTML.
  • The W3C version refers to the technology as HTML5, rather than just HTML.
  • Examples that use features from HTML5 are not present in the W3C version since the W3C version is published as HTML4 due to W3C publication policies.
  • The W3C version includes a redundant and inconsistent reference to the WCAG document.
  • The W3C version omits a paragraph of implementation advice for political reasons.

So the W3C specification contains a link to the WhatWG document, which contains a rather inflammatory statement, prompting Sam Ruby, the HTML5 WG co-chair, to write:

To have the W3C specification refer readers to another specification for an exact list of differences, and to have that other specification indicate that the omission was due to political reasons is intolerable.

Earlier this afternoon, I filed a Formal Objection against publication of the HTML5 heartbeat documentation, until all references to the WhatWG version of the specification, and the WhatWG mailing list, are removed from the W3C document. That this state has continued for so long is unconscionable. What, on earth, was the W3C thinking?

I was pleased to see that two of the HTML5 co-chairs, Paul Cotton and Sam Ruby, have stopped the heartbeat publication of the HTML5 specification, until the offending material is withdrawn. This effort was not prompted by my Formal Objection—the chairs are reacting to the editorial changes.

Even now, the HTML5 editor, Ian Hickson, is demanding an accounting of decisions that satisfy him. I wonder how many fan boys will rush to provide him support, or whether the browser companies finally start to realize that he is more wall, than doorway.

Regardless, if you’re thinking that the WhatWG will pull out of the HTML5 effort, and doom it by their lack of participation, think again: the WhatWG organization is not a legal entity. It is an informal group of a handful of individuals, half of whom became disillusioned with the effort years ago and have not participated since.

The group does not have a patent policy, so there is no way possible that Apple would allow something such as Canvas to be managed under the auspices of the WhatWG. The group can’t even support a copyright license, because there is no legal entity to act as holder of copyright. Not unless you count the person who provides the WhatWG server, who restarts the WhatWG server when it’s down, and who has complete editorial control over the WhatWG HTML5 document: Ian Hickson. And I don’t think even Google could tolerate handing that much power over to one, single individual.

The W3C is also not a legal entity BUT…members of the W3C organizations have to enter into a contract and agreement with the three legal entities behind the W3C: MIT, ERCIM, and Keio University. Though frequently contentious, and overly bureaucratic at times, the W3C effort is the only effort where people other than Ian Hickson may have a say about what is, or is not, in the HTML5 specification. Just as important, the W3C provides the legal stability that allows all of the browser companies to freely, and safely, participate.


My SVG progress bar

In honor of Microsoft supporting SVG in IE9, Web Directions is hosting an application contest: create your best and most innovative progress element using SVG. Microsoft is providing the prizes, and they’re nice: a new laptop, XBox, and Lego Mindstorms kit. Tasty.

I was inspired to create my own SVG progress graphic applications, using a well known graphic that I borrowed from Wikipedia. I did the work for fun, and won’t be entering the contest. Why? For one, I don’t have a Windows machine that runs IE9 in order to test the application. For another, I’ve never been much of a contest type of person. Plus there’s that validation requirement: pretty tough when you combine SVG inline in XHTML5 with ARIA.

Note that you can access the page and the examples using any browser you want— including Safari. Either the applications work, or they don’t; I’m not going to stop you from trying them.