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
