W3C home > Mailing lists > Public > public-pointer-events@w3.org > October to December 2012

Draft Minutes: 4 December 2012 call

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 04 Dec 2012 12:13:33 -0500
Message-ID: <50BE2F3D.6060403@nokia.com>
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
The draft minutes from the December 4 voice conference are available at 
<http://www.w3.org/2012/12/04-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 December 11. In the 
absence of any changes, these minutes will be considered approved.

Thanks Rick for Scribing this meeting!

-ArtB

    [1]W3C

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

                                - DRAFT -

                    Pointer Events WG Voice Conference

04 Dec 2012

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0077.html

    See also: [3]IRC log

       [3] http://www.w3.org/2012/12/04-pointerevents-irc

Attendees

    Present
           Art_Barstow, Olli_Pettay, Jacob_Rossi, Rick_Byers,
           Asir_Vedamuthu, Scott_González, Doug_Schepers,
           Matt_Brubeck

    Regrets
    Chair
           Art

    Scribe
           Art, Rick

Contents

      * [4]Topics
          1. [5]Getting started
          2. [6]announcements?
          3. [7]CfC to publish first public working draft
          4. [8]bugs
          5. [9]bug 20107 - Pointer events should indicate stylus
             eraser/inversion
          6. [10]Bug 20108 - Extend pointer events to support raw
             trackpad data
          7. [11]Bug 20108 - Clarify pointer capture behavior
          8. [12]20109 - Permitted values for pressure
             https://www.w3.org/Bugs/Public/show_bug.cgi?id=20109
          9. [13]20111 - Define compatibility mapping for touch
             events
             https://www.w3.org/Bugs/Public/show_bug.cgi?id=20111
         10. [14]20112 - pointerenter and pointerleave events
             https://www.w3.org/Bugs/Public/show_bug.cgi?id=20112
         11. [15]Pointer Events and Click; thread
             <http://lists.w3.org/Archives/Public/public-pointer-ev
             ents/2012OctDec/0072.html>
         12. [16]any other business
      * [17]Summary of Action Items
      __________________________________________________________

    <ArtB> Scribe: Art

    <ArtB> ScribeNick: ArtB

    Date: 4 December 2012

    <smaug> hmm, is it possible to teach Zakim to bind certain nick
    always to the right person

    <smaug> mbrubeck: ping

Getting started

    AB: need a scribe (cheat sheet
    <[18]http://www.w3.org/wiki/PointerEvents/Meetings#Meeting_Scri
    bes>)

      [18] http://www.w3.org/wiki/PointerEvents/Meetings#Meeting_Scribes%3E)

    RB: I can take it today but want someone else to help in the
    future

    AB: thanks Rick

    <scribe> ScribeNick: rbyers

    <ArtB> Scribe+ Rick

    Jacob: we should rotate scribe according the bugs

    <scribe> Agenda:
    [19]http://lists.w3.org/Archives/Public/public-pointer-events/2
    012OctDec/0077.html

      [19] http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0077.html

announcements?

CfC to publish first public working draft

    Art: proposal is to go ahead and publish it
    ... but Jacob is free to update the doc, eg. to reflect any
    decisions made today
    ... any objections?

    None

    <ArtB> RESOLUTION: the group agrees to publish a FPWD of
    Pointer Events

    <ArtB> ACTION: Jacob prepare a FPWD and notify Art when it is
    ready (see [20]http://www.w3.org/wiki/Webapps/SpecEditing)
    [recorded in
    [21]http://www.w3.org/2012/12/04-pointerevents-minutes.html#act
    ion01]

      [20] http://www.w3.org/wiki/Webapps/SpecEditing)

    <trackbot> Created ACTION-6 - Prepare a FPWD and notify Art
    when it is ready (see
    [22]http://www.w3.org/wiki/Webapps/SpecEditing) on Jacob Rossi
    - due 2012-12-11].

      [22] http://www.w3.org/wiki/Webapps/SpecEditing)

    Art: guess is doc will be published a week from today, or ...
    <missed>
    ... last date to publish this year is Dec 13

    Jacob: is there a CfC period?

    Art: No, resolution is good enough for you to start

    Jacob: Think I can get it in sometime this week

    <ArtB> ACTION: barstow send Transition Request for FPWD of
    Pointer Events [recorded in
    [23]http://www.w3.org/2012/12/04-pointerevents-minutes.html#act
    ion02]

    <trackbot> Created ACTION-7 - Send Transition Request for FPWD
    of Pointer Events [on Arthur Barstow - due 2012-12-11].

bugs

    Jacob: for new bugs, suggest we wait for some discussion on the
    list

bug 20107 - Pointer events should indicate stylus eraser/inversion

    <ArtB> —>
    [24]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20107

      [24] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20107

    Jacob: current spec doesn't expose erase, valid feedback.
    ... default guess: another value for the button property

    Rick: how is the button identified?

    Jacob: suggest we use the identifier from the USB HID

    <jrossi2>
    [25]http://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEve
    nts.html#chorded-button-interactions

      [25] http://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#chorded-button-interactions

    Jacob: suggest appending to this table a button #5%
    ... will send mail with suggested button name
    ... if everyone agrees, will change the spec

Bug 20108 - Extend pointer events to support raw trackpad data

    <ArtB> —>
    [26]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20108

      [26] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20108

    correction

Bug 20108 - Clarify pointer capture behavior

    Jacob: what's missing from the spec are some additional things
    IE10 does for the capture APIs:
    ... see bug for details
    ... #1 - should it be possible to capture when buttons=0?

    Olli: may need other mechanism for UA to release pointer
    capture
    ... gecko is fairly strict in it's set capture implementation
    ... probably more so than IE

    Jacob: sounds like we need some allowances for UAs to choose to
    release capture at other times

    Olli: Agree

    Jacob: in IE10, it also differs between Win7 and Win8
    ... I will think through some spec text to give more freedom
    ... to clarify, IE10 only has preview on Win7 that doesn't
    support pointer events.
    ... #4 from bug: pointer events aren't dispatched to elements
    not in the document
    ... believe this is consistent with most types of events

    Rick: touch events is very different - always capture to the
    node where they started, even once removed from the document

    Jacob: prefer not to allow events for detached element

    Rick: agree

    Jacob: #5: compat mouse events are also redirected to captured
    element
    ... to be consistent with where pointer events
    ... hearing no opposition, should we add them?

    Olli: should we limited capturing to a single document?

    Jacob: I have looked into those multi-iframe scenarios.
    ... you're not going to get access to the dom, but you will get
    co-ordinate data
    ... agree we need to be very careful.
    ... if we come up with a specific issue, we can open a bug to
    add a restrictioon

    Olli: ok

    RESOLUTION: Will add the additional pointer capture conditions
    to the spec

20109 - Permitted values for pressure
[27]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20109

      [27] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20109

    <ArtB> —>
    [28]http://lists.w3.org/Archives/Public/public-pointer-events/2
    012OctDec/0018.html

      [28] http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0018.html

    <jrossi2>
    [29]http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf

      [29] http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf

    Jacob: Input APIs in Windows are largely designed around this
    USB spec
    ... defines two different ways of looking at pressure, as
    discussed on the list
    ... uses both relative (0..127) and absolute (physical units)
    forms of pressure
    ... get the point that a more capable pen should be able to
    provide higher than normal values
    ... think we should either keep it as is, or switch to physical
    units

    Olli: clear we can't report some random value that has no
    meaning

    Rick: probably only conforming behavior on Android is to
    truncate above 1.0

    Jacob: want the property to be interoperable and mean the same
    thing

    <Asir> sorry I got dropped and reconnected

    Rick: key question is if we have only one anchor, should we
    anchor against the maximum value or some subjective indication
    of 'norma' pressure

    Jacob: related issue: how to report no support for pressure
    ... currently we report 0

    Matt: would be nice for applicatons to have one code path for
    pressure sensitive and non-pressure sensitive devices
    ... using 0 means the app must handle the two cases seperately

    Jacob: we want this to be device agnostic - don't want to
    become a device properties spec

    Jacob/Matt/Rick: agree we should simulate reasonable pressure

    Jacob: in particular, if device does not support pressure,
    value should be 0 when not in active button state, and 1 when
    it is

    RESOLUTION: if device does not support pressure, value should
    be 0 when not in active button state, and 1 when it is

    Jacob: OK, what about max vs. normal?

    Art: could rely on implementation feedback

    Rick: evidence for using 'normal' is not strong

    RESOLUTION: Keep pressure range as speced, but listen for
    implementation feedback

    shepazu: Can emulate pressure via surface area
    ... should we account for this?

    Jacob: a UA could do this, and web site wouldn't notice. So
    would be hard to call this not compliant

    shepazu: should we mention this as a note?

    Jacob: don't want to go too far in specifying device behavior
    here

    <ArtB> ACTION: barstow add doug's use case about varying touch
    pressure to v.next list [recorded in
    [30]http://www.w3.org/2012/12/04-pointerevents-minutes.html#act
    ion03]

    <trackbot> Created ACTION-8 - Add doug's use case about varying
    touch pressure to v.next list [on Arthur Barstow - due
    2012-12-11].

20111 - Define compatibility mapping for touch events
[31]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20111

      [31] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20111

    Art: any objections to touch-events mapping being done in
    webevents WG instead of pointer events wG?

    None

    RESOLUTION: Touch-event mapping is out of scope for pointer
    events WG, will be handled by web events WG instead

    <ArtB> ACTION: barstow work with Doug and Rick on defining
    Touch Events mapping in the Web Events WG [recorded in
    [32]http://www.w3.org/2012/12/04-pointerevents-minutes.html#act
    ion04]

    <trackbot> Created ACTION-9 - Work with Doug and Rick on
    defining Touch Events mapping in the Web Events WG [on Arthur
    Barstow - due 2012-12-11].

20112 - pointerenter and pointerleave events
[33]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20112

      [33] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20112

    Jacob: no opposition to adding to the spec, assuming it's the
    same definition as for mouse

    Art: any objections?

    RESOLUTION: Add pointeenter and pointerleave to spec using the
    same model as mouseenter and mouseleave

    Art: extend to 90 minutes?

    Rick: Jacob: hope/expect we won't have 90 minutes worth of bugs
    to discuss

    Doug: would have conflict

    Jacob: suggest we leave as is for at least December, and if
    we're building up a backlog we can revisit in new year
    ... if we're active on the mailing list then we can cover more
    there

Pointer Events and Click; thread
<[34]http://lists.w3.org/Archives/Public/public-pointer-events/2012Oc
tDec/0072.html>

      [34] http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0072.html%3E

    Art: seems to have resolved, follow-up on list

any other business

    Art: will have meeting next week, Doug will chair

    Rick: I may not be able to make it next week

    Doug: I will keep track
    ... and let the list know if there's a meeting next week

    Jacob: what do we need to do to get Matt permission to help
    edit the PE spec?

    Art: all members already have permission

    Jacob: OK, I'll work with Matt to make him an editor

    np Art, a few more times and I may start to get better at it
    ;-)

    <ArtB> rbyers - you are doing a GREAT job!

    <ArtB> Scribe: Rick

Summary of Action Items

    [NEW] ACTION: barstow add doug's use case about varying touch
    pressure to v.next list [recorded in
    [35]http://www.w3.org/2012/12/04-pointerevents-minutes.html#act
    ion03]
    [NEW] ACTION: barstow send Transition Request for FPWD of
    Pointer Events [recorded in
    [36]http://www.w3.org/2012/12/04-pointerevents-minutes.html#act
    ion02]
    [NEW] ACTION: barstow work with Doug and Rick on defining Touch
    Events mapping in the Web Events WG [recorded in
    [37]http://www.w3.org/2012/12/04-pointerevents-minutes.html#act
    ion04]
    [NEW] ACTION: Jacob prepare a FPWD and notify Art when it is
    ready (see [38]http://www.w3.org/wiki/Webapps/SpecEditing)
    [recorded in
    [39]http://www.w3.org/2012/12/04-pointerevents-minutes.html#act
    ion01]

      [38] http://www.w3.org/wiki/Webapps/SpecEditing

    [End of minutes]
Received on Tuesday, 4 December 2012 17:14:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:24 UTC