See also: IRC log
<trackbot> Date: 01 July 2009
<dand> Is it the same # as before i guess?
<dand> cheers
<scribe> scribenick: shepazu
shepazu: there's been traffic on
the list about testing mutation event speed
... useful info, but not directly actionable
MSjacob: I wanted to hear feedback from implementers if there is special casing for quirks mode wrt events
smaug: I don't know of any
special casing in Gecko
... does IE
MSjacob: not currently
Travis: we're working out our
general compat story for IE9
... good to know we don't have to worry about any special
casing
dand: still waiting on feedback from chromium guy
shepazu: there was discussion on the mailing list from Nakano-san
dand: that's more to do with positioning the IME window, not necessarily related to events
shepazu: yes, good discussion to have, but not necessarily stuff that needs to be in the D3E spec
dand: when you select text in a browser in an editable or non-editable regions, it would be nice to have selection events
Travis: good question, not sure what HTML5 has added for editing events
<Hixie> nothing added for editing events so far
Travis: IE does have some selection events, which we aren't particularly proud of...
<Hixie> mostly i've been waiting to see what happens with mutation events and whether anyone makes any proposals (the chrome team in particular has indicated they have some proposals they want to make this quarter regarding editing apis and events)
<Hixie> hth
Travis: we have onselectstart and
onselectchange, which do mostly the same thing
... Mozilla has onselect that fires when you are done
selecting, which IE doesn't have, but we really want it
... selectionchange is interesting, but unintuitive
<dand> @hixie, thanks. maybe i'll bring an idea they had up now after the selection conversation
Travis: I'm not sure DOM3 Events
is the right place for these, might be better in HTML5
... my rationale is that D3E focuses on DOM changes, while HTML
has more editing stuff
dand: what about key events
Travis: we could put the
selection events in D3E, but there's a lot of editing prose in
HTML5, and there would need to be close coordination
... but my chief concern is that we want to finish DOM3 Events
quickly, so I'd hesitate to add new stuff to it
shepazu: I agree
shepazu: I really want to move to
LC as soon as possible...
... please send in all actionable comments about the DOM3
Events spec, and I will make those edits
<scribe> ACTION: smaug to comment on D3E [recorded in http://www.w3.org/2009/07/01-webapps-minutes.html#action01]
<trackbot> Created ACTION-373 - Comment on D3E [on Olli Pettay - due 2009-07-08].
<scribe> ACTION: Travis to comment on D3E [recorded in http://www.w3.org/2009/07/01-webapps-minutes.html#action02]
<trackbot> Created ACTION-374 - Comment on D3E [on Travis Leithead - due 2009-07-08].
<scribe> ACTION: MSjacob to comment on D3E [recorded in http://www.w3.org/2009/07/01-webapps-minutes.html#action03]
<trackbot> Sorry, couldn't find user - MSjacob
dand: we're discussing this with
this in Chrome
... one of the problems with contenteditable is that
user-triggered actions only in generic mutations events, not
reflecting the user intent
... I'll write up a more detailed explanation
smaug: what about paste and drag and other UI events?
dand: yes, you end up having to listen to a large number of events that are irrelevant
Travis: are you looking to have something that notifies you after the change has occurred
dand: it would be good to find
out that something is about to happen, then after it is
ended
... I think we can cover most of the existing mutation event
use cases
... it would tell you that something happened, and why it
happened (paste, undo, etc.)
... I know there is something similar in HTML5
smaug: even hixie is not fond of the HTML5 writeup for undo, etc.
<Hixie> what am i not fond of? :-)
<MSjacob> @hixie: events similar to undo in the HTML5 spec
<smaug> http://www.whatwg.org/specs/web-apps/current-work/#undo
<smaug> Hixie: UndoManager
<Hixie> yeah i'm no fan of the undo manager
Travis: if I knew that I was
listening to a text input event, I could intercept, say, drop
events
... this becomes less useful when complex editing behavior is
defined, but still may be useful
dand: do people think it's a good idea to account for all events that arise from user interaction with the page?
Travis: yes, we should have a
clear motivation for each event, and explain all the results of
user interactions
... a guiding principle behind when you would want to use any
particular event
<scribe> ACTION: Travis to start writeup of guiding principles for event usage [recorded in http://www.w3.org/2009/07/01-webapps-minutes.html#action04]
<trackbot> Created ACTION-375 - Start writeup of guiding principles for event usage [on Travis Leithead - due 2009-07-08].
dand: I'd like to see those principles
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) Succeeded: s/experimenting/discussing this/ Succeeded: s/that/the HTML5 writeup for undo, etc./ Found ScribeNick: shepazu Inferring Scribes: shepazu Default Present: [Microsoft], Shepazu, smaug, dand Present: [Microsoft] Shepazu smaug dand WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 01 Jul 2009 Guessing minutes URL: http://www.w3.org/2009/07/01-webapps-minutes.html People with action items: msjacob smaug travis[End of scribe.perl diagnostic output]