Draft minutes: 12 February 2013 call

The draft minutes from the February 12 voice conference are available at 
<http://www.w3.org/2013/02/12-pointerevents-minutes.html> and copied below.

WG Members - if you have any comments, corrections, etc., please send 
them to the public-pointer-events mail list before 19 February 2013. In 
the absence of any changes, these minutes will be considered approved.

-Thanks, Art

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                    Pointer Events WG Voice Conference

12 Feb 2013

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0098.html

    See also: [3]IRC log

       [3] http://www.w3.org/2013/02/12-pointerevents-irc

Attendees

    Present
           Art_Barstow, Scott_Gonzalez, Rick_Byers, Peter_Beverloo,
           Jacob_Rossi, Asir_Vedamuthu, Alex_Russell, Cathy_Chan,
           Matt_Brubeck

    Regrets
           Olli_Pettay

    Chair
           Art

    Scribe
           Art

Contents

      * [4]Topics
          1. [5]pointer type extensibility
          2. [6]Call for Consensus to publish Last Call Working
             Draft of Pointer Events v1 spec.
          3. [7]AOB
      * [8]Summary of Action Items
      __________________________________________________________

    <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
    [9]http://lists.w3.org/Archives/Public/public-pointer-events/20
    13JanMar/0098.html. Any change requests?
    ... do we want to look at the comments from Alex Russell
    <[10]http://lists.w3.org/Archives/Public/public-pointer-events/
    2013JanMar/0110.html>?

       [9] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0098.html.
      [10] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0110.html%3E?

    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
    [11]http://lists.w3.org/Archives/Public/public-pointer-events/2
    013JanMar/0096.html ]

      [11] 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> [12]http://dev.w3.org/csswg/mediaqueries4/#pointer

      [12] 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
    [13]http://www.w3.org/2013/02/12-pointerevents-minutes.html#act
    ion01]

    <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
    [14]http://www.w3.org/2013/02/12-pointerevents-minutes.html#act
    ion02]

    <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

Summary of Action Items

    [NEW] ACTION: barstow send a headsup to relevant WGs re PEv1
    LCWD [recorded in
    [15]http://www.w3.org/2013/02/12-pointerevents-minutes.html#act
    ion02]
    [NEW] ACTION: Jacob - notify Art when a Pointer Events v1  LCWD
    is "PubReady" for Feb 19 [recorded in
    [16]http://www.w3.org/2013/02/12-pointerevents-minutes.html#act
    ion01]

    [End of minutes]

Received on Tuesday, 12 February 2013 17:09:48 UTC