Category: Standards

Web and tech standards

Categories
HTML5 Specs W3C

Strategic decisions 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.

Categories
HTML5 Specs W3C

HTML5 Issue decisions

I did hear back from HTML5 co-chairs on my issues, and one of the decisions, on Issue 93, was just published.

No surprises, the decision was to keep the element. I’ll update this post with the status of the other issues as the decisions are published.

Issue 93:

Categories
HTML5 Media Specs

CNet story on HTML5

Stephen Shankland of CNet published an article, Growing pains afflict HTML5 standardization. He sent me an interview email and quoted a small portion of the response. I believe he quoted me fairly. However, I wanted to publish the entire interview, so you can see the material not included.

—begin interview—

> –What are Hickson’s shortcomings?

The issue is less about one individual’s shortcomings and more about a single individual given what amounts to dictatorial powers (a phrase Ian has himself used) about what is, or is not, in HTML5. Ian is a very capable person, but he believes that the best, quickest way to create a specification is if one person makes all the decisions about what is in a specification. Ian also has strong, rather inflexible, opinions about the future of the web, and the future of HTML. One person with such strong, inflexible opinions, and with virtually unlimited control over the HTML5 specification contents, is not a good thing.

Ian also has had little exposure to web communities outside of the browser developer community. In fact, he believes that the Implementers, as he calls them, should have final say in all aspects of HTML5. Yet there are groups of people–web developers and designers, tool and application builders, folks concerned about accessibility, eBook creators and authors, and so on–just as impacted by what happens to HTML5 as the browser developers. Many from these communities have had to fight, sometimes for years, to add even the simplest modification to the HTML5 specification.

The situation is made worse because there are two versions of the HTML5 specification: the one at the W3C, which I think of as the official version, and a “shadow” version at the WhatWG. If Ian’s opinion is overridden in the W3C HTML Working Group, he’ll reluctantly make the change in the W3C version of the specification, but leave the text unchanged in the WhatWG version.

The existence of both documents confuses the web community about which document _is_ the HTML5 specification. When the specifications were the same, this wasn’t as much of a problem. Now that there are several significant differences between the specs, though, the existence of both is a very serious issue.

> –What’s the best way to rectify the situation?

In my opinion, the HTML5 specification would be vastly improved if there were a small team of experienced specification editors, rather than one single person given such unlimited control. I’m not sure, though, if Ian would be willing to work with a team, or to give up any editorial control in the specification. He may choose to quit, instead.

There was also an early Working Group decision to give both Ian and another person editing powers over the HTML5 specification, and this earlier decision has been used as a barricade against the idea of bringing in new editors. However, the other individual who was once involved with HTML5, quit sometime ago. His quitting should have opened the door to adding new editors.

You’re a writer. You know how important it is to have others review your material—to catch typos or fix awkward or confusing phrases; to question assumptions you’ve made, or whether your opinion may be overly influencing how you perceive an event.

This type of collaboration is just as important in a specification. More so, because the fewer people with actual authoring capability in the specification, the more likely personal bias has undue influence, and the fewer needs of the community are met.

> –Is there still a role for the WHATWG? If it were to disappear tomorrow, what would happen to HTML5 development?

The WhatWG is an unusual group. It gives the appearance of being egalitarian because anyone can subscribe to the WhatWG email list and make suggestions about the WhatWG documents. However, actual membership in the WhatWG was by invitation, and includes a small handful of people, some of whom have quit working with the WhatWG years ago. Yes, anyone in the WhatWG email lists can make a suggestion, but only if they manage to convince Ian of the worth of the modification does it get incorporated into to the specification.

Ian can supposedly be overridden by the small, closed group of actual WhatWG members, but again: many of this group have quit working with the WhatWG, and the rest, well, their interests aren’t necessarily the same interests of many in the web community.

At this time, I believe that the existence of the WhatWG does more harm than good. Its existence has fractured the community interested in HTML5, leading to the contentiousness that has dogged the HTML5 effort. The existence of duplicate documents in both the W3C and the WhatWG confuses the web community. That the WhatWG documents now differ from the W3C documents, further exacerbates the problem.

If the WhatWG were to disappear tomorrow, work on the HTML5 specification would continue. I believe that, after the initial shake up, work would progress on the HTML5 specification more rapidly. If there is only one group of people working on the HTML5 specification, and only one document, people would have to work through their differences. There wouldn’t be an ‘escape route’ for a subset of the people, and there would no longer be “the WhatWG” folks, and the “W3C folks”. It would be just people, working on HTML5.

> –Has the W3C truly shouldered the burden of HTML5 standardization?

In my opinion, once references to the WhatWG email lists, documents, issues database, FAQ, and so on are removed from the W3C HTML5 specification, and the W3C truly accepts ownership of the specification, then the organization will have fully shouldered the burden of HTML5 standardization.

> –What are some specific examples of HTML features that you felt Hickson handled poorly?

First, I want to mention some of the HTML5 features I believe Ian has handled well in the spec. He worked to standardize the browser object model, to develop audio and video elements that can support multiple codecs, incorporated SVG and MathML into HTML, helped clarify some items left ambiguous in HTML4, and a host of other good work.

The thing is, though, Ian agreed with most of these items. When he agrees with you, he can be very efficient. Even if he disagrees with you, but he personally likes and respects you, he’ll be more amenable to listening to your feedback.

However, if he doesn’t agree with you, and you’re not part of the group with which he surrounds himself, he can be extremely obstinate about modifying the HTML5 specification. To the point of absurdity at times.

Case in point is how Microdata came about. A couple of years back, the RDFa community wanted to incorporate modifications into HTML5 so that RDFa could be used in HTML, as well as XHTML. We were asked to provide use cases, and we did; a significant number of use cases, probably more than has been provided for any other aspect of HTML5.

Ian responded to the use cases and requirements not by agreeing, and adding support for RDfa; not by saying no, RDFa shouldn’t be incorporated directly into the HTML5 specification. What he did, instead, was invent an entirely new way of handling inline metadata called Microdata. He had added Microdata to the HTML5 specification without once counter-proposing it as an alternative, and without _any_ discussion within the community (WhatWG or W3C). Ian didn’t like RDFa, therefore Ian created something new.

Eventually the RDFa community realized that incorporating RDFa directly into the HTML5 was unnecessary and added to what is an overly large document. A member of the community, Manu Sporny, created a separate document that discusses how to incorporate RDFa into HTML5, which is on a separate publication track.

Several folks in the W3C HTML WG suggested that Microdata also isn’t an essential component of the HTML5 specification, and should be split into a separate document. Not eliminated, just split off. Ian disagreed.

Eventually we ended up having to go to a poll and get a co-chair decision to split Microdata into a separate specification. However, if you look at the WhatWG version of the HTML5 document, Microdata is still incorporated.

This is an example of a major change in the spec that was not handled well by Ian, and is still not being handled well by Ian.

Another instance of an HTML feature I felt has been handled extremely poorly is a single attribute that has been under discussion for over three years: the table summary attribute.

The table summary attribute is a way for people to provide a helpful description of a complex HTML table so that those people using assistive devices, such as screen readers, could better understand how to navigate through the table. It is optional, and should only be used with complex tables.

Ian felt that the attribute was used incorrectly, and therefore he deprecated it (or, in HTML5 terms, made it “obsolete but conforming”). Many in the accessibility community protested because, in their opinion, there is no other way to incorporate this useful information so that it would be available to those using screen readers or screen magnifiers, without it also being exposed to those not using these devices (and who didn’t need this information, because they could actually see the table).

Instead, Ian added a convoluted section to the table element that describes numerous ways that people could incorporate text into their content so that this information is provided without having to use the summary attribute, because, in Ian’s opinion, the summary attribute has not been used correctly and is therefore harmful. However, it is not within the scope of the HTML specification to tell people what they should use in text surrounding HTML tables. It is also not within the scope of the HTML specification to tell people how to use elements, if such usage isn’t coached in such a way that the usage is a requirement for validity. An HTML specification is not a user guide.

For three years the debate on this simple little attribute has been ongoing without resolution. It’s still a pending issue in the W3C issues database. It’s still waiting resolution.

Three years. One single attribute. Tell me something: wouldn’t a reasonable person decide at some point that perhaps if the accessibility community really wants this item so badly, that it should be kept in the HTML5 specification as a valid, conforming attribute? With an understanding that the accessibility community then has an obligation to ensure it’s used correctly in the future?

At what point in time in three years did this item go beyond reason?

> Sorry, one more–since I’m not a technical expert, could you try to boil down the hidden attribute technology issue?

The hidden attribute originated as an attribute named irrelevant. It was created as a way to mark “irrelevant” web page elements that are not meant to be displayed by the user agents. Why not displayed? Because when the element is marked with the irrelevant attribute, it’s not relevant at that time. It was renamed to hidden because a) people were confused at the irrelevant concept, and b) many people can’t spell the word.

The hidden attribute functions exactly the same as setting the CSS display property to “none” for an element. Whatever element is so marked is removed from the page flow, and is not rendered by any user agent (browser, screen reader, or otherwise). To display the element, you have to use JavaScript, just as you do with the CSS display property.

Where the hidden attribute supposedly differs from the CSS display property is that there is “semantics” associated with the hidden attribute, not associated with the CSS display property. The hidden attribute marks “irrelevant material”. Yet what is irrelevant about page content that is still active? According to the spec:

“Elements in a section hidden by the hidden attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes.”

Truly irrelevant page contents should be created and added to the web page when needed, and removed from the page when no longer needed. That’s the way you handle “irrelevant page contents”.

In effect, there are no semantics associated with the hidden attribute. Its use is purely for presentational purposes. And since we decided long ago that we’re not going to tightly integrate presentation with structure in HTML, not only is hidden redundant, its existence is counter to 15 years of hard work to eliminate such tight integration.

–end of interview

I don’t necessarily agree with Shankland that the issues are minor. I also don’t agree with anyone who says that the browser companies are the only parties that matter when it comes to HTML.

True, the browser companies can be a major roadblock if they decide not to implement a feature. At the same time, though, it’s essential to take into consideration the needs of the entire web community, not just the browser companies.

The current HTML5 situation is little different than an IT group in a company telling the end users that they, the IT group, will decide what gets implemented and when, and the users should just shut up, and be happy to get what they get.

Categories
HTML5 Specs W3C

Next steps

Sam Ruby’s take on the CNet HTML5 article:

Balanced piece that neither sweeps under the rug nor sensationalizes the differences that we are working through.

To me, this is the same as saying, “Nothing to see here folks. Just be sure to step over the dead body on your way out.”

I still have not had resolution on several issues, and have not yet received a response from the W3C HTML WG co-chairs when I asked for a status of when I may expect resolution.

I believe most of my change proposals will not be successful, except perhaps Issue 89, on removing the idioms section, and Issue 100, on removing srcdoc: the former easily has no place in a HTML specification; the latter is just plain ugly as sin. Whatever the decision on any of these items, though, I won’t be formally objecting to the results. The most polite way I can express my feelings about the W3C at this moment is that it isn’t my happy place.

I also believe that the work on HTML5 will continue, but that the W3C will, more or less, allow Ian to do what he wants. I think there will continue to be two documents, and neither will be the same. I think these battles will happen, again and again, and there will never be a true resolution. I also think that the concept of a HTML standard has now been irreparably harmed— being redefined into being whatever the dominant browser companies want, regardless of other community interests.

However, I would love to be proven wrong. All across the board.

As for me, I’m focusing on my first self-published book, which is about HTML5. Whatever happens with the HTML5 spec, all I can do now is try to help folks make the best of it.

Categories
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.