See also: IRC log
<trackbot> Date: 25 January 2011
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 25 January 2011
<scribe> Meeting: Web Events WG Voice Conference
egrets: Dzung_Tran, Anders_Höckersten, Olli_Pettay
<shepazu> trackbot, start telcon
<trackbot> Meeting: Web Events Working Group Teleconference
<trackbot> Date: 25 January 2011
<shepazu> code: 9231#
AB: a draft agenda was submitted yesterday ( http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0009.html ). Any change requests?
[ None ]
AB: earlier today, Doug announced
the availability of the "Touch Events Specification" Editor's
... thanks Doug!
<timeless_w7ip> doug: congrats on getting Hg up :)
AB: this is indeed a fresh doc,
so I don't expect everyone to have read it
... and we do have some regrets
DS: I'd like to go through
... I'll start with an introduction
... I struggled a bit and then each event is a set of lists
... and each list is a set of touch points
... and each touch point has several attributes one would associate with an event
... f.ex., for a click, get screen x+ why
... in webkit get lists and those lists have the events
... took this pretty much from Webkit impl as documented on various sources on the web
<mbrubeck> useful for comparison: http://developer.apple.com/library/safari/#documentation/UserExperience/Reference/TouchEventClassReference/TouchEvent/TouchEvent.html
DS: I did add some stuff: cx and
... I mean rx and ry
<timeless_w7ip> oh, good. i was going to complain about that (cx v. rx), i'd rather "radiusX"/"radiusY"
DS: they indicate radius of the
... need an area rather than an exact point
... so why did I use this model rather than the Mozilla model?
... I think the WebKit model has broader deployment
... Josh asked about the names I choose and about identifiers rather than an ID
... the answer is: that's the way it is done in WebKit
AB: add, as a first ED, the
contents are all up for discussion
... i.e. the spec isn't frozen :-)
<timeless_w7ip> indeed, there was a promise that we weren't going to treat first editor's content as final
MB: I've done some work on Gecko
and WK but work for Mozilla
... I submitted my comments
DS: with balls and wheels have
some stair-stepping problems
... may need to do some mapping
... for the 1st draft, I thought it would be easier to use WK model
... if there are good reasons to change, we should discuss that
MB: the two main diffs between ED
and WK impls are
... 1) touch radius
... and 2) touch enter and leave?
DS: yes, that's correct
LG: WK has keyboard modifiers on touch events
DS: oh, I forgot to add them
<timeless_w7ip> shepazu: (editorial) i think you should probably add references to the WK and Gecko docs to the References section :)
MB: it enherit from UIEvent
DS: OK; good to know; I'll change
... In my local copy, I changed to UIEvent
... will also add the keyboard stuff; should be easy to do
... re kebd modifiers, you are talking about Meta/Alt keys?
DS: is that in the touch point or
the touch interface?
... should be in same place as screenX and screenY, right?
DS: ok, control key, meta key, ...; I'll copy those from DOM 3 Events spec
<mbrubeck> Sangwhan_Moon1: are you on the call?
AB: I noticed Sangwhan has a question but I don't think he is on the call
<lgombos> WebKit latest TouchEevent - http://trac.webkit.org/browser/trunk/Source/WebCore/dom/TouchEvent.idl
LG: the URI entered is a reference for the modifiers and events for WK impl
<mbrubeck> Safari uses "long" for screen events: http://developer.apple.com/library/safari/#documentation/UserExperience/Reference/TouchEventClassReference/TouchEvent/TouchEvent.html
<timeless_w7ip> the datatype issue is that events attributes like clientX are integer-ish not float-ish
AB: any other comments Matt you want to raise now?
<Sangwhan_Moon1> I believe long would be a better option than using floats
MB: a few minor things e.g. rx
and ry attrs
... the spec should talk about the coordinate system
DS: I've updated the text to use pixels
MB: but pixels are ambigous
<Sangwhan_Moon1> as it is very unlikely that a float screen coordinate is possible in the real world
MB: in that they are device
... and used differently e.g. in CSS pixels
<timeless_w7ip> it should be in "input coordinates" consistent with how the mouse pixels work
<Sangwhan_Moon1> DOM 2 mouse events also uses long for screen coordinates
MB: If content authors will use this data, they need to relate it to a physical size
<Sangwhan_Moon1> so it would make more sense to have those in align in terms of datatypes
MB: and that would mean using something like CSS pixels
DS: I'm ok with that
... but they are already assuming the same number of pixels from pageX, pageY, etc.
MB: but those use different size pixels with mobile safari
DS: screenX and screenY should be the same
MB: true but pageX and pageY do
... not clear if rX and rY would change
... if content authors want to map rX and rY to physical lengths
... they need to know the density of the display
... assuming they are in hw pixels rather than CSS pixels
<timeless_w7ip> ... which can be done perhaps w/ CSS media queries, which is "awkward"
DS: we do need to define what we
... and reference something, probably CSS
AB: we can't leave it open in the spec, right?
MB: correct; we don't need to solve it today on this call
<Zakim> timeless_w7ip, you wanted to ask for changing "r" for "radius"
JS: would prefer "radiusX" to be consistent with screenX, ...
DS: that's fine with me (I'm
biased by SVG)
... are people ok with touch area being an ellipse?
MB: not clear what an impl should do if it doesn't have info about the area
DS: <digress>this is the
first time I've used respec; anyone else used it?
... not clear how NoExceptions is used
MB: so it does not throw an exception?
DS: I need to clarify this
... it is zero if no other value is available
JS: 1 may be better because people will try to divide by 0 and indeterminate things happen then
DS: I'm fine with using "1"
<timeless_w7ip> (technically they are rather well defined, but propogation is distressing to real users)
LG: what if someone is not using a finger but something else
DS: don't think that would be
... can't distinguish between finger or stylus
<shepazu> updated: http://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html
JS: need to be careful to not discriminate based on capabilities of users
<timeless_w7ip> [ http://www.section508.gov ]
DS: this is about distinguishing
different device capabilities (not user capabilities)
... oh, just realized I need to add pressure
<mbrubeck> Sangwhan_Moon1: no, it hasn't
<mbrubeck> Sangwhan_Moon1: agenda - http://developer.apple.com/library/safari/#documentation/UserExperience/Reference/TouchEventClassReference/TouchEvent/TouchEvent.html
<mbrubeck> wrong link
DS: and I have checked in a new version
DS: want to be flexibile on input devices
<timeless_w7ip> i fully expect each web application to butcher and mishandle various input methods
DS: to be more explicit, would
need to expose device capabilities
... eg: does this device expose pressure sensitivity
<timeless_w7ip> whereas, providing encouragement for user agents to provide a way for users to express strokes/pressure/whatever
DS: does it undertand stylus with
rX and rY
... then it adatation could be done based on feature detection
<timeless_w7ip> if a query by an web application allows a user agent to offer emulation to the user, then that might be ok
DS: and not sniffing
<lgombos> shepazu: on the latest draft "readonly attribute boolean metaKey" is still missing
DS: I don't know how to specify
that UA may specify these things
... I can add lang that some features may not be supported and UA may do customizations
JS: think the spec should encourage good behaviours
DS: I would like a concrete example, please
JS: I don't have anything to offer now
DS: I would appreciate it Josh, if you would take this to the list
<mbrubeck> When specifying capabilities like touch radius that are not available to all devices/agents, the spec could say that these attributes could represent other user-controlled inputs, at the UA's discrection.
MB: I want to talk about
... eg. which elements receive touch events
... in WK browsers, element that receives touch event
<scribe> ... continues to receive events even if the input has moved
<timeless_w7ip> [ matt believes that touchdown targets effectively are able to manage drag events because they continue to get events ]
DS: yes, I believe that is true
MB: this affects touch enter and
... if have two simultaneous touch events on different elements, then which one gets event first?
DS: wouldn't you throw 2 events?
MB: or have one event with a list
DS: I would expect 2 diff
... and each event to have both touch points
... target touches get one touch point
... but in this case there would be two events each with 2 touches items, 2 changedTouches items, and 1 targetTouches item
MB: regarding capture, think we
need to review some existing impls
... re touch/cancel event
... the ED defines 1 narrow case
... would prefer to make that more impl defined
... if tracking stops before end, should be able to cancel
DS: I'd like to define as many as
... e.g. must fire when X happens and may fire an event at other times ...
... re simultaneous touches
... do you think it would be useful to add a timestamp to each touch point?
... or, would that be useless overhead?
... May want to go thru a list to see when different touches happened
<timeless_w7ip> i'm pretty sure some dom events typically do have timestamps
<timeless_w7ip> so yes, i think it's vaguely useful
MB: can't they track that info by watching touch up and down events?
MB: so, that would just be for convenience?
MB: ok, so I have no opinion
<timeless_w7ip> oh. this is to the touch point as opposed to the touch event? if the event contains the other, then i guess it seems superfluous..
SM: preventing default behaviour from the UA
DS: I haven't gotten around to
... will try to get something into the spec before next call
... another question - regarding pressure ....
... what units should we use?
<timeless_w7ip> pressure is sometimes from 0..1
DS: a scale of 1 to 10
... an unbounded float
... should it be relative?
SM: most analog devices use 0 to 1
DS: could be boolean :)
<timeless_w7ip> x11 exposes pressure
SM: so far I haven't seen a platform that propagates pressue down to the app
<timeless_w7ip> and Qt iirc exposes it
<timeless_w7ip> you can get pressure from one of the major windows touchpad vendors if you talk to it
DS: some support exists; can do it with flash
<timeless_w7ip> http://docs.huihoo.com/qt/4.3/widgets-tablet-tabletcanvas-cpp.html is an example of a pressure aware Qt app fwiw
AB: any other urgent questions?
We have about 5 mins left
... anything else Doug?
DS: I will probably look at InkML spec for related stuff
<timeless_w7ip> http://doc.trolltech.com/4.5/qtabletevent.html#pressure uses 0..1 fwiw
AB: naturally, we want technical
discussions to continue on the list
... what about a call next week?
DS: I do intend to update the spec
<mbrubeck> if there were any platforms that use unbounded floats for pressure, it would be easy for UAs to normalize that to a 0..1 range.
DS: and we had a bunch of people that couldn't make it today
AB: tentatively have a call next
week and that would be Feb 1
... and it will be canceled if it there is no clear need to have it
<timeless_w7ip> [ http://forum.chumby.com/viewtopic.php?id=4107 -- XSPRawTouchscreenEvent ]
AB: thanks again Doug!
... meeting adjourned
RSSAgent, make minutes
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/regrests/regrets/ Succeeded: s/lenghts/lengths/ Succeeded: s/tainted/biased/ Succeeded: s/simutaneous/simultaneous/ Succeeded: s/cotrolled/controlled/ Succeeded: s/2 change events and 1 target touches/2 touches items, 2 changedTouches items, and 1targetTouches item/ Succeeded: s/1target/1 target/ Succeeded: s/simuntaneous/simultaneous/ Found ScribeNick: ArtB Found Scribe: Art Present: Art_Barstow Doug_Schepers Laszlo_Gombos Matt_Brubeck Josh_Soref Sangwhan_Moon Regrets: Dzung_Tran Anders_Höckersten Olli_Pettay Agenda: http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0009.html Found Date: 25 Jan 2011 Guessing minutes URL: http://www.w3.org/2011/01/25-webevents-minutes.html People with action items:[End of scribe.perl diagnostic output]