Re: Sections of the HTML5 specification being removed from the W3C without discussion

On 9/9/2011 9:16 AM, Chris Baker wrote:
> Simply in the way of comment, this situation is quite dismaying. I 
> fear that the less organized and stable the working groups and the 
> process of maintaining and generating the spec becomes, the more apt 
> vendors are to become inconsistent in implementation; this will 
> directly result in fewer developers adopting any of the new spec in 
> the short term. Moreover, I think the participation of Microsoft in 
> the specification and adoption may potentially be one of the single 
> greatest boosts to innovation on the web - the hours and dollars 
> wasted on implementing cross-browser code can instead be spent on 
> forward development. If this process or the spec itself cannot be 
> organized, professional, orderly, and business-like, I fear vendors, 
> especially Microsoft, are going to see the incentive to play ball 
> diminish and we'll have another 10 years of continued dual- (or 
> tripple- or nightmare quadrupal-) development ahead of us to make this 
> stuff work in the various user agents. Taking ONLY that into 
> consideration, I view this entire specification and process as a 
> pivotal moment for the web as a whole, and to lose this initiative 
> means stagnation for years to come.

Calm your fears! <smile>.

Having followed vendors closely for the past 5 years, while I develop, I 
can tell you that things continue to work-out-well for browser 
interoperability.
Microsoft has been very supportive of the web standards, and continues 
to catch-up to the newer more powerful web-side specifications:
http://html5labs.interoperabilitybridges.com/

They continue to be the leader in ARIA support, with Mozilla a close second.
They're playing ball. Webkit and Opera are both, very much invested in 
w3c specs.

I've only seen a convergence, when it comes to these specifications, 
despite there being so may new specs on the table.

There have been instances where vendors do have to go-it-alone. I think 
that Apple-WebKit is a prime example.
These have not been particularly harmful, as vendors tend to catch-up. I 
believe the developers on all browser teams
are aiming more for convergence, than for forking. The majority of 
Apple's innovations have made it into the other UAs.

> I am loathe to make this comment; I am hardly highly-involved, I feel 
> like the peanut gallery. But I think I can say that I speak for a 
> significant number of developers when I implore, urge, beseech and beg 
> you as a group to take the necessary measures to pull this process 
> back together and give us something we can rely on. I'm game, I've 
> started putting the more stable elements of HTML5 out there on my 
> client pages, I'm teaching new developers about the newer spec and 
> encouraging adoption in any way I can. I look to the WHATWG *and* w3 
> to be the leaders here; we "field developers"" are literally at your 
> mercy. All the current momentum is not lost,  there's a workable 
> specification in all those documents with nothing less than the future 
> of the internet hanging in the balance - this is not melodramatic to 
> say. Your work is important, I appreciate all that has been done and 
> look forward to a return to order!

Let's examine balance:

Editors:

Tab Atkins:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1265.html
"The editor is the *lowest* level in the hierarchy of constituencies"

Ian Hickson:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1277.html
"As editors we must be willing to throw away efforts when it becomes 
clear that they are not the best solution for the Web"

http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0021.html
"make an API for these features that addresses the needs I listed ... 
and assuming that browsers would
be willing to support them, then there's no question that we'd add them 
to the spec."

Aryeh Gregor:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/030041.html
"Sometimes features get added without implementers' support, but don't 
rely on it.  If it gets implemented, on the other hand, you can be sure 
someone will want to spec it, so that interoperability doesn't suffer"
http://annevankesteren.nl/2011/07/editor
"my time is my own or my employer's, and no one else has any right to 
place demands on how I spend it... I simply do not agree that I have any 
moral obligation to let the W3C or anyone else tell me how to spend my 
time."

Vendors:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029133.html
"I have approximately zero faith in JS coders and HTML coders doing 
things 'right', after fairly extensive exposure to the results of their 
work... My faith in canvas coders is closer to 0.2 (on a 0-1 scale), 
largely because it's not quite as mainstream yet, so only the more 
competent folks are doing it."

http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0069.html
"A million developers doing a million different things will mostly do 
things wrong when the correct solution requires extra effort and doesn't 
have immediate visual or functional feedback telling you if it's working 
or broken."

http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0032.html
"a much better way to address the problem of canvas text editors not 
being accessible  ... is to discourage authors from building them in the 
first place."

http://lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/0039.html
"rather than trying to hack accessibility onto a feature so that it may 
be used for something it was never intended to do, you should detail the 
missing functionality that you want/need from the normal text editing 
machinery"

http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0080.html
"I've talked with several WebKit engineers here at Apple... the 
consensus is that adding retained-mode features to the Canvas API is not 
something we're interested in."

http://lists.w3.org/Archives/Public/public-html/2011Jun/0351.html
"Microsoft considers SVG to be the correct way to do retained mode graphics"

http://lists.w3.org/Archives/Public/public-html/2011Jun/0339.html
"Why is 'use SVG' not sufficient for this?"

Balance:

The balance is very-much on the side of big vendors. That's fine, they 
have the money, they invest in their browsers, and in some cases, the 
browsers are open source and we're able to submit patches. With a 
project like WebKit, I know that I could invest into a proposal, submit 
it for webkit review, and from there, likely into a specification. 
Currently, none of the big boys are making Canvas applications. Google 
has their sketching program in docs, written for SVG targets. Microsoft 
barely uses Canvas, though they are at least interested in accessibility 
on its own means. Apple lives in its OS stack, they define the language 
and the accessibility. They recommend coding in Objective-C. ;-)

The reason I bring that up: vendor priorities are very much driving 
these processes. Google's decision to enter into the browser market is a 
primary force for them to enhance their own service offerings. By 
rapidly introducing APIs which suite Google products, they are able to 
cut costs, and increase the attractiveness of their services. If a 
service has a need, lets say Gmail needs better support for file 
attachments, Google has a browser, a hook into WebKit upstream, and 
several people working on W3C specs. They get what they want. If Apple 
has a need, well they just add it into their browser and let the specs 
catch up later.

We can't do that as developers. Now that the Web Apps have reasonably 
caught up to traditional desktop technologies, there are hundreds, 
perhaps thousands, of independent companies creating their own 
client-side web applications; desktop development-style. This is a power 
shift in itself. Where traditional development has been 
document-centric, with little pairings of interactivity,  web 
application development is tool-oriented; it's about creating a consumer 
of documents, instead of creating documents. It's about creating user 
agents inside of the browser, user agents that process documents. A 
document may be viewed for minutes, and then the next document is 
brought up. A user agent may be open for hours, as the user moves 
through multiple documents. Web application developers are creating user 
agents inside of the browser, as they support whatever processes their 
product is intended to. This is in conflict with the notion that the 
browser vendor should be the only user agent present. When this conflict 
is internal to a company, it gets resolved. When it's external, we have 
a really bad situation.

Look at IBM, there's a vendor that did not jump into the browser fray. 
Now they have an issue:
"the first time I mentioned canvas to an IBM product team the first word 
out of their mouth was: 'Cool, we can create a new custom UI on the 
existing standard controls!'".

Though they have contributed to the w3c, to Webkit and to Mozilla, they 
are in a bit of a bind on meeting WCAG levels. If they had done what 
Google had done, and put weight as a browser vendor, they could just do 
what Google does, what Apple does, and add in the methods they need to 
meet their business requirements. Instead, they have to sit and wait. 
Because, they are developers, not browser vendors.

Browser vendors maintain the utmost control in this process. They are 
aware of that control, and they are using it to their advantage. And 
that's perfectly reasonable. But, they can use that control in a manner 
that is anti-competitive. In a manner that says to developers: "sure, 
you spent hundreds of thousands, perhaps millions, in authoring. Go 
ahead and rewrite all of that... it doesn't fit within our idea of 
correctness." In point of fact, it doesn't fit within their current 
product offerings and internal procedures. That's the issue. It benefits 
them to block such innovations, as a tactical business advantage.

Let's go back to Mozilla: they now have an offering, a PDF viewer 
written in JS, which acts as a user agent within a user agent. Now, 
unlike last year, and the year prior (remember bespin), that behemoth 
has a reason to look into developer issues again. Should Google, should 
Apple, find that they too want to write a user agent, perhaps to 
re-write a PDF viewer in JS, they too will change their tone. When they 
need to meet federal standards for accessibility, and they find that 
their APIs are insufficient, it will no longer be a protracted argument 
about the merits and correctness of things. They'll simply add the APIs, 
and that will be that.

Many of these spec editors are employed by very self-interested 
corporations. And in free market style, things are, mostly, working out 
for all of us.

The W3C is, I believe, intended to assist the members that do not 
develop their own browser implementations, to assist them in working 
with members that do. That is where I would like to see attention, in 
this unfortunate power struggle.

Work on accessibility is blocked continually, in large part, by Apple 
and by Google, who have little interest in maintaining compatibility 
with Windows, or with old applications, or with third party assistive 
technology. Little interest. When we work on the lists, this is 
relegated to issues of "correctness". The issue, really, is of 
relevance. The W3C should maintain relevance of its members and of 
developers; it continues cede that power to browser vendors; those 
vendors are manned by business savvy folk who realize that obstruction 
can be a tactical advantage in business.

TLDR; Vendors have discovered that forking is expensive, a bad business 
choice. Hurray. They've also discovered that selective inclusion and 
obstruction is rather cost effective, giving them competitive 
advantages. A great business choice. That, unfortunately, hurts 
developers, ranging in size from megaliths such as IBM, to non-members 
such as Wacom, and individual developers, such as myself.


-Charles