Re: Fwd: [IndexedDB] Event handlers

On 2/1/13, David Bruant <bruant.d@gmail.com> wrote:
> Le 01/02/2013 02:17, Cameron McCormack a écrit :
>>>> The main problem at the moment with on/event/ is that you cannot
>>>> actually tell from that whether such events will be dispatched on that
>>>> object and no others. (E.g. DOMContentLoaded is dispatched on objects,
>>>> but has no corresponding on/event/ attribute, events for media
>>>> elements have on/event/ attributes on HTMLElement rather than just
>>>> <video> and <audio>, etc.) Although I suppose that is only true for
>>>> HTMLElement/Document/Window and not true for other classes, such as
>>>> XMLHttpRequest.
>>>>
>>>> I don't think we've settled on a strategy here yet.
>>>>
>>>>
>>>> Maybe IDL is not the right place, but giving a listing of events
>>>> dispatched next to the IDL might be nice for developers trying to
>>>> figure out what the object can do.
>>> May I ask why IDL wouldn't be the right place?
>>> And what would be a list next-to-IDL-but-notIDL?
>>
>> Although you could consider the set of events that the browser will
>> dispatch to a given DOM object to be part of the overall API
>> interface, it's not really part of the interface in the IDL sense

The event is not be a part of the object that it is dispatched to but
there is a relationship in some sense. The HTML5 spec explains the
API-defined events that fire on INPUT. And MSDN always listed their
events in a table.

> I keep reading this sentence and I'm not sure I understand. I would
> expect the "I" in IDL and API to refer to the same thing, that is, a
> description of how a script can interact with an object. An IDL fragment
> should be a D-escription of the overall AP-I. That's what I imagined at
> least. Maybe I was wrong.
> \

Travis Leithead summed the crux of the "which events on an interface"
problem. The event is a string and any event may fire at any time.
That is why there is now the 'isTrusted' property on events.

For more detail, see w3c message "Detecting and Creating Events".
There, I proposed 'eventTarget.generatesEvent' and IIRC that was no
good because of Gecko's internals.

>>
>> There's "Categories", "Contexts in which this element can be used",
>> "Content model", etc.
> These are specific to HTML. And nothing forbids you in JS to append an
> <h1> to a <p>.
> \
HIERARCHY_REQUEST_ERR, DOM 1. HTML 4 says that the P element cannot
contain block level elements so that DOM error can be expected. And
when <P><H1></H1></P> is parsed, the P should be closed. I would avoid
doing that.

Can we get back to talking about Events?
-- 
Garrett
Twitter: @xkit
personx.tumblr.com

Received on Friday, 1 February 2013 16:54:08 UTC