W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

[DOMCore] Added Events

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 15 Feb 2011 11:20:48 +0100
Cc: www-dom@w3.org
To: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.vqxwcybi64w2qv@anne-van-kesterens-macbook-pro.local>
As I mentioned at TPAC I wanted DOM Core to include the fundamentals of  
events[1]. As with the rest of DOM Core I have attempted to write it from  
scratch loosely based on testing browsers and the existing DOM Events  
specifications. Glenn Maynard helped out with some details.


This is a rough overview of what changed since DOM Level 2 Events/DOM  
Level 3 Events:

  * It is clearer what attributes of an event return at any point during  
the existence of an Event object. E.g. what does ev.type return if ev =  
document.createEvent("event"). Or what does ev.eventPhase return at any  
point in time? Now defined.
  * There are no more restrictions on Event.type. Gecko allows the empty  
string and I do not see a good reason to add extra checks to prevent that.
  * This makes invoking initEvent() optional.
  * I have allowed for initEvent() to be invoked before and after  
dispatching. It will unset the trusted flag. There did not seem a need for  
a restriction other than during a dispatch.
  * I have made initEvent() arguments other than the first optional. Making  
it slightly more convenient to use.
  * Propagation and canceled state are cleared before dispatching rather  
than after. Otherwise defaultPrevented would be affected.
  * I changed the details around cancelable events to make more sense. Only  
with cancelable events will invoking preventDefault() have an effect.  
Browsers were not really in alignment here.
  * This also means that the return value of dispatchEvent will be false if  
preventDefault() was called on a non-cancelable event.
  * Removed the need for EventException.

Overall I feel it is a much more straightforward definition of the events  

Feedback appreciated!

[1] Part of the reason was that mutation events could eventually be  
defined directly by the methods that trigger them hopefully making it much  
less opaque how they actually work. Now I have not actually gotten around  
to specifying mutation events just yet. Another reason is that now Node  
can easily inherit from EventTarget. I believe we wanted to do that, right?

Anne van Kesteren
Received on Tuesday, 15 February 2011 10:21:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC