- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 22 Feb 2011 12:16:44 -0500
- To: "public-webevents@w3.org" <public-webevents@w3.org>
- Message-ID: <4D63EF7C.30207@nokia.com>
The draft minutes from the February 22 voice conference are available at
the following and copied below:
http://www.w3.org/2011/02/15-webevents-minutes.html
WG Members - if you have any comments, corrections, etc., please send
them to the public-webevents mail list before March 22 (the next voice
conference); otherwise these minutes will be considered Approved as is.
-Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Web Events WG Voice Conference
22 Feb 2011
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0066.html
See also: [3]IRC log
[3] http://www.w3.org/2011/02/22-webevents-irc
Attendees
Present
Art_Barstow, Josh_Soref, Cathy_Chan, Matt_Brubeck,
Olli_Pettay, Laszlo_Gombos, Doug_Schepers, Sangwhan_Moon,
Dzung_Tran
Regrets
Chair
Art
Scribe
Art
Contents
* [4]Topics
1. [5]Tweak Agenda
2. [6]Issue-1 Resolve touch area re. radius and angle
3. [7]Raised Issues
4. [8]Issue-2 What should happen when a touch is dragged off
the screen
5. [9]Issue-3 Click event target after DOM mutation during
touchstart
6. [10]Issue-4 Does preventDefault on touchmove cause a
dragging motion to fire a click event?
7. [11]Issue-5 What events fire if an alert is performed
within a touch sequence?
8. [12]Issue-6 Touch targets in frames
9. [13]Issue-7 Targets for touch events: Elements or Nodes?
10. [14]AOB
* [15]Summary of Action Items
_________________________________________________________
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 22 February 2011
<smaug_> finally
Tweak Agenda
AB: I posted a draft agenda yesterday (
[16]http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/
0066.html ). The main idea is to focus the call on specific issues.
Any change requests?
[16] http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0066.html
Issue-1 Resolve touch area re. radius and angle
AB: Issue-1 ( [17]http://www.w3.org/2010/webevents/track/issues/1 )
and Action-11 (
[18]http://www.w3.org/2010/webevents/track/actions/11 )
[17] http://www.w3.org/2010/webevents/track/issues/1
[18] http://www.w3.org/2010/webevents/track/actions/11
DS: it seems reasonable
... what they are suggesting
... I read the Canonical linux spec
... However, there are aspects I don't quite understand
... The document they pointed me to is copyrighted
... Must be careful about chaning it re copyright
... I don't want to introduce mistakes nor violate copright
... I have had some conversations
... and need to follow-up with them
... We must make sure we don't violate any copyright issues
OP: is there something like this in InkML spec?
... perhaps we can use their wording
DS: it's a good idea for us to align with InkML in general
... they do talk about angle in the spec
<sangwhan> [19]http://www.w3.org/TR/InkML/
[19] http://www.w3.org/TR/InkML/
DS: but don't talk about it in quite the same way as the Linux docs
<shepazu> [20]http://www.w3.org/TR/InkML/#orientation
[20] http://www.w3.org/TR/InkML/#orientation
DS: Think of their channels as our properties
<timeless> [ InkML channels ~ DOM properties
DS: InkML channels are not identical to our properties ]
... but for our purposes, we can consider them the same
<mbrubeck> It looks like InkML's OR ("rotation (counter-clockwise
rotation about pen axis)") is equivalent to ABS_MT_ORIENTATION from
the kernel multi-touch docs, in the case where tip=ellipse.
<scribe> ACTION: doug follow up with the canonical guys re
copyrights [recorded in
[21]http://www.w3.org/2011/02/22-webevents-minutes.html#action01]
<trackbot> Created ACTION-16 - Follow up with the canonical guys re
copyrights [on Doug Schepers - due 2011-03-01].
AB: we must be very careful re IP when looking at inputs from non WG
members
DS: W3C IP commitments only cover IP from Members that were members
of the WG that created the Recommendation
... For example, if W3C Member A is not a member of Web Events, any
spec we create does not include a RF commitment from Member A
... has anyone else reviewed the Linux documentation i.e. kernel
mulit-touch
MB: I think it is a straight fwd change to what we have spec'ed now
... they address some other things we may not need to specify to the
same degree
... I have related action-11 and I hope to check something into the
ED today
... being careful re copyright
AB: does anyone else have feedback on the Linux multi-touch spec?
JS: one thing we should look at are CSS specs that added angle stuff
... we may want to look at the various proposals
... I think animations, transitions or some other may have some
stuff for us
<sangwhan> [22]http://www.w3.org/TR/css3-values/#angles
[22] http://www.w3.org/TR/css3-values/#angles
JS: We should try to be consistent if/when it makes sense
DS: looking at the InkML diagram ...
... I'll see if I can reuse their diagram
... there are 2 different angles
... the angle perpendicular to the surface
... and the angle that is circle around the midpoint
... f.ex. if the device is vert and finger is vert
... but if finger comes from a side
... we may want to address that
JS: I thought we were only talking about the ellipse distortion; but
it sounds like someone is raising the angle of incidence to the
surface
MB: I think JS is raising a different issue
... angle of pen to surface
DS: agree we should try to be consistent with CSS
... and InkML and Geolocation Device Orientation
... perhaps we should get a summary of the various angle uses
... and include a recommendation
... can you do that Josh?
JS: I think we only care about the ellipse angle
DS: there are different things we can talk about re angles
... the units
<mbrubeck> s/I'm not particularly interested in covering it.//
<mbrubeck> I didn't say that.
DS: In SVG one can have radians or degrees
... we should decide how we are going to handle this
... I can't take on the "angle summary"
... Can you do that for CSS Josh?
JS: perhaps OP or SM can do that work
AB: can someone do the analysis Doug is recommending?
DS: I won't be here for the next 3 weeks
... [so we have some time ... ]
OP: ok, I'll look into this
<timeless> [
[23]http://www.w3.org/TR/SVG/types.html#InterfaceSVGAngle ]
[23] http://www.w3.org/TR/SVG/types.html#InterfaceSVGAngle
<scribe> ACTION: olli investiage various angle-related work e.g.
InkML, CSS, SVG, ... [recorded in
[24]http://www.w3.org/2011/02/22-webevents-minutes.html#action02]
<trackbot> Created ACTION-17 - Investiage various angle-related work
e.g. InkML, CSS, SVG, ... [on Olli Pettay - due 2011-03-01].
<timeless> i think mostly the issue is that for a DOM api we're only
going to be able to expose properties with a single unit. so it's a
matter of picking / recommending the best unit.
Raised Issues
AB: we have 5-6 "raised" issues. Before we look at them, I have a
few lead in comments ...
... as we discussed last week, when an issue is created, it is
automatically tagged with a "Raised" state. From that state it can
advance to: "Open" which means we agree this is an issue; to
"Postponed" if we agree it is an issue but will not address it in
the version of the spec in which we are currently working; to
"Closed" if we will not address the issue (ever).
<mbrubeck> Degrees have at least one advantage over radians, which
is that common values can be represented exactly in floating-point
arithmetic.
AB: why do we care about issue state? It is important, especially
for those interested in our work but not directly contributing, to
keep the state of the issues up-to-date.
... for the purposes of today, it would be good to review the Raised
Issues and to at least get a sense of what, if anything, we want to
do with the issue. That is, we don't necessarily need to "address"
the issue during this call but we may want to, for example, assign
one or more actions for an issue.
<sangwhan> Probably not the best option, but following the SVGAngle
interface and indicating the unit type is also a option (although
not pretty in ECMAScript)
<shepazu> Geolocation API WG's Device Orientation spec:
[25]http://dev.w3.org/geo/api/spec-source-orientation.html
[25] http://dev.w3.org/geo/api/spec-source-orientation.html
Issue-2 What should happen when a touch is dragged off the screen
AB: this issue is in the raised state (
[26]http://www.w3.org/2010/webevents/track/issues/2 )
[26] http://www.w3.org/2010/webevents/track/issues/2
MB: I think something like touch cancel should be defined
... not sure though we can mandate it
... may not be detectable on some hardware
... as such, think we need to do some research here
... to understand how this could be done on some hw
SM: resistive screens think pen left the screen
DS: but we have other screens to consider
SM: but if spec is directed to capative only then will be trick to
do
... touch area needs to be predefined value
... from app dev view, only 1 pixel is detected
DS: I'm not suggesting we talk about 1 or the other
... we should talk about both
... and can have conditional characteristics
... e.g. "if device supports ... then must do ..."
SM: I can do some investigation here
<scribe> ACTION: moon do some investigation for Issue-2 [recorded in
[27]http://www.w3.org/2011/02/22-webevents-minutes.html#action03]
<trackbot> Created ACTION-18 - Do some investigation for Issue-2 [on
Sangwhan Moon - due 2011-03-01].
Issue-3 Click event target after DOM mutation during touchstart
AB: this issue is in the raised state (
[28]http://www.w3.org/2010/webevents/track/issues/3 )
... any comments?
[28] http://www.w3.org/2010/webevents/track/issues/3
MB: think this is part of a larger issue re how default events
translate to clicks and other mouse events
... From an impl pov, click is based on touchend event so if insert
new element
...<missed some stuff>
... Think we need to talk about when and how mouse events are fired
for browser supporting touch events
AB: any actions for this?
... Does anyone want to help move it forward?
... Otherwise, we keep it Raised
DS: I'm interested in helping but can't take on extra tasks/actions
now
Issue-4 Does preventDefault on touchmove cause a dragging motion to
fire a click event?
AB: this issue is in the raised state (
[29]http://www.w3.org/2010/webevents/track/issues/4 )
[29] http://www.w3.org/2010/webevents/track/issues/4
MB: this is part of the larger issue I just mentioned
... think we need a framework on how to address this
DS: yes, agree with MB
JS: I think Andrew is right that not blocking seems silly
... but it is too early to move this issue to another state
AB: ok; so let's leave it Raised for now
Issue-5 What events fire if an alert is performed within a touch
sequence?
AB: this issue is in the raised state (
[30]http://www.w3.org/2010/webevents/track/issues/5 )
[30] http://www.w3.org/2010/webevents/track/issues/5
OP: I updated the Issue some
JS: personally, don't want the UI to block
... A user triggering drag start won't want an alert to pop up
... gives a bad UI
MB: in spec, touchcancel there is some relevant text
JS: triggering events within an alert is bad
<mbrubeck> That's true
DS: how can this be done
JS: spec can say nested event loop results in an exception
SM: think that is a bit extreme
<mbrubeck> If we don't define alert() -> touchcancel, then there's
no event loop
SM: spec could discourage this and that may be enough
MB: Andrew said every touch start should have a touchend
... makes sense
DS: if have a cancel, need to send a touchend
<sangwhan> +1
JS: do you want 1 event or both cancel and end?
DS: a touch cancel would have a default action of touch end event
OP: agree that makes sense
... need to define when if before or after alert
... XHR is a bit trickier; if synchronous, no events while it is
handled
... should browser queue events?
<timeless> -- again, throwing is the simplest solution
<timeless> .. and it yields the best user experience :) ... plus it
discourages sync XHR
AB: any actions for Issue-5? Anyone want to help move it forward?
Issue-6 Touch targets in frames
AB: this issue is in the raised state (
[31]http://www.w3.org/2010/webevents/track/issues/6 )
... Andrew asks "How do touch events propagate when they begin on an
iframe?"
[31] http://www.w3.org/2010/webevents/track/issues/6
MB: is this addressed by some other spec?
... e.g. DOM events spec?
DS: I don't think DOM events spec addresses this
OP: correct, no spec defines event target
DS: seems like HTML since that is where frames are defined
MB: think they should be dispatched to elements within the frame
... don't think it would controversial if we define this
JS: think about narrow ad
... may have a security issue here
DS: it is related to setCapture
... which is an API/method to say all events are targeted at this
element until I say releaseCapture
<timeless> [
[32]https://developer.mozilla.org/en/DOM/element.setCapture ]
[32] https://developer.mozilla.org/en/DOM/element.setCapture
DS: if have 100x100 iframe and then move to another iframe, which
events does the iframe get?
... are mouse moves for outer frame
... from sec perspective, when it exits iframe, there should be no
more events
... unless there is a touch cancel or touch moves back
... but that could be a new touch event
JS: if device is fixed screen and app knows it
... based on event, app could figure where it is on the page
... this can permit a disclosure (leak)
AB: should we move this to Open (we will address) or leave it
Raised?
... for now leave it Raised
Issue-7 Targets for touch events: Elements or Nodes?
AB: this issue is in the raised state (
[33]http://www.w3.org/2010/webevents/track/issues/7 )
... this is from Andrew "Targets for touch events, Elements or
Nodes?"
[33] http://www.w3.org/2010/webevents/track/issues/7
SM: think it should be aligned with mouse events
MB: PPK talked about this on the list
... he thinks it is a bug that has not been fixed
... I don't know if this is accurate
... think there is consensus on the list that Elements should be the
target
... I can put text in the ED and then ask people if they have any
objections
DS: I'm OK with this
MB: there could be some cases for Node target
... but I doubt most web authors would use it
AB: I'm OK with Matt's proposal
<scribe> ACTION: brubeck to address Issue-7 [recorded in
[34]http://www.w3.org/2011/02/22-webevents-minutes.html#action04]
<trackbot> Created ACTION-19 - Address Issue-7 [on Matt Brubeck -
due 2011-03-01].
<mbrubeck> interesting...
[35]http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/events/EventT
arget.html
[35] http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/events/EventTarget.html
<scribe> ACTION: barstow Issue-7 to open [recorded in
[36]http://www.w3.org/2011/02/22-webevents-minutes.html#action05]
<trackbot> Created ACTION-20 - Issue-7 to open [on Arthur Barstow -
due 2011-03-01].
<mbrubeck> "The EventTarget interface is implemented by all Nodes in
an implementation which supports the DOM Event Model."
AB: and if no objects to Matt's proposal, Issue-7 will be closed
<smaug_> mbrubeck: what is interesting in that? In Gecko all Nodes
implement EventTarget
AOB
<mbrubeck> smaug_: Oh yeah, I guess that makes sense, for things
like mutation events.
AB: with Doug going away for 3 weeks, I think we should this time to
work on the known issues
... and not have any calls until Doug returns
... Is this OK?
MB: OK
OP: OK
SM: OK
<smaug_> timeless: yes, seems to be you
AB: next call will be March 22
... so everyone, please work on the Open and Raised issues and Open
Actions
... perhaps 1-2 weeks after we resume calls, we will be in a
position to talk about a First Public WD
... meeting adjourned
Summary of Action Items
[NEW] ACTION: barstow Issue-7 to open [recorded in
[37]http://www.w3.org/2011/02/22-webevents-minutes.html#action05]
[NEW] ACTION: brubeck to address Issue-7 [recorded in
[38]http://www.w3.org/2011/02/22-webevents-minutes.html#action04]
[NEW] ACTION: doug follow up with the canonical guys re copyrights
[recorded in
[39]http://www.w3.org/2011/02/22-webevents-minutes.html#action01]
[NEW] ACTION: moon do some investigation for Issue-2 [recorded in
[40]http://www.w3.org/2011/02/22-webevents-minutes.html#action03]
[NEW] ACTION: olli investiage various angle-related work e.g. InkML,
CSS, SVG, ... [recorded in
[41]http://www.w3.org/2011/02/22-webevents-minutes.html#action02]
[End of minutes]
Received on Tuesday, 22 February 2011 17:17:19 UTC