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

Hi, folks-

I have no problem changing the DOM3 Events spec if that's the behavior 
that implementers want specified.  I'd love for it to be as clear, 
simple, and precise as possible, and I have been asking for specific 
feedback for the past few years; while we have gotten a lot of good 
feedback, we did not get feedback asking for these specific changes... 
if we had, and if there was agreement by the browser vendors, we would 
have simply made the changes.

In fairness, it's often easier to start with a blank slate than to 
revise something that's been around for 10 years with several different 
rounds of editors.  I've thought of doing the same with DOM3 Events 
before, and maybe I should have.  So, sometimes things simply become 
more clear when you write them yourself than when you comment on 
existing specs.  I applaud the DOM Core editors taking the initiative to 
revisit assumptions and try to make a cleaner model.

However, what I don't want is for DOM3 Events to be irrelevant, 
incorrect, and misleading by the time it reaches Rec... obviously, we'd 
revise it, but in the meantime, it would be sitting in CR, giving 
implementers the impression that it is the way to get interoperable 
behavior, and that it is relatively stable... having a concurrent 
conflicting spec within the same group is an anti-pattern, when one spec 
is moving toward stability after years of consensus-building around the 
behavior.

(In general, I don't think it is a good practice to make conflicting 
working drafts rather than commenting on existing specifications first; 
I don't think it is an efficient way for a group to proceed (though of 
course conflicting proposals help improve specs in the early stages).)

I don't object to specifying the event model in DOM Core going forward, 
nor to extensions to what is defined in DOM3 Events; I only object to 
conflicts or contradictions between the two specs.  In fact, there are 
changes I would like to have specified in DOM3 Events, but couldn't 
build consensus around for that timeframe, including generic event 
constructors and initializers, rather than initializers for each event; 
I think this is a much better model.

I will remove my objection to publish DOM Core if: 1) conflicts (rather 
than extensions) are removed from the draft, or reconciled with changes 
in DOM3 Events; and 2) for those changes that have broad consensus, we 
can integrate them into DOM3 Events, which means that the changes should 
be sent as comments on DOM3 Events, to be discussed by the group and 
their current status determined.

I had previously started a DOM Core 4 draft specification, but when Anne 
and others volunteered to do Web DOM Core, I moved aside to let them 
work, and volunteered to help with that draft; I would still like to 
help edit that specification, to bring a slightly different perspective 
and approach, and to coordinate between DOM3 Events and DOM Core, and I 
believe we can edit the spec together amicably and productively.

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

Received on Saturday, 26 February 2011 15:15:31 UTC