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
