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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Shelley Powers
There's an ongoing discussion[1] about removing the Editing API from the
HTML5 specification.

The issue is less that the section was removed, and more the fact that
the section was removed to a document OUTSIDE of the W3C. More
importantly, this change was not truly discussed within the HTML WG, and
I have reason to believe members of the HTML WG are not aware of this
change. Depending on the bug system as a way of informing WG members of
a significant change is a failure of the highest order.

Now, the same thing has happened again, but this time with the section
of the HTML5 document formerly labeled Dynamic Markup insertion[2]. I
don't believe there was even a bug report filed on this one, it was just
removed[3][4].

In looking at the change control entry, I also find a third document,
DOM Range[5]. One author identifies himself, the other uses a nickname,
rather than his real name.

Seriously?

Again, the issue is less that the items were removed, and more that the
items were removed unilaterally, and the new documents are placed
outside of the W3C.

My first question on all of this is: is the HTML WG even a viable entity
anymore? It doesn't seem that way. All the HTML WG is now is a listing
of bug entries and an occasional formal request from a co-chair. I have
seen other Working Groups, and there is little of what I would call
"working" about the HTML WG. Not anymore.

Secondly, is this the type of stewardship we can count on from the W3C
going forward? Allowing one specific company to pull chunks of W3C
specifications out of the W3C, without any consideration of other
company's intellectual property rights on the concepts in the text
covered in the text? More importantly, without regard for the possible
risk this may be placing companies who have started to implement these
specifications? These member companies have placed faith in the W3C. Was
this faith misplaced?

Perhaps rather than ask if the HTML WG is a viable entity, I should ask
whether the W3C is a viable entity. Actions like these described in this
email that are allowed to happen without hindrance or even comment  
casts doubt on the ability of the organization to continue being a
caretaker for the specifications that form the infrastructure for the web.

Shelley Powers

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13423
[2]
http://www.w3.org/TR/html5/apis-in-html-documents.html#dynamic-markup-insertion
[3] http://html5.org/specs/dom-parsing.html
[4] http://html5.org/tools/web-apps-tracker?from=6531&to=6532
[5] http://html5.org/specs/dom-range.html




Reply | Threaded
Open this post in threaded view
|

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

Charles Pritchard-2
On 9/8/2011 7:56 AM, Shelley Powers wrote:
> There's an ongoing discussion[1] about removing the Editing API from
> the HTML5 specification.
>
> The issue is less that the section was removed, and more the fact that
> the section was removed to a document OUTSIDE of the W3C. More
> importantly, this change was not truly discussed within the HTML WG,
> and I have reason to believe members of the HTML WG are not aware of
> this change. Depending on the bug system as a way of informing WG
> members of a significant change is a failure of the highest order.

I'd imagine these documents are only temporarily outside of the W3C:
it would be nice if editors making such changes -wait- until the w3c
version repositories catch up.

It'd also be nice if they'd at least reference their editor drafts on
the w3c repos, instead of consistently redirecting us to non-w3c hosts.

> Now, the same thing has happened again, but this time with the section
> of the HTML5 document formerly labeled Dynamic Markup insertion[2]. I
> don't believe there was even a bug report filed on this one, it was
> just removed[3][4].
>
> In looking at the change control entry, I also find a third document,
> DOM Range[5]. One author identifies himself, the other uses a
> nickname, rather than his real name.
>
> Seriously?

These all look like the same shared effort of DOMCORE:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

Some of the HTML5 specifications no longer rely on HTML5.

This can be helpful, for instance, on server-side or non-browers
applications trying to service various web apis.

"Ms2ger" has been using that alias for awhile. I don't believe it is an
issue with copyright, given that various groups use non-registered
aliases in their copyright notices on software.

The DOMCORE specification is now built via script, allowing the editors
to create their own fork, while maintaining a procedurally correct w3c
version.

> Again, the issue is less that the items were removed, and more that
> the items were removed unilaterally, and the new documents are placed
> outside of the W3C.
>
> My first question on all of this is: is the HTML WG even a viable
> entity anymore? It doesn't seem that way. All the HTML WG is now is a
> listing of bug entries and an occasional formal request from a
> co-chair. I have seen other Working Groups, and there is little of
> what I would call "working" about the HTML WG. Not anymore.

The HTML5/DOM4 editors do seem to be moving on in their own direction,
with the WG acting more as police than participants.
Many editors have spoken out, requesting a change in W3C policy. They're
looking for less policing.

> Secondly, is this the type of stewardship we can count on from the W3C
> going forward? Allowing one specific company to pull chunks of W3C
> specifications out of the W3C, without any consideration of other
> company's intellectual property rights on the concepts in the text
> covered in the text? More importantly, without regard for the possible
> risk this may be placing companies who have started to implement these
> specifications? These member companies have placed faith in the W3C.
> Was this faith misplaced?
>
> Perhaps rather than ask if the HTML WG is a viable entity, I should
> ask whether the W3C is a viable entity. Actions like these described
> in this email that are allowed to happen without hindrance or even
> comment  casts doubt on the ability of the organization to continue
> being a caretaker for the specifications that form the infrastructure
> for the web.

There are many specs within the w3c and working groups that are not
suffering from these power-struggles. That said, HTML5, Canvas 2d and
DOM4, are suffering.
And yes, those are very prominent specifications.

Presently, the W3C WGs are the only means we have of defending our use
cases. Though the editors of those specifications can and have created
their own specs, unilaterally, the specs hosted by the w3c still follow
procedure, or at least, are still bound to it.

There is still room for objection, and voting, within the W3C. The W3C
still offers protections, and a back channels for communication across
vendors.
Those are still present.

The specification fork for Canvas, explicitly targets and sabotages some
of my use cases. It knowingly operates against the consensus of the
canvas wg, the w3c chairs, and the actual operation of existing
implementations. But, those actions, made unilaterally, by one person,
are hosted off-site, off of the w3c.

That seems to be the direction of things. I'd request that, when editors
are publishing to w3c, they stay within the w3c domain. Otherwise, as
they're well aware, they can link where-ever they like, and do whatever
they want.

All of us have benefited from the added mobility that WHATWG-oriented
editors have gained these past few years.

I ask, again, WHATWG-oriented editors, please maintain the w3c
specifications, when you are making your changes.

-Charles

Reply | Threaded
Open this post in threaded view
|

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

Shelley Powers


On 9/8/2011 11:38 AM, Charles Pritchard wrote:

> On 9/8/2011 7:56 AM, Shelley Powers wrote:
>> There's an ongoing discussion[1] about removing the Editing API from
>> the HTML5 specification.
>>
>> The issue is less that the section was removed, and more the fact
>> that the section was removed to a document OUTSIDE of the W3C. More
>> importantly, this change was not truly discussed within the HTML WG,
>> and I have reason to believe members of the HTML WG are not aware of
>> this change. Depending on the bug system as a way of informing WG
>> members of a significant change is a failure of the highest order.
>
> I'd imagine these documents are only temporarily outside of the W3C:

The intention with the Editing API was to leave it permanently out of
the W3C. It was only when Apple objected to having to "fork" that the
editor reluctantly decided to move it back to the W3C.

Then all of a sudden it became a decision for Google Legal, only, which
is absurd.

The group made a commitment to a level of maturity of the document when
they agreed to go to Last Call. As Wayne Carr put it in the HTML WG
email. LC is not a trivial exercise, or just another document step[1].

Now, all of a sudden, entire pieces of the specification are being
hacked off and placed who knows where.

> it would be nice if editors making such changes -wait- until the w3c
> version repositories catch up.
>
> It'd also be nice if they'd at least reference their editor drafts on
> the w3c repos, instead of consistently redirecting us to non-w3c hosts.
>

Agree.

>> Now, the same thing has happened again, but this time with the
>> section of the HTML5 document formerly labeled Dynamic Markup
>> insertion[2]. I don't believe there was even a bug report filed on
>> this one, it was just removed[3][4].
>>
>> In looking at the change control entry, I also find a third document,
>> DOM Range[5]. One author identifies himself, the other uses a
>> nickname, rather than his real name.
>>
>> Seriously?
>
> These all look like the same shared effort of DOMCORE:
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
>

But it is still taking material from a LC document, in an existing
chartered group, and placing it into another document that has no
seeming standing in any group within the W3C, and doing so, if I read
the comment in the bug correctly, indifferently.


> Some of the HTML5 specifications no longer rely on HTML5.
>

This can be helpful, for instance, on server-side or non-browers
applications trying to service various web apis.
>
> "Ms2ger" has been using that alias for awhile. I don't believe it is
> an issue with copyright, given that various groups use non-registered
> aliases in their copyright notices on software.
>

It's an issue of professionalism. If the W3C doesn't care that people
use handles instead of their names, I suppose I don't either...but it's
silly.

> The DOMCORE specification is now built via script, allowing the
> editors to create their own fork, while maintaining a procedurally
> correct w3c version.
>
>> Again, the issue is less that the items were removed, and more that
>> the items were removed unilaterally, and the new documents are placed
>> outside of the W3C.
>>
>> My first question on all of this is: is the HTML WG even a viable
>> entity anymore? It doesn't seem that way. All the HTML WG is now is a
>> listing of bug entries and an occasional formal request from a
>> co-chair. I have seen other Working Groups, and there is little of
>> what I would call "working" about the HTML WG. Not anymore.
>
> The HTML5/DOM4 editors do seem to be moving on in their own direction,
> with the WG acting more as police than participants.

The WG isn't acting, it's just going through the motions.

> Many editors have spoken out, requesting a change in W3C policy.
> They're looking for less policing.
>

I would expect to see maturity in a W3C working group. Some might call
this "policing", but what we should expect from the W3C is a steady
movement to stability of delivered product.

The HTML WG has had to develop an obsessive dependence on procedure,
because the group is failing. It started to fail the very first day the
group decided to adopt the WHATWG effort, without question, and appoint
Ian Hickson as editor. It continued to fail when it didn't adopt another
editor when the second, token editor quit.

There is no discussion anymore. The Accessibility group is off doing its
thing, which is kind of sad, because most if not all that they'll
recommend will get ignored.

The HTML5 specification is undergoing major change now, none of which is
actually discussed in the HTML WG email list, most of which is hidden in
Bugzilla. But then, most members of the HTML WG seemingly gave up
months, even years ago.

I don't know what some consider "policing", but I would expect to see
more from the W3C to ensure a level of stability--not less.

>> Secondly, is this the type of stewardship we can count on from the
>> W3C going forward? Allowing one specific company to pull chunks of
>> W3C specifications out of the W3C, without any consideration of other
>> company's intellectual property rights on the concepts in the text
>> covered in the text? More importantly, without regard for the
>> possible risk this may be placing companies who have started to
>> implement these specifications? These member companies have placed
>> faith in the W3C. Was this faith misplaced?
>>
>> Perhaps rather than ask if the HTML WG is a viable entity, I should
>> ask whether the W3C is a viable entity. Actions like these described
>> in this email that are allowed to happen without hindrance or even
>> comment  casts doubt on the ability of the organization to continue
>> being a caretaker for the specifications that form the infrastructure
>> for the web.
>
> There are many specs within the w3c and working groups that are not
> suffering from these power-struggles.

Oh, there are power struggles (I followed along with the RDF group years
ago), but there isn't this constant battle with having to fight another
non-group seemingly bent on sabotaging the W3C's effort.

And agree, other groups are doing well, with a greater degree of
cooperation and a united interest in developing a sane specification.

But, as we've seen, the W3C can't depend on the behavior of the members
of the group to ensure the group progresses.


> That said, HTML5, Canvas 2d and DOM4, are suffering.
> And yes, those are very prominent specifications.
>

Because the W3C can't deal with a situation where the people aren't
cooperating--especially when some of the people who aren't cooperating
are from browser companies.

But it is with efforts such as these that we need the W3C to assert some
sanity...not adopt a hands off attitude as the effort crumbles.

> Presently, the W3C WGs are the only means we have of defending our use
> cases. Though the editors of those specifications can and have created
> their own specs, unilaterally, the specs hosted by the w3c still
> follow procedure, or at least, are still bound to it.
>

That's a good point, but with the HTML5 spec, at least, there is no
longer a defense for the interests of all communities impacted by HTML.

> There is still room for objection, and voting, within the W3C. The W3C
> still offers protections, and a back channels for communication across
> vendors.
> Those are still present.
>

I have not seen it in two years. Two years.

No, I no longer believe it.

> The specification fork for Canvas, explicitly targets and sabotages
> some of my use cases. It knowingly operates against the consensus of
> the canvas wg, the w3c chairs, and the actual operation of existing
> implementations. But, those actions, made unilaterally, by one person,
> are hosted off-site, off of the w3c.
>

Charles, I didn't even know there was a specification fork for Canvas,
I'm sorry. I've been so caught up with the HTML5 spec, itself. Where is
this fork?

> That seems to be the direction of things. I'd request that, when
> editors are publishing to w3c, they stay within the w3c domain.
> Otherwise, as they're well aware, they can link where-ever they like,
> and do whatever they want.
>
> All of us have benefited from the added mobility that WHATWG-oriented
> editors have gained these past few years.
>

You know, I'm no so sure.

The infrastructure of the web is more in a state of chaos then growth,
now. The efforts seem to be more targeted to a small group of
like-minded individuals, than the web community at large. The
accessibility folks have been especially treated with disdain, which I
find disquieting. And the world at large is burned out on the contention
between the W3C and the WHATWG.

Most of the WHATWG effort seems to be focused more on creating a new
generation of browser wars, then building the web.

> I ask, again, WHATWG-oriented editors, please maintain the w3c
> specifications, when you are making your changes.
>

I echo your statement, except I address it more towards the W3C.

W3C, fix this mess.

Shelley

> -Charles

Reply | Threaded
Open this post in threaded view
|

Accessibility and Copyright, was: Re: Sections of the HTML5 specification being removed from the W3C without discussion

Charles Pritchard-2
On 9/9/2011 6:16 AM, Shelley Powers wrote:
>
>
> On 9/8/2011 11:38 AM, Charles Pritchard wrote:
>> On 9/8/2011 7:56 AM, Shelley Powers wrote:
>>> There's an ongoing discussion[1] about removing the Editing API from
>>> the HTML5 specification.
>>>
...

>>> Now, the same thing has happened again, but this time with the
>>> section of the HTML5 document formerly labeled Dynamic Markup
>>> insertion[2]. I don't believe there was even a bug report filed on
>>> this one, it was just removed[3][4].
>>>
>>> In looking at the change control entry, I also find a third
>>> document, DOM Range[5]. One author identifies himself, the other
>>> uses a nickname, rather than his real name.
>>>
>>> Seriously?
>>
>> These all look like the same shared effort of DOMCORE:
>> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
>>
>
> But it is still taking material from a LC document, in an existing
> chartered group, and placing it into another document that has no
> seeming standing in any group within the W3C, and doing so, if I read
> the comment in the bug correctly, indifferently.

Likely, this is fall out from the straw poll on the copyright dedication
for HTML5:
http://www.w3.org/2002/09/wbs/40318/html5-license-poll-v3/results

I am not a lawyer, but I fake it when the opportunity presents itself.

This document is claimed by the three editors, solely, as their
copyright, and they have released it to public domain:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.src.html

Via build scripts, they produce this publication, which they have
granted to the W3C, and the W3C claims copyright:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

Via build scripts, they also produce this publication, which they
continue to assert their original copyright, as well as public domain
status:
http://dvcs.w3.org/hg/domcore/raw-file/tip/dom-core.html

Until and unless there is a legal challenge, I expect that WHATWG
authors will continue this practice. They maintain their changes very
closely, and though they work with W3C members, unless they actually cut
and paste code, they are likely within their rights to continue this
procedure. If/when I submit content to these editors, I will be
willingly submitting them with the understanding that it will be
released into public domain, without attribution. That said, I doubt
many others are as willing as I am. I caution the WHATWG editors, be
very careful with what you copy into your specification, lest you taint
your copyright assertion.


>
>> Many editors have spoken out, requesting a change in W3C policy.
>> They're looking for less policing.
>>
>
> I would expect to see maturity in a W3C working group. Some might call
> this "policing", but what we should expect from the W3C is a steady
> movement to stability of delivered product.
>
> The HTML WG has had to develop an obsessive dependence on procedure,
> because the group is failing. It started to fail the very first day
> the group decided to adopt the WHATWG effort, without question, and
> appoint Ian Hickson as editor. It continued to fail when it didn't
> adopt another editor when the second, token editor quit.
>
> There is no discussion anymore. The Accessibility group is off doing
> its thing, which is kind of sad, because most if not all that they'll
> recommend will get ignored.

They are, at least, supported by changes in US federal law. Many vendors
have done a poor job of even attempting to put resources into
accessibility. Many spec editors and vendor-developers consider
accessibility to be something that authors can not successfully engage
in. As a developer, I feel a similar lack of respect toward big vendors.
I take Google's recent revamp of Google Docs as an excellent sign that
at least one of their divisions has learned its lesson. I take
Microsoft's revamp of their own accessibility policies as an excellent
sign that they have learned their lesson. It sure is slow in coming,
though. Most of Google's divisions have not caught up. They have over a
hundred committing members to NaCl, and still lack a basic accessibility
structure. Chrome is in version "15", and still has flaws in basic
support of Windows high contrast mode. Their efforts are spent more on
self-voicing, than they are on first supporting the structures already
available. It's frustrating.

The beliefs of several WHATWG editors, that accessibility is a compact
between the user agent and the user, is something I find naive. The
author is involved, the author and the user are involved in human
communication. It's great to have a user agent that has assistive
properties, it's more important to have a user agent which the user can
plug other user agents into, such as ATs like JAWS. But vendor
priorities don't seem to swing that way. And since their priorities
don't go that way, the people they employ, to work on specs, are free to
remain idealists. In an ideal world, markup would be easy, and
everything would be exposed "automatically", for "free". In the
practical world, accessibility requires added effort for everyone. This
conflict doesn't sit well with the ideal world of a "correct"
specification. Without pressure, editors and vendors can drag their feet
as long as they desire.

They are dragging their feet, not maliciously. It's a state of benign
neglect, and as best as I try to communicate, I can't seem to get
through it. Sometimes I do consider it willful, a malicious ignorance.
But then I calm down, and remember that spec editors are idealists, and
vendors are self-interested corporations. Google uses Webkit, which was
largely funded by Apple: it's no surprise that their Windows
accessibility is neglected. Microsoft has its own browser, it's no
surprise that they have decided not to be regular committers to webkit
and Mozilla code bases.

Accessibility has had some big wins, in U.S. law, in corporate attention
and ARIA support. Sure, some of the spec editors see these issues as
something that can be worked out automatically, if the alchemy is
just-right. That's ok, the facts will bare themselves out, and
eventually, the vendors will mature. Microsoft has made ARIA a first
class citizen. Mozilla has an ARIA implementation with similar maturity.
It's happening... just, slowly.


>
>>> Secondly, is this the type of stewardship we can count on from the
>>> W3C going forward? Allowing one specific company to pull chunks of
>>> W3C specifications out of the W3C, without any consideration of
>>> other company's intellectual property rights on the concepts in the
>>> text covered in the text? More importantly, without regard for the
>>> possible risk this may be placing companies who have started to
>>> implement these specifications? These member companies have placed
>>> faith in the W3C. Was this faith misplaced?
>>>
>>> Perhaps rather than ask if the HTML WG is a viable entity, I should
>>> ask whether the W3C is a viable entity. Actions like these described
>>> in this email that are allowed to happen without hindrance or even
>>> comment  casts doubt on the ability of the organization to continue
>>> being a caretaker for the specifications that form the
>>> infrastructure for the web.
>>
>> There are many specs within the w3c and working groups that are not
>> suffering from these power-struggles.
>
> Oh, there are power struggles (I followed along with the RDF group
> years ago), but there isn't this constant battle with having to fight
> another non-group seemingly bent on sabotaging the W3C's effort.

You know the joke, when there are more than two people in a group,
politics are inevitable.

> And agree, other groups are doing well, with a greater degree of
> cooperation and a united interest in developing a sane specification.
>
> But, as we've seen, the W3C can't depend on the behavior of the
> members of the group to ensure the group progresses.
>

>> That said, HTML5, Canvas 2d and DOM4, are suffering.
>> And yes, those are very prominent specifications.
>>
>
> Because the W3C can't deal with a situation where the people aren't
> cooperating--especially when some of the people who aren't cooperating
> are from browser companies.
>
> But it is with efforts such as these that we need the W3C to assert
> some sanity...not adopt a hands off attitude as the effort crumbles.
>
>> Presently, the W3C WGs are the only means we have of defending our
>> use cases. Though the editors of those specifications can and have
>> created their own specs, unilaterally, the specs hosted by the w3c
>> still follow procedure, or at least, are still bound to it.
>>
>
> That's a good point, but with the HTML5 spec, at least, there is no
> longer a defense for the interests of all communities impacted by HTML.


I've seen the W3C take procedural control of a specification, out of the
hands of the editor, following WG consensus, a vote, and chair decisions.

Following that, the editor decided to address the issue that was
discussed in the WG, and added it to a forked, self-hosted, specification.

It's a little dysfunctional, but it is progress. I'm still holding out
hope for the specs to be merged... it may take a year for that to happen.

In the meantime, following the public comments of many spec editors,
I've decided that my efforts would be better spent developing patches
for existing browsers, and appealing to vendors directly, instead of
quarreling with editors. I do still gain benefit, and more
eyes, ears and conversations, through the W3C than I would otherwise.


>
>> There is still room for objection, and voting, within the W3C. The
>> W3C still offers protections, and a back channels for communication
>> across vendors.
>> Those are still present.
>>
>
> I have not seen it in two years. Two years.
>
> No, I no longer believe it.

There are many vendor-developers who only respond through W3C / WHATWG
public forums, and who have asked me in no uncertain terms, never to
e-mail them directly.


>> The specification fork for Canvas, explicitly targets and sabotages
>> some of my use cases. It knowingly operates against the consensus of
>> the canvas wg, the w3c chairs, and the actual operation of existing
>> implementations. But, those actions, made unilaterally, by one
>> person, are hosted off-site, off of the w3c.
>>
>
> Charles, I didn't even know there was a specification fork for Canvas,
> I'm sorry. I've been so caught up with the HTML5 spec, itself. Where
> is this fork?

It's minor: the editor decided that interactive form elements in the
<canvas> subtree should be restricted to <button>, radio and checkbox.
There are some other changes, but they are actually productive, and
intended to solve the use cases presented. It would be nice if they were
the topic of conversation, instead of non-discussed code-forks. I think
the editor was a little bitter about seeing the w3c specification
forcefully altered by w3c staff.

There was a similar attempt to restrict ARIA semantics on HTML tags,
such that tags with existing semantics could not be overwritten;
that is, one would not be able to do : <a role="button" href>...</a>

That was also met with resistance.


>> That seems to be the direction of things. I'd request that, when
>> editors are publishing to w3c, they stay within the w3c domain.
>> Otherwise, as they're well aware, they can link where-ever they like,
>> and do whatever they want.
>>
>> All of us have benefited from the added mobility that WHATWG-oriented
>> editors have gained these past few years.
>>
>
> You know, I'm no so sure.
>
> The infrastructure of the web is more in a state of chaos then growth,
> now. The efforts seem to be more targeted to a small group of
> like-minded individuals, than the web community at large. The
> accessibility folks have been especially treated with disdain, which I
> find disquieting. And the world at large is burned out on the
> contention between the W3C and the WHATWG.
>
> Most of the WHATWG effort seems to be focused more on creating a new
> generation of browser wars, then building the web.

I thought there might be a systematic means of proving HTML
completeness, by demonstrating that the accessibility tree, the DOM (as
accessed by the scripting environment) and the visual output, were on
par with the flexibility of current desktop applications. I thought
that'd be a nice way of looking at current needs. Many vendor-developers
told me off, on that one, claiming that user interface widgets are too
complex for authors to handle, and should be left up to user agents.

The current chaos, yes it is a bit chaotic, but it's serving the
growing, new, Web Apps community. I know that Doug had hoped for more
rapid progress and uptake of SVG. I wanted the same back in 2003.

Anyway, it didn't work out, so what we have instead are a whole lot of
components. And they are working out. We're able to build web
applications, which I contend, are fundamentally different than web
documents.
Documents are consumed by a user agent. Applications -are- a user agent,
they consume content. And as nice as HTML forms are, they're very basic
UI constructs.

I've had this argument a few times with spec editors and vendors. They
hum and haw, and finally say that "games", those are different than
documents, but web applications are not. They also claim that games can
not be served by existing accessibility semantics. A perspective I also
disagree with.

Here's David Singer of Apple, doing his best to imagine a "bio-reactor"
application, where he contends that existing accessibility semantics
would be in-effective:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0227.html
'a bio-reactor, in which various populations of algae, funghi, bacteria
etc. are competing. The user can interact with it using a 'virtual
pipette'... "

I've countered several times, that whether in games or in mechanical
simulations, current accessibility practices should be the first thing
examined.


>> I ask, again, WHATWG-oriented editors, please maintain the w3c
>> specifications, when you are making your changes.
>>
>
> I echo your statement, except I address it more towards the W3C.
>
> W3C, fix this mess.
>

Given the propensity of spec editors to fork, and to do things how they
want to, I think that the precedent set by DOMCore (now DOM4) is sound.
Move the specs onto the distributed version control system. Ask WHATWG
editors to use a single source file, and appropriate markup to handle
attribution and specification forks.

That makes it easy for the W3C to step in, when process dictates, while
still allowing the editor to maintain their own personal preferences on
their personal publications.


TLDR; WHATWG editors have a strong legal argument for asserting their
copyright in publications, independent of W3C publications. Many spec
editors and vendors have neglected practical accessibility
considerations, per WCAG, but they are increasingly giving those
principles more attention.  The W3C can force-the-hand of spec editors,
by having W3C staff alter specification documents hosted on w3c servers,
this has happened with Canvas.  Many spec editors and vendors continue
to want to innovate, and serve accessibility, but they are doing so from
a place of idealism, and are unreasonably neglecting existing
infrastructure. Many spec editors will continue to fork their
specifications from the decisions of WHATWG working groups. This
situation can be made more tolerable by maintaining documents and
version control which are suited to frequent forking and merging.


-Charles