Re: publish a new Working Draft of DOM Core; comment deadline March 2

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