Minutes: DOM3 Events Telcon, 20 October 2010

Here are the minutes for the DOM3 Events Telcon of 20 October 2010:

Attendeees: Travis Leithead, Olli Pettay, James Craig, Timeless, Jacob 
Rossie, Doug Schepers
Chair: Doug Schepers
ScribeNick: Travis
  shepazu: Agenda: UIScrollRequestEvent, UIValueChangeRequestEvent, 
Scribe: Travis
  shepazu: http://www.w3.org/2008/webapps/track/products/2
shepazu: Will update the issues in Tracker...
... RAISED -- logged the issue in the system
... OPEN -- issue has been looked at during conference
... PENDINGREVIEW -- we made a change, and are waiting for opener's 
response OR they have responded and are not satisifed with our response.
... CLOSED -- We responded and the opener was satisfied.
.... POSTPONED -- we will not resolve the issue as part of DOM L3 Events.

Agenda Item 1
Agenda: UIScrollRequestEvent, UIValueChangeRequestEvent, 
Topic: Wheel and UIScrollRequest
shepazu: jcraig can you provide background on UIScrollRequest?
jcraig: Sure
... Didn't think wheel event was appropriate because UIScrollRequest is 
a semantic event versus wheel as a hardware-generated event.
... Needed the event to respond to a variety of input scenarios (like 
touch/gesture, keypress,etc.)
... ex: user presses the Spacebar key.
... if user-script cancels the wheel event it won't stop the key events 
from firing.
smaug_: If the useragent responds to the key event by causing a scroll, 
then the wheel event would also be dispatched.
shepazu: We haven't been dealing with semantic-level events in this spec.
jcraig: Another example from the spec: Whether the user can press 
Command-Z to trigger an undo request.
... I know that key events are fired as the physical keys are pressed.
... At the time the Z is down, then the expectation is that the semantic 
event would be fired.
... If not cancelled, then the regular low-level key events would be fired.
shepazu: Why do the events need to be canceled?
... If there's an undo event that has been processed, what harm do the 
subsequent key events have?
jcraig: the web app needs a way to say, 'yes' I know about this event.
  timeless_mbp: if the web application handles he ui event to undo some 
drag operation. and it also registers cmd-z (for e.g. agents that don't 
send ui events) and has an undo stack, then the application could undo a 
second transaction. similarly.
  timeless_mbp: if the web application handles a ui event for undo, but 
doesn't handle cmd-z, then the cmd-z will bubble to the useragent + 
screen reader. this could result in the useragent undoing e.g. typing/paste
  timeless_mbp: by using preventdefault, you avoid the risk of confusion 
from that
shepazu: Trying to understand...
... If we'd started from semantic events, it would be much better for 
web apps.
  jrossi joined the chat room.
... DOM L3 Events spec has moved away from that direction.
  jcraig: q+ to say that these are not "touch" interface events
... It's clear that we need a place to spec the behavior of these 
higher-level events.
  timeless_mbp: handledEvent()
... preventDefault may be the wrong way of looking at it... Might be 
something more like "suppressEvent"
(Doug isn't looking at this log)
timeless_mbp: If the app is handling both key events and undo events 
(semantic) then you inadvertantly handle the undo twice.
shepazu: Web sites will have to write content for both models for awhile.
  Zakim: jcraig, you wanted to say that these are not "touch" interface 
shepazu: Libraries like jQuery will need to handle these sceanrios, and 
we'll need to provide the right APIs for them. We can't assume that 
authors will be able to switch over to semantic events immediately.
jcraig: Mentioned previously that semantic events are within the scope 
of the touch interfaces group.
... I'm not sure about that.
shepazu: Looking for a better name for touch events working group.
  timeless_xchat joined the chat room.
... If we need to do these "intensional events" elsewhere, we might be 
able to find a home.
resolution: DOM L3 will not add UIScrollRequest, and will be considered 
in another specification. Also will not change WheelEvent.

Topic: ValueChangeRequest, DOMAttributeChangeRequestEvent
jcraig: I think ValueChangeRequest would be in the same spec as 
... We should talk about DOMAttributeChangeRequestEvent
(what a mouthful)
smaug_: Will we need this if we develop something to replace mutation 
jcraig: This isn't a direct replacement for mutation events.
... This [DACREvent] is a request for the web app to make a change to 
the attribute.
... Whereas DOMAttrModified is a notification that the change has or is 
about to happen.
shepazu: Yes, I see that this is very different from mutation events.
jcraig: With this event [DACREvent] we (ARIA) wouldn't have a need for 
DOM Mutation events.
smaug_: If we had a better mutation event, could ARIA use those?
Travis wonders what attributes would the AT want to change and why? 
(Example please?)
  timeless: q+ to talk about how one can navigate a tree without 
changing the selection
(discussion around scenarios involving screen readers and actions in the 
web app)
shepazu: Is DOMAttributeChangeRequestEvent considered on the same level 
of the other semantic events?
jcraig: Yes, though DACREvent was considered a catch-all rather than 
having to define many individual events.

Topic: Issue 170- Consider not deprecating DOMActivate.
  smaug_: see http://www.w3.org/Bugs/Public/show_bug.cgi?id=10899
  shepazu: ISSUE-170?
  trackbot: ISSUE-170 -- Consider not deprecating DOMActivate -- raised
  trackbot: http://www.w3.org/2008/webapps/track/issues/170
shepazu: User agents are all handling 'click' events. You can 'click' 
most everything, but you can't activate everything...
... applications in reality have had to adapt to the fact that 'click' 
is the new activate.
... If we do an intensional events (semantic events) spec, then having a 
generic catch-all 'activate' event in the same context as the other 
semantic events is good (and would succeed there).
... Putting DOMActivate back into DOM L3 spec as it was before, will 
probably not succeed as it was intended.
... The suppression of the lower-level events when a higher-level 
semantic event is used would need to be need (generally).
  jrossi left the chat room. (Quit: CGI:IRC)
jcraig: Having a new activate event that can suppress subsequent events 
and is more of an activate 'request' than the current after-the-fact 
notification may be much more appropriate.
shepazu: Re: Issue 170... DOMActivate not well supported across user 
agents. Again, deprecation is saying this may be removed in the future.
Resolution: Define a suitable replacement for DOMActivate in the 
semantic events spec. Do not un-deprecate DOMActivate in DOM L3 Events.
shepazu: Will review all issues and mark them with appropriate status.

Topic: lowercasing 'textInput'
shepazu: ISSUE-155?
  trackbot: ISSUE-155 -- Consider lowercasing 'text'Input' event -- raised
  trackbot: http://www.w3.org/2008/webapps/track/issues/155
RESOLUTION: We will change textInput to textinput (lowercasing it).

Topic: Next Telcon
shepazu: We will have an extended call next week to review Last Call 
items before TPAC.
... I'm adding a few new keys based on remote controls / media controls 

Received on Wednesday, 20 October 2010 18:54:53 UTC