Tag: WhatWG

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

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

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 skullduggery, disdained, mocked 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?