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

Minutes, 11 May 2011 DOM3 Events Telcon

From: Doug Schepers <schepers@w3.org>
Date: Wed, 11 May 2011 14:52:58 -0400
Message-ID: <4DCADB0A.9010802@w3.org>
To: "www-dom@w3.org" <www-dom@w3.org>
http://www.w3.org/2011/05/11-webapps-minutes.html


              Web Applications Working Group Teleconference

11 May 2011

    See also: [2]IRC log

       [2] http://www.w3.org/2011/05/11-webapps-irc

Attendees

    Present
           Doug_Schepers, [Microsoft], Olli_Pettay

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           jrossi

Contents

      * [3]Topics
          1. [4]ISSUE-137
          2. [5]legacy key events
          3. [6]ISSUE-142?
          4. [7]ISSUE-142
          5. [8]onclick after removing element from document during
             onmouseup
          6. [9]WebApps-ISSUE-178?
          7. [10]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/D
             OM3-Events.html#event-type-DOMActivate
          8. [11]strange DOMACtivate wording
          9. [12]Next Steps
         10. [13]DOM Core
      * [14]Summary of Action Items
      _________________________________________________________

    <trackbot> Date: 11 May 2011

    <smaug> let's see if the connection is good enough

    <scribe> scribenick: jrossi

ISSUE-137

    smaug: it *may* fire for IME

    jrossi: yes, seems implementation specific. IE9 doesn't seem to fire
    at all.

    shepazu: let's add spec text stating that

    resolution: add text to keypress that states this event may not fire
    for IME input, depending on platform/implementation

legacy key events

    <shepazu>
    [15]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Event
    s.html#KeyboardEvent-supplemental-interface

      [15] 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#KeyboardEvent-supplemental-interface

    jrossi: yes, I'm fine with this with the new spec text

    shepazu: I also felt it OK to use WebIDL here since it's
    non-normative

    jrossi: agree

    smaug: yes, that's fine

    resultion: keep it as is

ISSUE-142?

ISSUE-142

    ISSUE-142?

    <trackbot> ISSUE-142 -- one keydown might fire multiple
    keypress/textInput events -- raised

    <trackbot> [16]http://www.w3.org/2008/webapps/track/issues/142

      [16] http://www.w3.org/2008/webapps/track/issues/142

    shepazu: maybe test this with a macro

    jrossi: testing with CTRL+V, we get one textinput
    ... are there dead keys that are macros of multiple characters?

    shepazu: don't see many results from a search for these
    ... I think it should result in only a single textinput event

    jrossi: I'm fine with Hallvord's suggested spec text with the caveat
    that IE may be broken in some unknown cases. But we probably
    wouldn't value those scenarios highly and would treat them as bugs.

    smaug: I'm fine with this. We should ask him for clarification
    though.

    shepazu: I'll follow up with Hallvord to confirm.

    resolution: shepazu will discuss the effect of keypress for multiple
    characters, but won't change the spec pending some evidence from
    hallvord

onclick after removing element from document during onmouseup

    <shepazu>
    [17]http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0052.html

      [17] http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0052.html

    <shepazu>
    [18]http://lists.w3.org/Archives/Public/www-dom/2011AprJun/thread.ht
    ml#msg58

      [18] 
http://lists.w3.org/Archives/Public/www-dom/2011AprJun/thread.html#msg58

    issue-180?

    <trackbot> ISSUE-180 -- onclick after removing element from document
    during onmouseup -- raised

    <trackbot> [19]http://www.w3.org/2008/webapps/track/issues/180

      [19] http://www.w3.org/2008/webapps/track/issues/180

    <shepazu> [20]https://bugs.webkit.org/show_bug.cgi?id=60600

      [20] https://bugs.webkit.org/show_bug.cgi?id=60600

    jrossi: IE9 matches Gecko in that we don't fire click events or
    perform the activation when the element is removed from the document
    during mouseup
    ... I don't believe it's desirable (or potentially safe) to activate
    links which have been removed from the document

    smaug: yes, I agree

    [21]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Event
    s.html#events-mouseevent-event-order

      [21] 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-mouseevent-event-order

    smaug: it should probably go in 5.2.3.2 Mouse Event Order

    jrossi: agrees

    <a href="[22]http://www.google.com" id="test">test</a>

      [22] http://www.google.com/

    <script>

    var elem = document.getElementById("test");

    elem.addEventListener("mousedown", function(e) {

    alert('mousedown');

    elem.parentNode.removeChild(elem);

    }, false);

    elem.addEventListener("mouseup",function(e){
    alert('mouseup');},false);

    elem.addEventListener("click",function(e){ alert('click');},false);

    </script>

    jrossi: this doesn't apply specifically to click, if you remove the
    element at any point in the sequence then the rest of the sequence
    is aborted

    <shepazu> "If an element is removed from the DOM between mousedown
    and mouseup, no events will be dispatched for mouseup, click, or
    subsequent activation events."

    <shepazu> "A mouseup event may still be dispatched on a different
    element, depending upon the speed of a 'click' event in the
    environment."

    <shepazu> "If an element is removed from the DOM between mousedown
    and mouseup, no events will be dispatched for mouseup, click, or
    subsequent activation events for that element. A mouseup event will
    still be dispatched on a different element."

    "If an element is removed from the DOM during the dispatch of
    mousedown and mouseup, no events will be dispatched for mouseup,
    click, or subsequent activation events for that element. A mouseup
    event will still be dispatched on a different element."

    "If an element is removed from the DOM between mousedown or mouseup,
    no events will be dispatched for mouseup, click, or subsequent
    activation events for that element. A mouseup event will still be
    dispatched on a different element."

    "If an element is removed from the DOM dispatch mousedown or
    mouseup, no events will be dispatched for mouseup, click, or
    subsequent activation events for that element. A mouseup event will
    still be dispatched on a different element."

    <shepazu> "If an element is removed from the DOM during the dispatch
    of a mousedown event, no events for that element will be dispatched
    for mouseup, click, or subsequent activation events. A mouseup event
    will still be dispatched on a different element."

    "If an element is removed from the DOM during the mouse events
    sequence, the remaining events of the sequence will not be fired at
    that element."

    resolution: add something to the effect of what jrossi typed

    <smaug>
    [23]http://lists.w3.org/Archives/Public/www-dom/2011AprJun/0025.html

      [23] http://lists.w3.org/Archives/Public/www-dom/2011AprJun/0025.html

WebApps-ISSUE-178?

    <shepazu> WebApps-ISSUE-178?

    issue-178?

    <trackbot> ISSUE-178 -- Implementations and DOM Core allow empty
    string and null event types -- pending review

    <trackbot> [24]http://www.w3.org/2008/webapps/track/issues/178

      [24] http://www.w3.org/2008/webapps/track/issues/178

    jrossi: my recent change removed the requirement that initializing
    an event with a type of empty string or null should throw an
    exception
    ... no implementation did that, and there's not really a great
    reason to

    <smaug> WDC
    [25]http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-eve
    nttarget-dispatchevent

      [25] 
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-eventtarget-dispatchevent

    jrossi: jonas proposed that empty string not be allowed and instead
    be the indicator that an event object has yet to be initialized
    ... I replied saying that I didn't think there was any reason type
    was the correct place to expose such an API. And at any rate, my
    change lays the ground work for another spec (such as DOM Core) to
    spec how such an API (to detect whether an object has been
    initialized) would work.
    ... but that it seems like feature creep to add that to D3E at this
    point

    smaug: it's not the cleanest way to expose such an API

    shepazu: not a very intuitive way of exposing it, seems like a hack

    jrossi: agree

    resolution: spec is fine as is

    <scribe> ACTION: shepazu to clean out "issues" marked up in spec
    text [recorded in
    [26]http://www.w3.org/2011/05/11-webapps-minutes.html#action01]

    <trackbot> Created ACTION-624 - Clean out "issues" marked up in spec
    text [on Doug Schepers - due 2011-05-18].

[27]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.h
tml#event-type-DOMActivate

      [27] 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMActivate

strange DOMACtivate wording

    <shepazu>
    [28]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Event
    s.html#event-type-DOMActivate

      [28] 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMActivate

    <shepazu> [29]http://www.w3.org/TR/DOM-Level-2-Events/events.html

      [29] http://www.w3.org/TR/DOM-Level-2-Events/events.html

    <a href="[30]http://www.google.com" id="test">test</a>

      [30] http://www.google.com/

    <script>

    var elem = document.getElementById("test");

    elem.addEventListener("DOMActivate", function(e) {

    console.log(e.detail);

    e.preventDefault();

    }, false);

    </script>

    jrossi: don't see a detail property in FF for DOMActivate anyway

Next Steps

    shepazu: I can close out these issues we discussed today

    jrossi: then will you send mail to Art and the WG list to ask for a
    CfC?

    shepazu: sure

DOM Core

    shepazu: are there any outstanding descrpancies between DOM Core and
    D3E?

    jrossi: not that I'm aware of
    ... we covered those last week (and then rehashed one issue today)

    shepazu: smaug, you checked this?

    smaug: yes, we fixed these issues (dispatch through non DOM trees,
    emptystring/null event types, keeping EventException). I'm not aware
    of any others.

    shepazu: then I'll withdraw my objection to publication of DOM4 Core

    <shepazu> trackbot, end telcon?

    <trackbot> Sorry, shepazu, I don't understand 'trackbot, end
    telcon?'. Please refer to [31]http://www.w3.org/2005/06/tracker/irc
    for help

      [31] http://www.w3.org/2005/06/tracker/irc

    <shepazu> tracbot, end telcon

    <shepazu> trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: shepazu to clean out "issues" marked up in spec text
    [recorded in
    [32]http://www.w3.org/2011/05/11-webapps-minutes.html#action01]

    [End of minutes]
Received on Wednesday, 11 May 2011 18:55:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:07 GMT