Pointer Events WG Voice Conference -- 12 Feb 2013

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

<rbyers> I'm here

<slightlyoff> OH HAI

AR: Google; TAG member; lots of reviews

AB: I sent a draft agenda yesterday http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0098.html. Any change requests?
... do we want to look at the comments from Alex Russell <http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0110.html>?

RB: which subset should be take Alex?

AR: pointerID

RB: I'd like extensibility to be on the agenda

AR: ok with me

AB: any objections to adding Alex's comments to the agenda?

[None]

AB: can we get a Scribe for today?

RB: I can Scribe

<rbyers> ScribeNick rbyers

AB: thanks

pointer type extensibility

[ Rick's input http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0096.html ]

RB: lots of support for Pointer Events, at least at the high level

… heard lots of good things

… I've been thinking about extensibility for new pointer types

… Need to avoid past mistakes re extensibility

… I made a proposal

… Can move from a string to a series of booleans

… Helps to opt in for different types

JR: we have talked about extensibility before

… In the future we will have more devices

… The problem I see with booleans is not knowing what type of device it is

… It would be possible for more than one boolean prop can be true

RB: correct

JR: then how do you actually know what the device is

RB: some external doc would specifiy that

… we can't have a single property

… because that breaks when new devices are added

… need to know if a new device can emulate an "old device" e.g. touch

JR: so if trying to emulated panning, it is different interaction with touch vs mouse pointer

… would have to keep track of multiple different devices

RB: if have a new device, want to do something new, but if old device handle it

… can use isDepthCam then, do X

… concerned about complexity of composition scenarios

JR: I need to think about this some more

… is this the same as feature detection vs. browser detection

<slightlyoff> ISTM that we're trying to shoehorn generated events into a model for low-level events

<slightlyoff> (and vice-versa)

… should we be silent re device type and say something about the device capabilities

… e.g. can this device hover

… rather than what is the device called

RB: agree that might be the right approach

JR: need a minimal set of device types

… adding them means need to add more data about the new devices features

… that are unique to the new device

JR: for near future (5-10 years), touch will be the new mouse

… don't think there will be a mad rush of new pointer types

RB: not sure this is just niche scenarios

… if we do have a new device in the future, we should try to be forward compat now

<slightlyoff> aren't they just going to synthesize events the way we do with mouse for touch?

<slightlyoff> isn't synthesis the basic compat strategy?

<slightlyoff> and if it's not, is there a different one?

DS: I think this differentiation of devices versus capabilities, we should mirror that in other parts of the platform like CSSMQs

<slightlyoff> making media queries extensible from script would get you there too

… It strikes me that this is v2 features

… We can expand in v2 after we have more usage

… I don't think v1 locks us out of v2 changes

RB: wonder if if string pointer type actually ties our future

<slightlyoff> there seems to already be contention about wether or not "stylus" is binary vs. "mouse"

<asir> Doug is right ... we should take the time to think through scenarios and address them in v next

JR: there should always be some default case

… for a lot of devices, up and down are same

JR: I worry about trying to emulate past devices

… and instead promote generic pointer

AR: wonder if there is some reasonable way to back off from identifying device

… e.g. if have a pen, have pen events

… and pointer events synthesize a high level event

… want to use device independent properties

<shepazu> q

MB: I've been writing code using PE, TE, mouse events

… some times we want to do something different for "precise" devices like a pen

… for some pointers, near is good enough

… CSS MQ proposal for more precision

… perhaps we can use that

<rbyers> http://dev.w3.org/csswg/mediaqueries4/#pointer

DS: I like the precision argument

<rbyers> none, coarse and fine are the values today

… hover, pressure are key differentiators

MB: exposing pressure as a capability would be useful

DS: if we go down this route, will get complaints about device profiling

… but I like the idea

MB: can already get that fingerprinting now

DS: agree

… part of the issue is fear of using strings

… and locking into emualtion modes

<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.

… Jacob says use a generic code path and then only select on device type if have to

<slightlyoff> e.g., simply loading a page shouldn't expose more, but an event handler can

… thinks there needs to be some Best Practices

… Hope to get some related info ready by the Feb 21-22 conference

… Need a "this is the right way" to do PointerEvents

… type documentation

… We are not good at predicting what devices will be relevant in the future

… but we can talk about user's capabilities

… If we don't have concrete proposal for capabilities, need to be careful

<slightlyoff> we're not speculating, we're attempting to allow room for growth in the future

RB: agree we need to avoid speculation

… agree Education and coding practices can help

… lots of sites are broken with touch

… we provide some guidelines about how to handle the interop issues

… and the education isn't enough

[ discussion about some issues with Google maps ]

AR: I am worried about what is high level vs. low level event

… the lower level we attack, the higher the probability to do something wrong for the user

… Where do we see Pointer Events - high or low level?

RB: on IE, there is no touch events

… think we consider touch events as somethign that will go away some day

JR: I consider PE as low-level

… there are some higher level events like click, gestures, context menus

… those are easier to abstract and make work across devices

… but if using PE, they are low level events and devapps must be careful re user experience

… Not sure we need special events for each device

… Want one event model and appropriate switches that can be used when needed

DS: I would argue PE is more medium level

… it is an abstraction above things like mouse and pen

… but it is also below things like IndieUI events

… Think this spec is two-fold: higher level abstraction but one can go to lower level like device type like pens, etc.

JR: I think we are making assumptions there is always a device to emulate

<slightlyoff> but kinect isn't operating in CSS pixel space....

… There can be different interaction models with touch and pen versus devices like Kinect

<slightlyoff> any pointer event from kinect is going to be pre-processed for this API

… Think devs will always want to do something special for some devices

… But they don't want to add a new event model for every new devices

<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.

<slightlyoff> mbrubeck: mice already falsify that notion

<slightlyoff> mbrubeck: see Section 8

MB: I agree PE is a low level spec

… it is about as low level as make sense for the OWP

… maps well to motion events on Android for example

… if go any lower, it will be device specific

<slightlyoff> we've lost the call

<rbyers> Looks like we just lost the call, coming back

SG: Alex mentioned section 8

… the goal is for mouse to never to be used ever again

… Section 8 is advice for sites to switch over to PointerEvents

<slightlyoff> I can understand not wanting to expose mice again, but consider right-click...it's specific to which mouse events come in.

<slightlyoff> but I think what I'm getting at is this:

<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)

<beverloo> We're trying to dail in, ArtB

<slightlyoff> you can't *preclude* low-level input types from bleeding out...indeed, that's how we got to this point

<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

<slightlyoff> I vote for moving on to other topic

Call for Consensus to publish Last Call Working Draft of Pointer Events v1 spec.

<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)

<rbyers> AB: Either we can delay last call and try to resolve extensibility

<rbyers> … or publish last call now

<rbyers> asir: we should go to last call

<rbyers> .. and talk about what should be last call, vs. v2 issue

RB: I am concerned about extensibility and be locked iin

<slightlyoff> +1...I think it's fine to got to LC and treat these as LC comments

<rbyers> damn

<rbyers> calling again from another phone

<slightlyoff> on which network? ;-)

<scott_gonzalez> Zakim: aaaa is rbyers

DS: I don't think it is a problem to deprecate or expand the list of pointer types

<rbyers> .. multi-pronged approach, education, promoting best practices, making sure generic events (not checking pointerType) handle most of the cases

<rbyers> .. part also adding some capability profiling

<rbyers> .. and extensibility points

<rbyers> .. any disagreement?

<rbyers> [None]

<rbyers> AB: Matt, do you support last call?

<rbyers> MB: Yes

<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

<rbyers> .. Scott?

<rbyers> SG: Good to go to LC

<rbyers> Cathy: fine with last call

<rbyers> RB, PB, AR: We're good with LC too

<scribe> ACTION: Jacob - notify Art when a Pointer Events v1 LCWD is "PubReady" for Feb 19 [recorded in http://www.w3.org/2013/02/12-pointerevents-minutes.html#action01]

<trackbot> Created ACTION-22 - - notify Art when a Pointer Events v1 LCWD is "PubReady" for Feb 19 [on Jacob Rossi - due 2013-02-19].

<rbyers> RESOLUTION: Publish last call pointer events v1

<rbyers> AB: Need to include length of review period, at least 3 weeks

<rbyers> .. given we want comments from CSS, WebEvents, IndieUI, web apps

<rbyers> .. should have at least 4 weeks

<rbyers> .. any objections?

<rbyers> DS: Propose a little longer

<rbyers> .. even 6 week would be ok

<rbyers> Asir: we'll get comments quicker with a shorter period

<rbyers> DS: Good point, 4 weeks probably good

<rbyers> DS: Ok, will go with 4 week review period

<rbyers> DS: Will take testing topic to mailing list

AOB

<rbyers> DS: any implementation status?

<scribe> ACTION: barstow send a headsup to relevant WGs re PEv1 LCWD [recorded in http://www.w3.org/2013/02/12-pointerevents-minutes.html#action02]

<trackbot> Created ACTION-23 - Send a headsup to relevant WGs re PEv1 LCWD [on Arthur Barstow - due 2013-02-19].

<rbyers> AB: Call next week?

<rbyers> .. probably won't have anything to discuss

<rbyers> .. tentatively next scheduled call Feb 26

- DRAFT -

Pointer Events WG Voice Conference

12 Feb 2013

Attendees

Contents

pointer type extensibility

Call for Consensus to publish Last Call Working Draft of Pointer Events v1 spec.

AOB

Summary of Action Items

Scribe.perl diagnostic output