W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2005

DOM Events v 3.0

From: Floersch, Chris (MAN-Corporate) <Chris.Floersch@cox.com>
Date: Mon, 24 Oct 2005 10:50:39 -0400
Message-ID: <E3F45252EBE3444A8F97E37442123AC7025D39BF@mmscs20.man.co>
To: "'www-dom@w3.org'" <www-dom@w3.org>

Just some comments about the spec. I noticed a few things that should be
considered.

UIEvents should have the relatedTarget field rather than MouseEvents.
RelatedTarget in a DOMFocusIn would be the element that was losing focus and
vise versa..

Also I realize than HTML does not have anything like key handlers. Kinda
like Java's KeyStorke which can bind particular keyevents to actions. But
other XML implementations might. The relatedTarget field could be used in
the DOMActivate as well to reflect any number of things.

Also on MouseEvents. You have clientX, and clientY, why not just a simple X,
and Y?? Seems to me in a browser clientX, and clientY would be relative to
the frame/document coordinates. But X,Y would/should be relative to the
component's coordinate space.

Seems the detail arg should be moved from UIEvent to MouseEvent and be
renamed to count or something. KeyEvents don't use it. Focus Events don't
use it, TextEvents don't use it. The only thing that seems to use it other
than mouse events is the activate and to be honest with you it kinda seems
pointless as it implies no difference between activate and click.. Activate
is typically a preassigned condition of a particular type of component. And
Enter/Clicks should not be tied to it. Anyway< I realize that for backward
compatability this is unlikely but it makes little senseto have it as part
of UIEvent.. Don't make a similar mistake with the relatedTarget field.. It
would be very useful for a great deal more than just mouse events.
Received on Monday, 24 October 2005 22:49:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:58 GMT