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
