On Wed, 02 Mar 2011 06:10:47 +0100, Garrett Smith <[email protected]>
wrote:
On 3/1/11, Anne van Kesteren <[email protected]> wrote:
These are the reasons they are intertwined:
* document.createEvent()
That was previously DocumentEvent interface, IIRC.
Implementations put it on Document instead. And of course we could then
still define it in a separate document (we are planning to introduce
"extends" or some such for that), but it is more convenient to not do so.
* mutation events
Why can't those be defined independently in Events. (not a fan of
mutation events, BTW).
Nobody is a fan. They are dispatched directly as the result of method
invocation and in some cases can even effect what exception the method
needs to throw (as I understand it). So they are highly intertwined and
defining them separately is not a good idea.
* we want Node to inherit from EventTarget
That can be stated in DOM Core. For example: The Node Interface
implements EventTarget [Events Core].
Implements is different from inheritance. Again though, yes that would not
require Events to be in the same document, it is just more convenient.
* both events and documents depend on the same tree concept
How do XHR events or progress events depend on tree concept?
Indexed DB does. Not everything does, of course.
* INVALID_STATE_ERR is shared
XHR and Event instances can have invalid states, but should those
exceptions to have the same name and numerical representation?
That is the convention we have used thus far, yes (not just for
XMLHttpRequest). I doubt we will change that at this point.
[...]
I noticed that the DOM Core spec uses "throw" instead of "raise". I
don't mind the change but it might be something that matters for IDL
formalism.
This will probably converge over time.
--
Anne van Kesteren
http://annevankesteren.nl/
