15:58:07 <RRSAgent> RRSAgent has joined #webevents
15:58:07 <RRSAgent> logging to http://www.w3.org/2011/02/22-webevents-irc
15:58:14 <ArtB> RRSAgent, make log public
15:58:22 <ArtB> ScribeNick: ArtB
15:58:23 <ArtB> Scribe: Art
15:58:23 <ArtB> Agenda: http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0066.html
15:58:23 <ArtB> Date: 22 February 2011
15:58:23 <ArtB> Chair: Art
15:58:23 <ArtB> Meeting: Web Events WG Voice Conference
15:58:40 <Zakim> +Cathy
16:00:02 <ArtB> Present: Art_Barstow, Josh_Soref, Cathy_Chan
16:00:11 <Zakim> + +1.206.697.aaaa
16:00:23 <mbrubeck> Zakim, aaaa is Matt_Brubeck
16:00:23 <Zakim> +Matt_Brubeck; got it
16:00:34 <ArtB> Present+ Matt_Brubeck
16:01:05 <Zakim> +[IPcaller]
16:01:10 <smaug_> finally
16:01:23 <ArtB> Present+ Olli_Pettay
16:01:23 <smaug_> Zakim, [IPcaller] is Olli_Pettay
16:01:23 <Zakim> +Olli_Pettay; got it
16:02:38 <Zakim> -Art_Barstow
16:03:16 <Zakim> +Laszlo_Gombos
16:03:55 <Zakim> +Shepazu
16:03:58 <ArtB> Present+ Laszlo_Gombos
16:04:14 <ArtB> Present+ Doug_Schepers
16:04:22 <Zakim> +Art_Barstow
16:04:35 <ArtB> Topic: Tweak Agenda
16:04:41 <ArtB> AB: I posted a draft agenda yesterday ( 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:04:41 <Zakim> +??P32
16:04:54 <ArtB> Present+ Sangwhan_Moon
16:05:00 <sangwhan> zakim, +??P32 is me
16:05:00 <Zakim> sorry, sangwhan, I do not recognize a party named '+??P32'
16:05:13 <sangwhan> zakim, who is on the call?
16:05:13 <Zakim> On the phone I see Josh_Soref, Cathy, Matt_Brubeck, Olli_Pettay, Laszlo_Gombos, Shepazu, Art_Barstow, ??P32
16:05:21 <sangwhan> zakim, ??P32 is me
16:05:21 <Zakim> +sangwhan; got it
16:05:40 <ArtB> Topic: Issue-1 Resolve touch area re. radius and angle
16:06:02 <ArtB> AB: Issue-1 ( http://www.w3.org/2010/webevents/track/issues/1 ) and Action-11 ( http://www.w3.org/2010/webevents/track/actions/11 )
16:07:07 <ArtB> DS: it seems reasonable
16:07:17 <ArtB> ... what they are suggesting
16:07:32 <ArtB> ... I read the Canonical linux spec
16:07:33 <Dzung_Tran> Dzung_Tran has joined #webevents
16:07:37 <Dzung_Tran> Present+ Dzung_Tran
16:07:42 <ArtB> ... However, there are aspects I don't quite understand
16:08:08 <ArtB> ... The document they pointed me to is copyrighted
16:08:26 <ArtB> ... Must be careful about chaning it re copyright
16:08:48 <ArtB> ... I don't want to introduce mistakes nor violoate copright
16:09:02 <timeless> s/violoate/violate/
16:09:04 <ArtB> ... I have had some conversations
16:09:13 <ArtB> ... and need to follow-up with them
16:09:31 <ArtB> ... We must make sure we don't violate any copyright issues
16:09:41 <ArtB> OP: is there something like this in InkML spec?
16:09:48 <ArtB> ... perhaps we can use their wording
16:10:06 <ArtB> DS: it's a good idea for us to align with InkML in general
16:10:20 <ArtB> ... they do talk about angle in the spec
16:10:32 <sangwhan> http://www.w3.org/TR/InkML/
16:10:33 <ArtB> ... but don't talk about it in quite the same way [as we do]
16:10:43 <shepazu> http://www.w3.org/TR/InkML/#orientation
16:10:54 <ArtB> ... Think of their channels as our properties
16:11:01 <shepazu> s/quite the same way [as we do]/quite the same way as the Linux docs/
16:11:47 <timeless> [ InkML channels ~ DOM properties
16:11:49 <ArtB> DS: InkML channels are not identical to our properties
16:11:53 <timeless> s/properties/properties ]/
16:12:01 <ArtB> ... but for our purposes, we can consider them the same
16:12:04 <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.
16:12:29 <mbrubeck> s/axis/axis)/
16:13:02 <ArtB> ACTION: doug follow up with the canonical guys re copyrights
16:13:02 <trackbot> Created ACTION-16 - Follow up with the canonical guys re copyrights [on Doug Schepers - due 2011-03-01].
16:13:30 <ArtB> AB: we must be very careful re IP when looking at inputs from non WG members
16:14:28 <ArtB> DS: W3C IP commitments only cover IP from Members that were members of the WG that created the Recommenation
16:14:39 <Zakim> -sangwhan
16:14:49 <timeless> s/Recommenation/Recommendation/
16:15:13 <Zakim> +??P0
16:15:19 <sangwhan> zakim, ??P0 is me
16:15:19 <Zakim> +sangwhan; got it
16:15:20 <ArtB> ... For example, if W3C Member A is not a member of Web Events, any spec we create does not inclue a RF commitment from Member A
16:15:35 <timeless> s/inclue/include/
16:16:43 <ArtB> DS: has anyone else reviewed the Linux documentation i.e. kernel mulit-touch
16:16:58 <ArtB> MB: I think it is a straight fwd change to what we have spec'ed now
16:17:27 <ArtB> ... they address some other things we may not need to specify to the same degree
16:17:45 <ArtB> ... I have related action-11 and I hope to check something into the ED today
16:17:51 <ArtB> ... being careful re copyright
16:18:14 <timeless> q+
16:18:18 <ArtB> AB: does anyone else have feedback on the Linux multi-touch spec?
16:18:38 <ArtB> JS: one thing we should look at are CSS specs that added angle stuff
16:18:48 <ArtB> ... we may want to look at the various proposals
16:19:12 <ArtB> ... I think animations, transitions or some other may have some stuff for us 
16:19:19 <sangwhan> http://www.w3.org/TR/css3-values/#angles
16:19:35 <ArtB> ... We should try to be consistent if/when it makes sense
16:19:54 <ArtB> DS: looking at the InkML diagram ...
16:20:06 <ArtB> ... I'll see if I can reuse their diagram
16:20:13 <ArtB> ... there are 2 different angles
16:20:22 <ArtB> .... the angle perpendicular to the surface
16:20:28 <timeless> q-
16:20:30 <ArtB> ... and the angle that is circle around the midpoint
16:20:43 <ArtB> ... f.ex. if the device is vert and finger is vert
16:20:50 <ArtB> ... but if finger comes from a side
16:20:57 <ArtB> ... we may want to address that
16:21:59 <ArtB> JS: <missed something please fill in Josh >
16:22:07 <ArtB> MB: I think JS is raising a different issue
16:22:20 <ArtB> ... angle of pen to surface
16:22:34 <ArtB> DS: agree we should try to be consistent with CSS
16:22:40 <timeless> s/<missed something please fill in Josh >/I thought we were only talking about the ellipse distortion; but it sounds like someone is raising the angle of incidence to the surface/
16:22:50 <ArtB> ... and InkML and Geolocation Device Orientation 
16:23:08 <ArtB> DS: perhaps we should get a summary of the various angle uses 
16:23:21 <ArtB> ... and include a recommendation
16:23:25 <ArtB> ... can you do that Josh?
16:24:08 <ArtB> JS: I think we only care about the ellipse angle
16:24:19 <ArtB> DS: there are different things we can talk about re angles
16:24:26 <ArtB> ... the units
16:24:35 <mbrubeck> s/I'm not particularly interested in covering it.//
16:24:37 <mbrubeck> I didn't say that.
16:25:01 <ArtB> ... In SVG one can have radians or degrees
16:25:17 <ArtB> ... we should decide how we are going to handle this
16:25:31 <ArtB> ... I can't take on the "angle summary"
16:25:46 <ArtB> ... Can you do that for CSS Josh?
16:25:56 <ArtB> JS: perhaps OP or SM can do that work
16:26:23 <ArtB> AB: can someone do the analysis Doug is recommending?
16:26:37 <ArtB> DS: I won't be here for the next 3 weeks 
16:27:04 <ArtB> ... [so we have some time ... ]
16:27:16 <ArtB> OP: ok, I'll look into this
16:27:21 <timeless> [ http://www.w3.org/TR/SVG/types.html#InterfaceSVGAngle ]
16:27:37 <ArtB> ACTION: olli investiage various angle-related work e.g. InkML, CSS, SVG, ...
16:27:37 <trackbot> Created ACTION-17 - Investiage various angle-related work e.g. InkML, CSS, SVG, ... [on Olli Pettay - due 2011-03-01].
16:27:58 <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.
16:28:20 <ArtB> Topic: Raised Issues
16:28:28 <ArtB> AB: we have 5-6 "raised" issues. Before we look at them, I have a few lead in comments ...
16:28:37 <ArtB> AB: 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).
16:29:25 <mbrubeck> Degrees have at least one advantage over radians, which is that common values can be represented exactly in floating-point arithmetic.
16:29:29 <ArtB> 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.
16:29:52 <ArtB> AB: 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.
16:30:48 <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)
16:31:14 <shepazu> Geolocation API WG's Device Orientation spec: http://dev.w3.org/geo/api/spec-source-orientation.html
16:31:29 <ArtB> Topic: Issue-2 What should happen when a touch is dragged off the screen
16:31:36 <ArtB> AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/2 )
16:32:13 <ArtB> MB: I think something like touch cancel should be defined
16:32:21 <ArtB> ... not sure though we can mandate it
16:32:31 <ArtB> ... may not be detectable on some hardware
16:32:43 <ArtB> ... as such, think we need to do some research here
16:32:54 <ArtB> ... to understand how this could be done on some hw
16:33:11 <ArtB> SM: resistive screens think pen left the screen
16:33:20 <ArtB> DS: but we have other screens to consider
16:33:52 <ArtB> SM: but if spec is directed to capative only then will be trick to do
16:34:09 <ArtB> ... touch area needs to be predefined value
16:34:20 <ArtB> ... from app dev view, only 1 pixel is detected
16:34:32 <ArtB> DS: I'm not suggesting we talk about 1 or the other
16:34:37 <ArtB> ... we should talk about both
16:34:47 <ArtB> ... and can have conditional characteristics
16:35:01 <ArtB> ... e.g. "if device supports ... then must do ..."
16:35:09 <ArtB> SM: I can do some investigation here
16:35:38 <ArtB> ACTION: moon do some investigation for Issue-2
16:35:39 <trackbot> Created ACTION-18 - Do some investigation for Issue-2 [on Sangwhan Moon - due 2011-03-01].
16:36:10 <ArtB> Topic: Issue-3 Click event target after DOM mutation during touchstart
16:36:16 <ArtB> AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/3 )
16:36:48 <ArtB> AB: any comments?
16:38:17 <ArtB> MB: think this is part of a larger issue re how default events translate to clicks and other mouse events
16:38:39 <ArtB> ... From an impl pov, click is based on touchend event so if insert new element
16:38:55 <ArtB> ... <missed some stuff >
16:39:16 <ArtB> ... Think we need to talk about when and how mouse events are fired for browser supporting touch events
16:40:00 <ArtB> AB: any actions for this?
16:40:08 <ArtB> ... Does anyone want to help move it forward?
16:40:27 <ArtB> ... Otherwise, we keep it Raised
16:41:06 <ArtB> DS: I'm interested in helping but can't take on extra tasks/actions now
16:41:22 <ArtB> Topic: Issue-4 Does preventDefault on touchmove cause a dragging motion to fire a click event?
16:41:35 <ArtB> AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/4 )
16:42:21 <ArtB> MB: this is part of the larger issue I just mentioned
16:42:33 <ArtB> ... think we need a framework on how to address this
16:42:39 <ArtB> DS: yes, agree with MB
16:43:10 <ArtB> JS: I Andrew is right that not blocking seems silly
16:43:20 <ArtB> ... but it is too early to move this issue to another state
16:43:33 <ArtB> AB: ok; so let's leave it Raised for now
16:43:39 <timeless> s/I Andrew/I think Andrew/
16:43:44 <ArtB> Topic: Issue-5 What events fire if an alert is performed within a touch sequence?
16:43:53 <ArtB> AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/5 )
16:44:31 <ArtB> OP: I updated the Issue some
16:45:13 <ArtB> JS: personally, don't want the UI to block
16:45:38 <ArtB> ... A user triggering drag start won't want an alert to pop up
16:45:48 <ArtB> ... gives a bad UI
16:46:04 <ArtB> MB: in spec, touchcancel there is some relevant text
16:46:41 <ArtB> JS: triggering events within an alert is bad
16:46:59 <mbrubeck> That's true
16:47:01 <ArtB> DS: how can this be done
16:47:20 <ArtB> JS: spec can say nested event loop results in an exception
16:47:27 <ArtB> SM: think that is a bit extreme
16:47:41 <mbrubeck> If we don't define alert() -> touchcancel, then there's no event loop
16:49:07 <ArtB> SM: spec could discourage this and that may be enough
16:49:49 <ArtB> MB: Andrew said every touch start should have a touchend
16:49:56 <ArtB> ... makes sense
16:50:07 <ArtB> DS: if have a cancel, need to send a touchend
16:50:22 <sangwhan> +1
16:50:43 <ArtB> JS: do you want 1 event or both cancel and end?
16:50:59 <ArtB> DS: a touch cancel would have a def action of touch end event
16:51:11 <ArtB> s/def action/default action/
16:51:26 <ArtB> OP: agree that makes sense
16:51:40 <ArtB> ... need to define when if before or after alert
16:52:23 <ArtB> ... XHR is a bit trickier; if synchronous, no events while it is handled
16:52:32 <ArtB> ... shoul browser queue events?
16:52:36 <timeless> s/shoul/should/
16:52:53 <timeless> -- again, throwing is the simplest solution
16:53:12 <timeless> .. and it yields the best user experience :) ... plus it discourages sync XHR
16:53:26 <ArtB> AB: any actions for Issue-5? Anyone want to help move it forward?
16:53:55 <ArtB> Topic: Issue-6 Touch targets in frames
16:54:06 <ArtB> AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/6 )
16:54:29 <ArtB> AB: Andrew asks "How do touch events propagate when they begin on an iframe?"
16:54:38 <ArtB> MB: is this addressed by some other spec?
16:54:44 <ArtB> ... e.g. DOM events spec?
16:54:54 <ArtB> DS: I don't think DOM events spec addresse this
16:55:06 <ArtB> OP: correct, no spec defines event target
16:55:11 <timeless> s/addresse/addresses/
16:55:18 <ArtB> DS: seems like HTML since that is where frames are defined
16:55:30 <ArtB> MB: think they should be dispatched to elements within the frame
16:55:40 <ArtB> ... don't think it would controversial if we define this
16:55:54 <ArtB> JS: think about narrow add
16:56:02 <timeless> s/add/ad/
16:56:07 <ArtB> ... may have a security issue here
16:56:17 <ArtB> DS: it is related to setCapture
16:56:47 <ArtB> ... which is an API/method to say all events are targeted at this element until I say releaseCapture
16:56:54 <timeless> [ https://developer.mozilla.org/en/DOM/element.setCapture ]
16:57:21 <ArtB> DS: if have 100x100 iframe and then move to another iframe, which events does the iframe get?
16:57:38 <ArtB> ... are mouse moves for outer frame
16:57:59 <ArtB> ... from sec perspective, when it exits iframe, there should be no more events
16:58:09 <ArtB> ... unless there is a touch cancel or touch moves back
16:58:19 <ArtB> ... but that could be a new touch event
16:59:03 <ArtB> JS: if device is fixed screen and app knows it
16:59:16 <ArtB> ... based on event, app could figure where it is on the page
16:59:31 <ArtB> ... this can permit a disclosure (leak)
17:00:21 <ArtB> AB: should we move this to Open (we will address) or leave it Raised?
17:00:31 <ArtB> ... for now leave it Raised
17:00:59 <ArtB> Topic: Issue-7 Targets for touch events: Elements or Nodes?
17:01:06 <ArtB> AB: this issue is in the raised state ( http://www.w3.org/2010/webevents/track/issues/7 )
17:01:17 <sangwhan> q+
17:01:40 <timeless> ack sangwhan 
17:01:41 <ArtB> AB: this is from Andrew "Targets for touch events, Elements or Nodes?"
17:02:04 <ArtB> SM: think it should be aligned with mouse events
17:02:11 <sangwhan> q-
17:02:27 <ArtB> MB: PPK talked about this on the list
17:02:37 <ArtB> ... he thinks it  is a but that has not been fixed
17:02:42 <mbrubeck> s/but/bug/
17:02:44 <ArtB> ... I don't know if this is accurate
17:03:35 <ArtB> MB: think there is consensus on the list that Elements should be the target
17:03:59 <ArtB> ... I can put text in the ED and then ask people if they have any objections
17:04:13 <ArtB> DS: I'm OK with this
17:04:33 <ArtB> MB: there could be some cases for Node target
17:04:45 <ArtB> ... but I doubt most web authors would use it
17:04:51 <Zakim> -Laszlo_Gombos
17:05:00 <ArtB> AB: I'm OK with Matt's proposal
17:05:26 <ArtB> ACTION: brubeck to address Issue-7
17:05:26 <trackbot> Created ACTION-19 - Address Issue-7 [on Matt Brubeck - due 2011-03-01].
17:05:35 <mbrubeck> interesting... http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/events/EventTarget.html
17:05:43 <ArtB> ACTION: barstow Issue-7 to open
17:05:43 <trackbot> Created ACTION-20 - Issue-7 to open [on Arthur Barstow - due 2011-03-01].
17:05:45 <mbrubeck> "The EventTarget interface is implemented by all Nodes in an implementation which supports the DOM Event Model."
17:06:04 <ArtB> AB: and if no objects to Matt's proposal, Issue-7 will be closed
17:06:46 <smaug_> mbrubeck: what is interesting in that? In Gecko all Nodes implement EventTarget
17:06:58 <ArtB> Topic: AOB
17:07:54 <mbrubeck> smaug_: Oh yeah, I guess that makes sense, for things like mutation events.
17:08:19 <ArtB> AB: with Doug going away for 3 weeks, I think we should this time to work on the known issues
17:08:27 <ArtB> ... and not have any calls until Doug returns
17:08:30 <ArtB> ... Is this OK?
17:08:32 <Zakim> -Matt_Brubeck
17:08:38 <ArtB> MB: OK
17:08:48 <ArtB> OP: OK
17:08:49 <ArtB> SM: OK
17:09:46 <smaug_> timeless: yes, seems to be you
17:09:47 <ArtB> AB: next call will be March 22
17:10:07 <ArtB> AB: so everyone, please work on the Open and Raised issues and Open Actions
17:10:52 <ArtB> AB: perhaps 1-2 weeks after we resume calls, we will be in a position to talk about a First Public WD
17:11:01 <Zakim> -Olli_Pettay
17:11:03 <Zakim> -Josh_Soref
17:11:03 <ArtB> AB: meeting adjourned
17:11:06 <Zakim> -Cathy
17:11:10 <Zakim> -Shepazu
17:11:13 <ArtB> RRSAgent, make minutes
17:11:13 <RRSAgent> I have made the request to generate http://www.w3.org/2011/02/22-webevents-minutes.html ArtB
17:11:16 <Zakim> -sangwhan
17:11:35 <Zakim> -Art_Barstow
17:11:37 <Zakim> RWC_()11:00AM has ended
17:11:38 <Zakim> Attendees were Josh_Soref, Art_Barstow, Cathy, +1.206.697.aaaa, Matt_Brubeck, Olli_Pettay, Laszlo_Gombos, Shepazu, sangwhan
17:11:49 <ArtB> zamim, bye
17:11:59 <sangwhan> zakim, bye
17:11:59 <Zakim> Zakim has left #webevents
17:18:12 <ArtB> rrsagent, bye
17:18:12 <RRSAgent> I see 5 open action items saved in http://www.w3.org/2011/02/22-webevents-actions.rdf :
17:18:12 <RRSAgent> ACTION: doug follow up with the canonical guys re copyrights [1]
17:18:12 <RRSAgent>   recorded in http://www.w3.org/2011/02/22-webevents-irc#T16-13-02
17:18:12 <RRSAgent> ACTION: olli investiage various angle-related work e.g. InkML, CSS, SVG, ... [2]
17:18:12 <RRSAgent>   recorded in http://www.w3.org/2011/02/22-webevents-irc#T16-27-37
17:18:12 <RRSAgent> ACTION: moon do some investigation for Issue-2 [3]
17:18:12 <RRSAgent>   recorded in http://www.w3.org/2011/02/22-webevents-irc#T16-35-38
17:18:12 <RRSAgent> ACTION: brubeck to address Issue-7 [4]
17:18:12 <RRSAgent>   recorded in http://www.w3.org/2011/02/22-webevents-irc#T17-05-26
17:18:12 <RRSAgent> ACTION: barstow Issue-7 to open [5]
17:18:12 <RRSAgent>   recorded in http://www.w3.org/2011/02/22-webevents-irc#T17-05-43