Re: Spec update: deviceorientation event should fire when listener is first registered

On Wed, Jul 13, 2011 at 1:29 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Tue, 12 Jul 2011 18:43:23 +0200, Wojciech Masłowski
> <wmaslowski@opera.com> wrote:
>>
>> I think you misunderstood me - what I meant is not that it doesn't make a
>> difference from compatibility point of view if a browser sends an event or
>> not, but that that it only matters for the first event you receive and not
>> really that much for later events unless you rely on something you really
>> shouldn't anyway.
>
> Sites will rely on that. Silly stuff happens on the web all the time. When
> designing APIs for the web you have to assume they are going to be used
> incorrectly.
>
>
>> If we are to be really picky then adding event listener for device
>> orientation enables the device compass which is a side effect. Other would
>> be sending an empty event to signal that the runtime cannot provide values.
>> Do you suggest that orientation doesn't fit DOM Events model and it should
>> something else, for example the same approach as geolocation?
>
> You could have the same approach as MessagePort as I mentioned elsewhere.
>

But I don't think that's a good idea for the reasons explained in my
previous email on this thread. Furthermore, that seems to contradict
the DOM Level 3 Event specification which clearly states in section
4.3 that:

"Note: In addition to the EventTarget.addEventListener method, some
host languages may allow a content author to register event listeners
by the use of attributes, e.g., onclick="handleClick()". Because the
details of this are often language-specific, this type of event
listener registration is not defined in this specification, but in
general, any event type may be used as an attribute in this way by
adding the prefix on- to the event type name, and events so dispatched
should behave consistently with the event registration and propagation
defined in this specification, with the same interfaces, properties,
and methods."

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#interface-EventTarget

Furthermore, HTML 5, section 6.1.6.1 says on the same topic:

"All event handlers on an object, whether an element or some other
object, and whether set to null or to a Function object, must be
registered as event listeners on the object when it is created, as if
the addEventListener() method on the object's EventTarget interface
had been invoked"

http://dev.w3.org/html5/spec/Overview.html#event-handler-attributes

How does your proposal comply with the "should behave consistently"
and "as if the addEventListener() had been invoked"  sentences above?

>
>> PS: Can you point me to any point in the DOM Events spec that states that
>> addEventListener cannot have any side effects?
>
> Specifications work the other way around. The events specification does not
> say it can have side effects and therefore it cannot (unless we modify it).
>

I guess the intent here was to say that adding a new event listener is
an event activation trigger. I couldn't find any guidelines anywhere
about what can and cannot be an activation trigger....

Thanks,
Andrei

Received on Wednesday, 13 July 2011 13:27:47 UTC