Category: Standards

Web and tech standards

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?

Categories
Specs

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…

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.” — <http://dev.w3.org/html5/spec/>, “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.

Categories
HTML5 Technology

Too much crap

I tried to find a web page to link in my last story, about the recent discussion surrounding Apple’s new HTML5 demo that deliberately prevents other browsers from accessing the examples. I finally had to link my own Twitter note about the problem, because every site that wrote about the issue had too much crap in their pages.

Don’t have to take my word, just search on “apple html5 demo blocks”, and you’ll find site after web site that covers the story, true, but the story is pushed down by headers that manage to link in half a dozen ads, and multiple Google links to boot. Or, just as you finally dig out the real stuff, some stupid overlay ad or “survey” hides everything, and you have to search for the little bitty close text, just to get rid of the damned thing.

Then there’s the Twitter tweets, and the Facebook notes, and the links to this application and that application; this widget and that. Are we afraid that people will think no one likes us if our web pages aren’t full of moving, annoying bits?

I watch my browser status bar as dozens of different domains have to be looked up, just to read one or two paragraphs of text. If my ISP’s DNS server is running slow, I never get to the stories.

I’m sure someone is making money from all of this. How much money are these sites really making, though, if after minutes of nothing, I hit the stop button and return to the searches to find a site that may actually provide the story, load relatively quickly, and not exhaust my DNS server in the process.

Folks have talked about wanting native semantics in HTML5 because they don’t want to have to load the big bad JavaScript frameworks, such as jQuery. “Give us date pickers and color pickers”, they say, “Because the JavaScript is too big! It hurts the web!” What’s absolutely absurd about all of this, is that the JavaScript framework libraries are probably the only thing in any of these sites that load quickly.

What Google, Yahoo, and Bing need to start printing in search results is how many domains will have to be looked up, how much external crap will have to be loaded, if we click that link. Frankly, I would find that much more helpful than a warning that the site could potentially be a source of malware. At least malware is a straightforward attack, which is better than this killing of our time waiting on these bloated, useless sites, where every ad company in the entire world has staked a claim, leaving tiny pieces of the page for actual, useful stuff.

Categories
HTML5

HTML 5 update

I’d provide another update on my HTML5 change proposals, but no co-chair decision has yet been published. There was a note in the last HTML WG teleconference minutes that decisions on three of the items, including two of mine, were ready to be published last Thursday, but nothing has appeared in the HTML WG email list.

As soon as the co-chairs publish the results for all six of my change proposals, I’ll post a note.

Regardless of decision, there is an indication, albeit on IRC, which makes it somewhat unreliable, that the browser companies will add the elements, whether they’re part of the HTML5 specification or not.

update

The HTML WG chairs have written up two decisions. I wasn’t expecting either to succeed, but was extremely disappointed in the weakness of the decision, and the fact that neither decision addressed anything that I brought up in either of my change proposals—the chairs focused purely on the objections to the proposal and counter-proposals, not to the proposals, themselves. (The author of the counter-proposals also noted that neither the proposal nor counter-proposal arguments were addressed in the decisions.)

You can read all the material yourselves, see what you think.

Removing the figure element:

Removing the aside element:

If you’re thinking that the chair decision regarding both change proposals are exactly the same, you’re correct. Sam Ruby duplicated the decision for both items, even though the change proposals were about two different elements.

That, and the fact that the decisions did not once address the concerns I raised, does open the door to formal objections. However, I have lost faith in the W3C. The organization has abrogated its responsibilities to all web communities, including web authors and developers. It is no longer the W3C of the 1990s.

Categories
HTML5 Specs

Progress Element: what I’ve found

To recap my weekend effort with the WebKit nightly implementation of the HTML5 progress element:

  • I created a application that uses the progress element and provides a text-based fallback for the element. You need to use setAttribute and getAttribute to get the progress element’s value attribute, as accessing the attribute directly on the object only works when progress is implemented in the browser. Apple’s VoiceOver seems to only audibly announce the state of the progress bar when it first receives focus. I can’t test with Firefox and NVDA on Windows, as Firefox has not yet implemented the element.
  • I created another application that provides a graphical progress bar fallback using two div elements. I also use ARIA to provide audible signals of progress bar state. During this experimentation, I found that you can’t change the background-color of the progress element, as this will wipe out the progress effect.
  • I created a third application, this time embedding the graphical progress bar fallback directly in the progress element. This approach works, but is invalid, since the progress element does not allow flow content. The assumption we take from the allowable content is that we’re supposed to accept a text-only progress bar fallback. This assumption of text-only fallback completely disregards the state of the art when it comes to progress bars that exists today.
  • I created a indeterminate progress bar application today. I discovered that you can’t change height or width of the progress element after all. If you do change the progress bar’s style setting, it adversely impacts on the indeterminate progress bar display. You have to accept the exact presentation of the progress bar, as determined by the browser. Frankly, I’ve never been overfond of the “blue gel” progress bar for Apple, and I think the progress bars, as implemented in WebKit, are ugly. Again, the indeterminate progress bar completely ignores the state of the art of “throbbers” that exists today. Can you see using this progress bar in Twitter?

I would move on to testing other new HTML5 elements, except for one small problem: the majority of new HTML5 elements have no real world implementation. Even many of the input elements, which have been around for six years have no implementation, or only partial implementation in one user agent, Opera.

As I wrote in an email to the HTML WG:

There are many new and modified elements in the HTML5 specification that do not have any implementation, and several that only have partial implementation by one User Agent. There are no implementations of any of the new or modified elements by any User Agent other than browsers (such as in authoring tools, or WYSIWYG plug-ins). Lack of implementation, or plans for implementation, especially when an element has been part of the WD for years, seems to meet the criteria for “features at risk”. Features at risk are those most likely to be challenged during Last Call, which could impede progress of the document through the Last Call process.

We get so caught up in the gee whiz newness of HTML5, and all its perceived glamor and sexy techiness that we forget that, for all intents and purposes, three-quarters of the specification is untried.