15:59:14 <RRSAgent> RRSAgent has joined #pointerevents
15:59:14 <RRSAgent> logging to http://www.w3.org/2013/02/12-pointerevents-irc
15:59:29 <ArtB> ScribeNick: ArtB
15:59:29 <ArtB> Scribe: Art
15:59:29 <ArtB> Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0098.html
15:59:29 <ArtB> Chair: Art
15:59:29 <ArtB> Meeting: Pointer Events WG Voice Conference
15:59:38 <ArtB> RRSAgent, make log public
15:59:45 <ArtB> RRSAgent, make minutes
15:59:45 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/12-pointerevents-minutes.html ArtB
16:00:01 <rbyers> rbyers has joined #pointerevents
16:00:10 <ArtB> RRSAgent, make log public
16:00:14 <Zakim> RWC_PEWG()11:00AM has now started
16:00:21 <Zakim> +scott_gonzalez
16:00:36 <Zakim> +Art_Barstow
16:01:22 <Zakim> +??P27
16:01:22 <rbyers> I'm here
16:01:57 <rbyers> zakim, ??P27 is me
16:01:57 <Zakim> +rbyers; got it
16:02:28 <Zakim> +Jacob_Rossi
16:02:48 <jrossi21> jrossi21 has joined #pointerevents
16:02:53 <ArtB> Present: Art_Barstow, Scott_Gonzalez, Rick_Byers, Peter_Beverloo, Jacob_Rossi
16:02:54 <Zakim> +[Microsoft]
16:03:02 <slightlyoff> slightlyoff has joined #pointerevents
16:03:08 <ArtB> Present+ Asir_Vedamuthu
16:03:28 <beverloo> beverloo has joined #pointerevents
16:03:45 <rbyers> Present+ Alex_Russell
16:03:53 <slightlyoff> OH HAI
16:03:55 <Zakim> +Cathy
16:04:05 <ArtB> Present+ Cathy_Chan
16:04:51 <ArtB> AR: Google; TAG member; lots of reviews
16:04:58 <ArtB> AB: I sent a draft agenda yesterday http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0098.html. Any change requests?
16:05:04 <ArtB> AB: do we want to look at the comments from Alex Russell <http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0110.html>?
16:05:36 <ArtB> RB: which subset should be take Alex?
16:05:40 <ArtB> AR: pointerID
16:05:51 <ArtB> RB: I'd like extensibility to be on the agenda
16:05:55 <ArtB> AR: ok with me
16:06:15 <ArtB> AB: any objections to adding Alex's comments to the agenda?
16:06:17 <ArtB> [None]
16:06:21 <Cathy> Cathy has joined #pointerevents
16:06:29 <ArtB> AB: can we get a Scribe for today?
16:06:35 <ArtB> RB: I can Scribe
16:06:35 <rbyers> ScribeNick rbyers
16:06:37 <ArtB> AB: thanks
16:06:40 <Cathy> Present+ Cathy_Chan
16:06:55 <rbyers> Topic: pointer type extensibility
16:07:15 <ArtB> [ Rick's input http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0096.html ]
16:07:35 <ArtB> RB: lots of support for Pointer Events, at least at the high level
16:07:39 <ArtB> … heard lots of good things
16:07:57 <ArtB> … I've been thinking about extensibility for new pointer types
16:08:18 <ArtB> … Need to leverage past mistakes re extensibility
16:08:30 <ArtB> s/leverage/avoid/
16:08:35 <ArtB> … I made a proposal
16:08:45 <ArtB> … Can move from a string to a series of booleans
16:08:54 <ArtB> … Helps to opt in for different types
16:09:08 <Zakim> +Doug_Schepers
16:09:24 <ArtB> JR: we have talked about extensibility before
16:09:49 <ArtB> … In the future we will have more devices
16:09:58 <rbyers> Zakim, who is noisy?
16:10:09 <Zakim> rbyers, listening for 10 seconds I heard sound from the following: Jacob_Rossi (60%), [Microsoft] (13%)
16:10:14 <ArtB> … The problem I see with booleans is not knowing what type of device it is
16:10:36 <ArtB> … It would be possible for more than one boolean prop can be true
16:10:41 <ArtB> RB: correct
16:10:51 <ArtB> JR: then how do you actually know what the device is
16:11:00 <ArtB> RB: some external doc would specifiy that
16:11:07 <ArtB> … we can't have a single property
16:11:19 <ArtB> … because that breaks when new devices are added
16:11:36 <ArtB> … need to know if a new device can emulate an "old device" e.g. touch
16:12:00 <ArtB> JR: so if trying to emulated panning, it is different interaction with touch vs mouse pointer
16:12:17 <ArtB> … would have to keep track of multiple different devices
16:13:03 <ArtB> RB: if have a new device, want to do something new, but if old device handle it
16:13:14 <asir> asir has joined #pointerevents
16:13:28 <ArtB> … can use isDepthCam then, do X
16:13:35 <shepazu> agenda+ event lists
16:14:02 <ArtB> … concerned about complexity of composition scenarios
16:14:13 <ArtB> JR: I need to think about this some more
16:14:39 <ArtB> … is this the same as feature detection vs. browser detection
16:14:52 <slightlyoff> ISTM that we're trying to shoehorn generated events into a model for low-level events
16:14:59 <slightlyoff> (and vice-versa)
16:14:59 <ArtB> … should we be silent re device type and say something about the device capabilities
16:15:08 <ArtB> … e.g. can this device hover
16:15:09 <shepazu> q+
16:15:16 <ArtB> … rather than what is the device called
16:15:30 <ArtB> RB: agree that might be the right approach
16:15:47 <ArtB> JR: need a minimal set of device types
16:16:06 <ArtB> … adding them means need to add more data about the new devices features
16:16:13 <ArtB> … that are unique to the new device
16:16:49 <ArtB> JR: for near future (5-10 years), touch will be the new mouse
16:17:04 <ArtB> … don't think there will be a mad rush of new pointer types
16:17:21 <ArtB> RB: not sure this is just niche scenarios
16:17:47 <ArtB> … if we do have a new device in the future, we should try to be forward compat now
16:17:53 <slightlyoff> aren't they just going to synthesize events the way we do with mouse for touch?
16:18:16 <slightlyoff> isn't synthesis the basic compat strategy?
16:18:22 <slightlyoff> and if it's not, is there a different one?
16:18:43 <ArtB> DS: I think this differentiation of devices versus capabilities, we should mirror that in other parts of the platform like CSSMQs
16:18:56 <slightlyoff> making media queries extensible from script would get you there too
16:19:08 <ArtB> … It strikes me that this is v2 features
16:19:17 <ArtB> … We can expand in v2 after we have more usage
16:19:28 <ArtB> … I don't think v1 locks us out of v2 changes
16:19:43 <ArtB> RB: wonder if if string pointer type actually ties our future
16:19:44 <slightlyoff> there seems to already be contention about wether or not "stylus" is binary vs. "mouse"
16:19:55 <Zakim> +Matt_Brubeck
16:20:28 <asir> Doug is right ... we should take the time to think through scenarios and address them in v next
16:20:53 <ArtB> JR: there should always be some default case
16:21:13 <ArtB> … for a lot of devices, up and down are same
16:21:40 <ArtB> Present+ Matt_Brubeck
16:21:58 <ArtB> JR: I worry about trying to emulate past devices
16:22:05 <slightlyoff> q+
16:22:09 <ArtB> … and instead promote generic pointer
16:22:50 <ArtB> AR: wonder if there is some reasonable way to back off from identifying device
16:23:00 <ArtB> … e.g. if have a pen, have pen events
16:23:15 <ArtB> … and pointer events synthesize a high level event
16:23:26 <ArtB> … want to use device independent properties
16:23:31 <slightlyoff> q-
16:23:35 <shepazu> q
16:23:35 <shepazu> q+
16:23:55 <ArtB> MB: I've been writing code using PE, TE, mouse events
16:24:12 <ArtB> … some times we want to do something different for "precise" devices like a pen
16:24:28 <ArtB> … for some pointers, near is good enough
16:24:40 <ArtB> … CSS MQ proposal for more precision
16:25:00 <ArtB> … perhaps we can use that
16:25:09 <rbyers> http://dev.w3.org/csswg/mediaqueries4/#pointer
16:25:10 <ArtB> DS: I like the precision argument
16:25:20 <rbyers> none, coarse and fine are the values today
16:25:22 <ArtB> … hover, pressure are key differentiators
16:25:39 <ArtB> MB: exposing pressure as a capability would be useful
16:25:58 <ArtB> DS: if we go down this route, will get complaints about device profiling
16:26:02 <ArtB> … but I like the idea
16:26:13 <ArtB> MB: can already get that fingerprinting now
16:26:19 <ArtB> DS: agree
16:26:31 <ArtB> … part of the issue is fear of using strings
16:26:39 <ArtB> … and locking into emualtion modes
16:26:51 <slightlyoff> fingerprinting is inevitable so long as people interact with the document. The onus is on us not to expose data *outside* of events firing.
16:27:01 <ArtB> … Jacob says use a generic code path and then only select on device type if have to
16:27:04 <slightlyoff> e.g., simply loading a page shouldn't expose more, but an event handler can
16:27:11 <ArtB> … thinks there needs to be some Best Practices
16:27:35 <ArtB> … Hope to get some related info ready by the Feb 21-22 conference
16:27:48 <ArtB> … Need a "this is the right way" to do PointerEvents
16:27:55 <ArtB> … type documentation
16:28:26 <ArtB> … We are not good at predicting what devices will be relevant in the future
16:28:37 <ArtB> … but we can talk about user's capabilities
16:29:40 <ArtB> … If we don't have concrete proposal for capabilities, need to be careful
16:29:50 <slightlyoff> we're not speculating, we're attempting to allow room for growth in the future
16:29:58 <ArtB> RB: agree we need to avoid speculation
16:30:14 <ArtB> … agree Education and coding practices can help
16:30:26 <ArtB> … lots of sites are broken with touch
16:30:47 <ArtB> … we provide some guidelines about how to handle the interop issues
16:30:57 <ArtB> … and the education isn't enough
16:31:11 <slightlyoff> q+
16:31:53 <ArtB> [ discussion about some issues with Google maps ]
16:32:11 <ArtB> AR: I am worried about what is high level vs. low level event
16:32:53 <ArtB> … the lower level we attack, the higher the probability to do something wrong for the user
16:33:05 <ArtB> … Where do we see Pointer Events - high or low level?
16:33:25 <slightlyoff> q-
16:33:30 <jrossi> q+
16:33:37 <ArtB> RB: on IE, there is no touch events
16:33:57 <ArtB> … think we consider touch events as somethign that will go away some day
16:34:05 <shepazu> q-
16:34:09 <ArtB> JR: I consider PE as low-level
16:34:14 <shepazu> q+
16:34:53 <ArtB> … there are some higher level events like click, gestures, context menus
16:35:07 <ArtB> … those are easier to abstract and make work across devices
16:35:35 <ArtB> … but if using PE, they are low level events and devapps must be careful re user experience
16:36:00 <slightlyoff> q+
16:36:04 <ArtB> … Not sure we need special events for each device
16:36:23 <ArtB> … Want one event model and appropriate switches that can be used when needed
16:36:35 <ArtB> DS: I would argue PE is more medium level
16:36:48 <ArtB> … it is an abstraction above things like mouse and pen
16:37:03 <slightlyoff> q-
16:37:11 <ArtB> … but it is also below things like IndieUI events
16:37:47 <ArtB> … Think this spec is two-fold: higher level abstraction but one can go to lower level like device type like pens, etc.
16:38:35 <ArtB> JR: I think we are making assumptions there is always a device to emulate
16:39:18 <slightlyoff> but kinect isn't operating in CSS pixel space....
16:39:20 <ArtB> … There can be different interaction models with touch and pen versus devices like Kinect
16:39:35 <rbyers> q+
16:39:36 <slightlyoff> any pointer event from kinect is going to be pre-processed for this API
16:39:44 <ArtB> … Think devs will always want to do something special for some devices
16:40:07 <ArtB> … But they don't want to add a new event model for every new devices
16:40:08 <mbrubeck> I think Pointer Events makes sense as the lowest-level for the web; it maps very directly to similar APIs provided by mobile OSes to apps, like Android's MotionEvent.  Lower-level APIs are possible (using WebUSB, e.g.?) but probably only for device- or platform-specific code that doesn't make as much sense as part of the web platform.
16:40:26 <slightlyoff> mbrubeck: mice already falsify that notion
16:40:34 <slightlyoff> mbrubeck: see Section 8
16:41:12 <jrossi> q-
16:41:27 <ArtB> MB: I agree PE is a low level spec
16:41:29 <rbyers> Zakim, who's noisy?
16:41:38 <ArtB> … it is about as low level as make sense for the OWP
16:41:40 <Zakim> rbyers, listening for 10 seconds I heard sound from the following: rbyers (24%), asir (10%)
16:41:52 <ArtB> … maps well to motion events on Android for example
16:42:03 <ArtB> … if go any lower, it will be device specific
16:42:10 <slightlyoff> we've lost the call
16:42:12 <mbrubeck> Zakim, who is here?
16:42:12 <Zakim> On the phone I see scott_gonzalez, Art_Barstow, rbyers, Jacob_Rossi, asir, Cathy, Doug_Schepers, Matt_Brubeck
16:42:14 <Zakim> On IRC I see asir, Cathy, beverloo, slightlyoff, jrossi, rbyers, RRSAgent, Zakim, mbrubeck, ArtB, scott_gonzalez, davidburns, shepazu, dfreedm, trackbot, sangwhan_
16:42:14 <rbyers> Looks like we just lost the call, coming back
16:42:20 <ArtB> SG: Alex mentioned section 8
16:42:32 <ArtB> … the goal is for mouse to never to be used ever again
16:42:51 <ArtB> … Section 8 is advice for sites to switch over to PointerEvents
16:43:02 <Zakim> -rbyers
16:43:18 <slightlyoff> I can understand not wanting to expose mice again, but consider right-click...it's specific to which mouse events come in.
16:43:38 <slightlyoff> but I think what I'm getting at is this:
16:43:40 <ArtB> rrsagent, make minutes
16:43:40 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/12-pointerevents-minutes.html ArtB
16:43:57 <shepazu> (breaking it down into basic characteristics, we have coordinates in a 3-D space, proximity and precision relative to positioned elements, and different activation behaviors including feedback… I don't see it going any more abstract than that, for low-level interfaces that might arise in the future)
16:43:58 <beverloo> We're trying to dail in, ArtB
16:44:03 <slightlyoff> you can't *preclude* low-level input types from bleeding out...indeed, that's how we got to this point
16:44:52 <Zakim> +??P27
16:44:53 <slightlyoff> having multiple types of input streams, and the fact that we're trying to figure out how to shoehorn differentiation into the API yells to me that we're trying to have it both ways
16:45:25 <slightlyoff> I vote for moving on to other topic
16:45:27 <asir> q+
16:45:45 <rbyers> q-
16:46:20 <ArtB> Topic: Call for Consensus to publish Last Call Working Draft of Pointer Events v1 spec.
16:46:21 <shepazu> (I think there are several layers of event abstraction: specific devices and pointers, generic pointers, gestures that map low-level to high-level events, and high-level intentional events like zoom or pan or undo)
16:46:37 <shepazu> q+
16:46:46 <asir> q+
16:46:54 <rbyers> AB: Either we can delay last call and try to resolve extensibility
16:46:58 <rbyers> … or publish last call now
16:47:44 <rbyers> asir: we should go to last call
16:47:58 <rbyers> .. and talk about what should be last call, vs. v2 issue
16:48:33 <ArtB> RB: I am concerned about extensibility and be locked iin
16:49:15 <slightlyoff> +1...I think it's fine to got to LC and treat these as LC comments
16:49:15 <rbyers> damn
16:49:24 <rbyers> calling again from another phone
16:49:48 <slightlyoff> on which network? ;-)
16:50:01 <Zakim> -??P27
16:50:12 <Zakim> + +44.207.346.aaaa
16:50:26 <scott_gonzalez> Zakim: aaaa is rbyers
16:50:47 <ArtB> DS: I don't think it is a problem to deprecate or expand the list of pointer types
16:51:27 <rbyers> .. multi-pronged approach, education, promoting best practices, making sure generic events (not checking pointerType) handle most of the cases
16:51:37 <rbyers> .. part also adding some capability profiling
16:51:47 <rbyers> .. and extensibility points
16:51:50 <rbyers> .. any disagreement?
16:51:52 <rbyers> [None]
16:52:14 <rbyers> AB: Matt, do you support last call?
16:52:16 <rbyers> MB: Yes
16:52:43 <rbyers> AB: We'll have at least a 4 week review period, we may indeed need to go back to another last call.  Not locking ourselves in
16:52:52 <rbyers> .. Scott?
16:52:56 <rbyers> SG: Good to go to LC
16:53:04 <rbyers> Cathy: fine with last call
16:53:24 <rbyers> RB, PB, AR: We're good with LC too
16:53:47 <ArtB> ACTION: Jacob - notify Art when a Pointer Events v1  LCWD is "PubReady" for Feb 19
16:53:47 <trackbot> Created ACTION-22 - - notify Art when a Pointer Events v1  LCWD is "PubReady" for Feb 19 [on Jacob Rossi - due 2013-02-19].
16:53:47 <rbyers> RESOLUTION: Publish last call pointer events v1
16:54:15 <rbyers> AB: Need to include length of review period, at least 3 weeks
16:54:27 <rbyers> .. given we want comments from CSS, WebEvents, IndieUI, web apps
16:54:30 <rbyers> .. should have at least 4 weeks
16:54:33 <rbyers> .. any objections?
16:54:40 <rbyers> DS: Propose a little longer
16:54:50 <rbyers> .. even 6 week would be ok
16:55:06 <rbyers> Asir: we'll get comments quicker with a shorter period
16:55:10 <rbyers> DS: Good point, 4 weeks probably good
16:55:35 <rbyers> DS: Ok, will go with 4 week review period
16:55:55 <rbyers> DS: Will take testing topic to mailing list
16:55:57 <rbyers> Topic: AOB
16:56:43 <rbyers> DS: any implementation status?
16:56:55 <smaug> smaug has joined #pointerevents
16:57:31 <ArtB> ACTION: barstow send a headsup to relevant WGs re PEv1 LCWD
16:57:31 <trackbot> Created ACTION-23 - Send a headsup to relevant WGs re PEv1 LCWD [on Arthur Barstow - due 2013-02-19].
16:59:02 <rbyers> AB: Call next week?
16:59:16 <rbyers> .. probably won't have anything to discuss
16:59:31 <rbyers> .. tentatively next scheduled call Feb 26
16:59:49 <Zakim> -Matt_Brubeck
16:59:50 <Zakim> - +44.207.346.aaaa
16:59:50 <Zakim> -scott_gonzalez
16:59:51 <Zakim> -Art_Barstow
17:00:13 <ArtB> Regrets: Olli_Pettay
17:00:21 <ArtB> RRSAgent, make minutes
17:00:21 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/12-pointerevents-minutes.html ArtB
17:03:15 <rbyers> rbyers has left #pointerevents
17:06:39 <Zakim> -Cathy
17:09:39 <ArtB> rrsagent, bye
17:09:39 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2013/02/12-pointerevents-actions.rdf :
17:09:39 <RRSAgent> ACTION: Jacob - notify Art when a Pointer Events v1  LCWD is "PubReady" for Feb 19 [1]
17:09:39 <RRSAgent>   recorded in http://www.w3.org/2013/02/12-pointerevents-irc#T16-53-47
17:09:39 <RRSAgent> ACTION: barstow send a headsup to relevant WGs re PEv1 LCWD [2]
17:09:39 <RRSAgent>   recorded in http://www.w3.org/2013/02/12-pointerevents-irc#T16-57-31