Hi, Anne-

I object to publishing a Working Draft of the DOM Core spec that includes DOM Events.

Introducing conflicting specifications that cover the same materials dramatically harms interoperability, and the idea of "competing specifications" is an anti-pattern when it comes to standardization.

If there are changes that you want to the DOM3 Events spec, and if you get the support of the browser vendors to make those changes, then I am happy to change the spec; I'm not married to the spec as it exists, but that is the result of what the last few years of discussing it with the browser vendors and users has resulted in. Please simply raise the individual issues on the www-dom mailing list for discussion. So far, I've seen no support on the list for adding events to DOM Core.

Finally, at TPAC, when we discussed working on DOM Core and DOM 3 Events "in parallel", we did not agree to adding events to DOM Core; in fact, we agreed to exactly the opposite: you wanted to move mutation events into DOM Core in a thinly-veiled attempt to remove them completely (rather than simply deprecate them as is done in DOM3 Events), and all the browser vendors disagreed with that. Claiming otherwise is simply an attempt to rewrite history.

So, in summary: please remove section 4, Events, from DOM Core before publishing it as a Working Draft, for now. After serious discussion, if the group agrees, we can always add them back later, but I would prefer to change DOM3 Events to seeing conflicting specifications.

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs


Anne van Kesteren wrote (on 2/24/11 5:37 PM):
On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman
<adria...@microsoft.com> wrote:
I'm concerned about the working group endorsing a working draft with
phrasing like "The timeStamp attribute must be useless." I understand
there are issues related to this (e.g. ISSUE-172) but this doesn't
seem like a professional way to approach them.

It's a funny way ;-) And it has a red marker pointing out the problems.
And as stated in the Status of this Document section publication does
not imply endorsement.


I think the document should have a clearly stated goal relative to DOM
L3 Events.

I thought that would be inappropriate since DOM Level 3 Events is still
in development. We discussed this at TPAC and decided that DOM Core
would do things in parallel and based on that we would figure out which
is the better approach once both are somewhat more stable. However,
relative to DOM Level 3 Events the differences are identical. So if that
would remove your objection I can change the "2" to a "3".


Currently it describes building on DOM L3 Core and DOM L2 Events. Anne
described adding events to the draft last week [1] but it's not clear
to me what the benefit of redefining the Event interface in this
document is when W3C is proceeding with DOM L3 Events on the
Recommendation track. If there are things that need to be clarified
specifically for browsers and similar user agents then perhaps a
profile of DOM L3 Events would be better.

The idea is to provide a better definition of the events model at a more
appropriate location. I do not think DOM Level 3 Events is the right way
forward, but I am happy to work in parallel to see which turns out
better in the end.


I'd prefer issues like this to be resolved before endorsing them in a
Working Draft.

Working Drafts are there to share ideas with the wider world. They are
not endorsed. Last Call Working Drafts and beyond are supposed to be
checked carefully. Letting the wider world comment on this idea is
exactly what I would like; to see if it's a good idea.

It would be nice if you could suggest some approach as to how we could
resolve this timely.


[1]
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0559.html


Reply via email to