- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Tue, 1 Mar 2011 21:10:47 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Adrian Bateman <adrianba@microsoft.com>, Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>, Michael Champion <Michael.Champion@microsoft.com>
On 3/1/11, Anne van Kesteren <annevk@opera.com> wrote: > On Mon, 28 Feb 2011 18:49:48 +0100, Garrett Smith <dhtmlkitchen@gmail.com> > wrote: >> | DOM Core defines the event and document model the Web platform uses. >> >> That says that DOM Core defines two different things: events and DOM. >> Some things might implement DOM Events Core (or a subinterface >> thereof) but are unrelated to the DOM. Like XHR. >> >> Could Events Core exist on its own? (You could make DOM Core >> conformance require Events Core conformance). > > These are the reasons they are intertwined: > > * document.createEvent() That was previously DocumentEvent interface, IIRC. > * mutation events Why can't those be defined independently in Events. (not a fan of mutation events, BTW). > * we want Node to inherit from EventTarget That can be stated in DOM Core. For example: The Node Interface implements EventTarget [Events Core]. > * both events and documents depend on the same tree concept How do XHR events or progress events depend on tree concept? > * 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? Defining Errors within the API that uses them makes it easier to change the Error. > Of course, given a mutual dependency they could be split, but I do not > really see the point. Something that depends on Events Core doesn't necessarily need to depend on DOMImplementation. I believe ProgressEvents is an existing case of that. I like to define specification to be specific. This makes them easier to read and change. Things that aren't related to document navigation can theoretically implement EventTarget. Node stuff, for example, nextSibling and cloneNode, aren't relevant to ProgressEvents. Should the "Exceptions" section be split out too in > your opinion? Given that "Events" and "Exceptions" are quite short and per > the above summary quite integral to how everything fits together I think > the current division makes sense. > No. "Exceptions" should not be in a separate specification; there is no core Exception module or interfaces. I like having the exception grouped with the API that uses it. INVALID_STATE_ERR for EventTarget is conceptually different than for XMLHttpRequest. I don't like having the same name for two different things. For example, a program that redispatches an Event would be putting that Event instance in an invalid state. Conversely, an `XMLHttpRequest` that calls `send()` before `open()` also creates an invalid state. However, to me, those are different scenarios. These two scenarios don't have enough in common to justify giving them the same numerical error code. I would actually prefer these two cases to have different error names because I think it would ease debugging. For instance, when an error message is missing or unhelpful, a web search on the error name should result in something more closely relevant to what caused the error. I'd stink to have a program with an XHR problem and get an error, search the web for that error, find the the Events API, and then go back to the program's event code. 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. -- Garrett
Received on Wednesday, 2 March 2011 05:11:20 UTC