Re: Travis-Jonas-Mike replies [DOML3Events] ACTION-267 Proposal for event iterator

Jonas Sicking wrote on 28 april 2009 21:57:
> On Tue, Apr 28, 2009 at 12:50 PM, Travis Leithead
> <Travis.Leithead@microsoft.com> wrote:
> > I think this was dropped because it would allow general web> apps to  
> inspect (and remove?) event handlers that were> registered by code  
> running in extensions or by the browser itself.
>  That is the initial problem that we in firefox would have with this.

As you pointed out last year, it is a "nice to have" but not crucial
to let the native browser code be able to use the same interfaces as
web page scripts. From an author's point of view I would expect only
other "user code" registered event handlers to be enumerated by the
event iterator, not browser or extension handlers.

Actually, I think a spec for the event iterator should explicitly say
that these MUST not be included in the enumeration.

Does that take care of the security issues or am I missing something
else?

The DOM is pretty much up for taking for any script allowed inside, so
are there really any new and dangerous things that can be done just
because event handlers are listable (and therefore removable), that
cannot be implemented by other means?

> The other problem is a lack of use cases.

In my view the API isn't complete without being able to enumerate a
collection that already has add/remove-methods, and as stated earlier
I think the main question should be what good reasons there are not to
include it. Use cases acknowledged by the browser literati or not, I
think this a matter of API completeness.

Personally I have been missing this feature when doing client-side DOM
transformations, f ex transforming more simple element hierarchies
into widget-like experiences and wanting to move/re-register existing
event handlers into the new element structure. This currently requires
the initial structure to use DOM0 event attributes.

Best regards
Mike Wilson


On Wed, 29 Apr 2009 01:05:34 +0200, Charles McCathieNevile  
<chaals@opera.com> wrote:

> (forwarded from public-webapps - I will add the current replies from  
> there to this thread)
>
> ------- Forwarded message -------
> From: "Mike Wilson" <mikewse@hotmail.com>
> To: public-webapps@w3.org
> Cc:
> Subject: RE: [DOML3Events] ACTION-267 Proposal for event iterator
> Date: Sat, 25 Apr 2009 11:35:54 +0200
>
> Following up on last year's discussion on adding support for
> querying DOM elements about already registered event handlers:
>
> Travis Leithead wrote on Apr 09, 2008; 08:07pm
>> In considering a design for the event iterator (allow devs
>> to enumerate what events have been _added_ via
>> addEventListener to a given object), I looked at two general
>> approaches:
>>
>> 1) Defining a new collection on every object that supports
>> the EventTarget interface
>> 2) Defining a 'getNextEvent' function for every object that
>> supports the EventTarget interface
>> 3) Defining a function that returns a static/dynamic list of
>> event handlers for a given object that supports the
>> EventTarget interface
> <rest of conversation snipped>
>
> Action page:
> http://www.w3.org/2006/webapi/track/actions/267
>
> Mail thread view on nabble:
> http://www.nabble.com/-DOML3Events--ACTION-267-Proposal-for-event-iterator-t
> d16593177.html#a16691378
>
> Was any consensus ever reached and what's the status of this
> suggestion now?
>
> Personally I think this feature is a very natural part of the
> DOM API and believe there needs to be very good reasons not to
> include it.
>
> Best regards
> Mike Wilson
>
>
>



-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 28 April 2009 23:20:58 UTC