W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: [DOM3 Events] Initialising events (concerns)

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 24 Sep 2009 13:24:00 +0300
Message-ID: <4ABB48C0.8050204@helsinki.fi>
To: Sergey Ilinsky <castonet@yahoo.co.uk>
CC: "www-dom@w3.org" <www-dom@w3.org>
On 9/24/09 12:16 PM, Sergey Ilinsky wrote:
> Hi,
> Having used DOM extensively (both implementing DOM and building
> applications directly interfacing with it) I would like to bring my
> consideration regarding re-factoring activity undertaken on DOM
> Events module. Although everyone interested is indeed aware of all
> these concerns, I thought it would be useful to summarize some of
> them.
> 1) The suggested change in the event interfaces is backwards
> incompatible with DOM-Events L2 and L1.
There is no DOM 1 Events ;)

> There is plenty of
> implementations, whose are not limited by "modern web-browsers" and
> include many other platforms (not even "libraries"), such as, for
> example JDK [1]
> 2) The change suggested only brings minor syntactical sugar without
> adding any functional value.
The change allows extensibility. Currently we're stuck with the 
properties which have been defined in DOM 2 Events, because we can't
add new parameters to init methods.

Would adding new methods to Java break the backward compatibility?
If we're talking about the suggested change to
allow setting attribute values before dispatching, that would mean
that Java would have to add setter methods 
bubbles/cancelably/target/etc. Does adding new methods to interface 
break backwards compatibility in Java? In C++ one could probably add a 
new interface,
which implements the setters and leave the DOM 2 Events interface as it 
is now. Well, actually, one could do that in Java too.
The currently org.w3c.dom.events.Event would stay as it is and
org.w3c.dom.events.DOM3Event would have the setter methods.
(ugly, but possible)

Note, I'm not happy changing the interfaces, but the current 
initXXXEvent methods are awkward and don't allow extensibility.


> 3) Application developer normally never creates/dispatches events
> into DOM thus never facing the part of interface in subject. Instead
> he only picks events up by registering a listener and quires event
> object properties. Those 14 people who ever touch event
> initialization methods, can create the convenience APIs themselves,
> and even prototype them on objects that implement EventTarget
> interface.
> Having found a new perfect API (BTW, why do you think you can do
> that?), which is in fact useless, we will destabilize web as a
> platform.
> Regards, Sergey Ilinsky.
> P.S. I welcome dropping namespaces from DOM Events.
> [1]
> http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/events/package-use.html
Received on Thursday, 24 September 2009 10:25:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:56 UTC