Re: publish a new Working Draft of DOM Core; comment deadline March 2

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
> <adrianba@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
>

Received on Friday, 25 February 2011 01:21:49 UTC