See also: IRC log
<trackbot> Date: 11 May 2011
<smaug> let's see if the connection is good enough
<scribe> scribenick: jrossi
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
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?
<trackbot> ISSUE-142 -- one keydown might fire multiple keypress/textInput events -- raised
<trackbot> 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
<shepazu> http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0052.html
<shepazu> 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> http://www.w3.org/2008/webapps/track/issues/180
<shepazu> 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
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="http://www.google.com" id="test">test</a>
<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> http://lists.w3.org/Archives/Public/www-dom/2011AprJun/0025.html
<shepazu> WebApps-ISSUE-178?
issue-178?
<trackbot> ISSUE-178 -- Implementations and DOM Core allow empty string and null event types -- pending review
<trackbot> 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 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 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].
<shepazu> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMActivate
<shepazu> http://www.w3.org/TR/DOM-Level-2-Events/events.html
<a href="http://www.google.com" id="test">test</a>
<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
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
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 http://www.w3.org/2005/06/tracker/irc for help
<shepazu> tracbot, end telcon
<shepazu> trackbot, end telcon
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found ScribeNick: jrossi Inferring Scribes: jrossi Default Present: Doug_Schepers, [Microsoft], Olli_Pettay Present: Doug_Schepers [Microsoft] Olli_Pettay WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 11 May 2011 Guessing minutes URL: http://www.w3.org/2011/05/11-webapps-minutes.html People with action items: shepazu WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]