W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2010

Minutes, DOM 3 Events Telcon, 14 Apr 2010

From: Doug Schepers <schepers@w3.org>
Date: Thu, 15 Apr 2010 13:36:33 -0400
Message-ID: <4BC74EA1.5060607@w3.org>
To: "www-dom@w3.org" <www-dom@w3.org>

Web Applications Working Group Teleconference
14 Apr 2010

See also: IRC log

     Shepazu, [Microsoft], Olli_Pettay
     smaug_, smaug


     * Topics
          1. registering events on nodes
          2. publish a working draft
     * Summary of Action Items

<trackbot> Date: 14 April 2010



<smaug_> scribe, smaug_

<shepazu> scribenick: smaug_

Travis: going through issues
... there is still magnify event

shepazu: we should clarify focused and active element

Travis: it all depends on whether the browser is focused or no

<smaug> testing

<smaug> scribenick, smaug

<smaug> scribenick: smaug

shepazu: I'm not quite sure whether relatedTarget should be null in some 
cases in FocusEvent.relatedTarget

Travis: this is about the security issue focusing iframe for example
... or if relatedTarget comes anywhere outside the document

shepazu: writing email to the mailing about relatedTarget
... I took magnify out of the spec
registering events on nodes



shepazu: the latter link points to example which isn't quite right

Travis: you can't register something unless it is eventtarget
... trusted (implementation) mouse events fire only on elements
... but scripts may create mouse events and fire them on text nodes

smaug: so remove "text nodes cannot be registered as event listeners"

Travis: in the big blue table, those proximal event target types are for 
the "trusted events"

<Travis> trusted of type boolean, readonly, introduced in DOM Level 3

<Travis> Used to indicate whether this event was generated by the user 
agent (trusted) or by script (untrusted). See trusted events for more 

shepazu: should I define hysteresis

Travis: yeah

<shepazu> define different headers in the List of DOM3 Event Types (esp. 
Trusted Proximal event target types)

<shepazu> also, explain in eventListener interface that though every 
node typ can be an event target, different trusted event types can only 
be registered and have as targets specific node types

Travis: about compositionend
... it is currently cancelable
... if it is cancelled textInput isn't fired
... in our implementation compositionend fires in few different cases: 
user commits the composition, or if IME looses focus etc
... so IME tells when it is "done" and we fire compositionend
... the feedback I had, cancelling compositionend cannot "undo" composition

smaug: cancelling textInput doesn't make

Travis: if you have textInput listener, you can always know the previous 

smaug: just store the old value somewhere

shepazu: no sense to have textInput cancelable

smaug: make it non-cancelable

Travis & shepazu yep

Travis: cancelling compositionend doesn't prevent textInput from firing

i.e. doesn't undo the composition


Travis: currently only compositionstart is effectively cancelable
publish a working draft

shepazu: for next week I'll try to get rid of as many issues as possible
... then we'll publish

resolution: publish new DOM 3 Events working draft

ArtB: I would get not yet LC



shepazu: once again I mentioned to XForms wg about DOMActivate that they 
haven't sent all the feedback
... I'd like to have LC before mid May

<shepazu> trackbot, end telcon
Received on Thursday, 15 April 2010 17:36:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:16 UTC