W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2013

Draft minutes: 16 April 2013 call

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 16 Apr 2013 13:29:24 -0400
Message-ID: <516D8A74.9070603@nokia.com>
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
The draft minutes from the April 16 voice conference are available at 
<http://www.w3.org/2013/04/16-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 April 23. In the 
absence of any changes, these minutes will be considered approved.

Thanks to Rick for taking the minutes!

-Thanks, ArtB


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

                                - DRAFT -

                    Pointer Events WG Voice Conference

16 Apr 2013


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

    See also: [3]IRC log

       [3] http://www.w3.org/2013/04/16-pointerevents-irc


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





      * [4]Topics
          1. [5]Getting started
          2. [6]proposal to remove requirement that pointer ID 1 is
             reserve for mouse
          3. [7]Email from Francois - setting a cpature on offshore
          4. [8]Bug Pointer out firing before pointer cancel
          5. [9]moving pointer events spec to CR
          6. [10]testing
          7. [11]CR exit criteria
          8. [12]testing
          9. [13]any other business
      * [14]Summary of Action Items

    <ArtB> ScribeNick: ArtB

    <scribe> Scribe: Art

    <jrossi2> phone issues....calling

Getting started

    AB: I posted a draft agenda yesterday
    ... it may make sense to move topic #2 (LC comment processing)
    after #3, #4 and #5. Is that OK?

      [15] http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0087.html.

    [ Yes'es ]

    AB: any other change requests?
    ... can I get a volunteer to scribe today's meeting? Scribe
    "cheat sheet" is

      [16] http://www.w3.org/wiki/PointerEvents/Meetings#Meeting_Scribes.

proposal to remove requirement that pointer ID 1 is reserve for mouse

    <rbyers> ScribeNick: rbyers


      [17] http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0072.html

    <ArtB> Feb 26 Alex argued pointerID should be opaque

      [18] http://www.w3.org/2013/02/26-pointerevents-minutes.html#item05

    <ArtB> March 12 we agreed to add a non-normative note that the
    id is implementation specific

      [19] http://www.w3.org/2013/03/12-pointerevents-minutes.html

    AB: but we've got some people in WG that feel we should drop
    this requirement
    ... Jacob, you argued it had some good use cases, right?

    JR: Two separate issues: 1) whether it's an integer or not -
    that has use cases and general agreement that integer is
    sometimes usefull
    ... 2) whether or not mouse is 1
    ... no specific use cases

    RB: I think last time we discussed, many agreed it seemed
    wrong, but we applied 'can we live with it' test

    AB: Jacob, do you object to removing it?

    JR: I agree it's not the best design, but IE may not be able to
    ... what's the right way forward? Can we mark it as at-risk in
    the CR spec?

    SG: IE implementation wouldn't have to change, spec just
    shouldn't force that behavior

    <chaals> [lurking: Does the proposal say mouse MUST not be 1 ?]

    JR: if we decide IE can't change, then it means there's a
    compat burden that other browsers might feel compelled to work
    ... so then it should be in the spec
    ... but I'm not opposed to removing this, I doubt there's much
    compat burden
    ... I just don't wouldn't want to reset last call for thiswant
    to reset last call

    AB: I think this could be considered a non-substantive bug fix

    DS: we can mark it as at-risk

    <chaals> [Which is what I thought, and which would not break IE
    conformance, right?]

    JR: can we just remove it as non-substative?
    ... view it as removing a contradiction in the spec

    DS: I think it's border line. Substantive -> would it change an
    ... would it change someone's review of the specification?
    ... an implementation might change, but wouldn't force them to
    ... is that fair?

    JR/AB: yes, agree

    DS: I think we could get away with a change before CR here

    OP: Should we explicitly say that implementations should choose
    randomly for mouse? Eg. so Gecko doesn't implement the same
    pattern as IE

    <ArtB> [[

    <ArtB> The pointerId selection algorithm is implementation
    specific. Therefore authors cannot assume values convey any
    particular meaning other than an identifier for the pointer
    that is unique from all other active pointers. As an example,
    values are not guaranteed to be monotonically increasing.

    <ArtB> ]]

    AB: Is this note sufficient?

    <jrossi2> for example, pointerType has changed from int to
    string....developers *will* have to change substantially when
    IE updates to spec

    OP: Right now problem is that IE is the only implementation,
    easy for everyone to copy this
    ... I think the spec should say that it's a random integer

    SG: seem's this is an artificial problem, there's already an
    explicit way to test for mouse - seems unlikely people would
    rely on '1'

    <ArtB> could s/implementation specific/implementation specific
    e.g. random/

    JR: spec doesn't say random, but it implies developers must
    treat it as random

    DS: I agree

    OP: I'd hope this could be codified as a requirement for

    AB: If we can get agreement on dropping, then during CR we can
    see if there's a real problem with hard-wiring 1
    ... we'll learn a lot more during CR phase
    ... Does anyone consider dropping pointer ID 1 as a substantive

    RB: I think it would be if we did what Oli suggests and require
    random, otherwise no

    Hearing no-one

    AB: Does anyone object to deleting these two sentences?


    RESOLUTION: Remove sentences requiring mouse to have pointerID
    1 as a non-substantive change

    AB: anything else?
    ... Sregey felt strongly about this

Email from Francois - setting a cpature on offshore element


      [20] http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0084.html

    AB: no response yet
    ... should we address now, or consider as CR comment?

    JR: inline with discussion last week, this would be a CR
    ... this is brand new

    AB: any objections?


    SG: are we going to discuss the other part (capture pointer on
    event) separately?

    AB: I thought we'd consider the entire comment as a CR comment,
    did you want to deal with part of it now?

    SG: What happens if it's CR comment?

    AB: We deal with it after CR published
    ... changes could bring us back to last call

    SG: One thing that seemed to come out of comments Sergey had
    was that allowing arbitrary pointer capture does seem kind of
    ... for the common cases, there doesn't seem to be any
    disadvantage to always capture on the event target

    Damn, sorry Art - not sure what's wrong with me today - I blame
    a cold...

    JR: First I think there's a ton of interest in the topics we've
    slated for v2, I suspect folks will want to start that quickly
    ... not worried about v2 being years and years down the road
    ... Secondly, I think there's multiple ways to handle this
    problem - don't think it's as bad as what's being described on
    the list.
    ... Do we hold back what's currently in the spec to fix the
    issue? I'd say it's more important to deliver the spec as it
    ... We haven't in practice hit this issue, eg. the java script
    library included with windows 8 apps uses pointer capture
    heavily, and I haven't heard any feedback that it's an issue
    ... I think it's interesting to continue a discussion on, just
    doesn't seem sufficiently critical to hold back the rest of the

    SG: Makes sense. Does the win8 library only capture to the
    event target?

    JR: No, the sometimes capture to other elements, and they don't
    always take capture so they can be exposed to scenarios where
    apps steal capture from them
    ... one idea for dealing with this is that an event fires when
    someone steals capture away from you

    SG: I'm fine waiting, considering this a CR comment

    AB: How to track these?

    JR: How about I open up bugzilla bugs for each change and
    resolve them so we have one place?

    AB: Fine with me, so how do we make sure we come back to it?

    JR: Just don't resolve the bug, use milestone field or
    ... tag it as CR as some way

    <jrossi2> ACTION: jrossi to open up CR bug for pointer capture
    issues [recorded in

    <trackbot> Created ACTION-40 - Open up CR bug for pointer
    capture issues [on Jacob Rossi - due 2013-04-23].

    DS: Anything else on Francois comment?
    ... need resolution or is bug good enough?

    RESOLUTION: Not going to block last call on Francois issue
    setting capture on offshore element

Bug Pointer out firing before pointer cancel

    <ArtB> [22]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21686

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


      [23] https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-pointercancel-event

    JR: Spec says that when you fire pointercancel, UA must fire
    pointerout AFTER the cancel
    ... feedback was firing pointerout before hand would make more
    sense (odd to get event after cancel)
    ... the wrote a test case and found IE10 behaves this way
    ... so either IE10 doesn't match or we change the spec
    ... don't have a strong preference, don't view it as being too

    DS: You might want to know why the pointer was out - you'd want
    the cancel event first

    SG: Nice having parity between pointerup and pointercancel

    JR: Yeah this is the way up works

    AB: So is there agreement that the spec needs to change?

    JR: Leaning towards not changing this

    SG: the way the spec is worded, pointercancel behaves exactly
    the same as pointerup, and code would likely to be written this
    ... easy to argue both ways
    ... having the parity with up makes it simple to reason about
    ... hard to come up with cases where one or the other will
    cause a problem
    ... unless there's some important reason that MS had for going
    the other way

    JR: No, I don't think there is. I think this could end up being
    an issue for us
    ... could be an issue (unrelated to pointer events) - delaying
    click event for double-tap to zoom, and sites adding click
    handler on over and removing on out
    ... could see a similar problem here

    RB: I agree

    AB: Any objections to a resolution to leave as is?

    JR: Already opened bug on current IE10 behavior

    RESOLUTION: Pointer out firing after pointer cancel is intended
    design, resolve spec bug as an IE bug

    AB: Revision history / last call comments needed in spec

    JR: rev history already there, will get last call comments via
    bugs - will ping you later today

moving pointer events spec to CR

    AB: Does anyone object to asking the director to publish CR of
    PointerEvents v1?
    ... or support?

    <jrossi2> No, Microsoft supports publishing CR

    AB: Nokia supports it

    RB: I support it

    DS: From w3C perspective, seems like everyone was followed
    appropriately, I support going to CR

    Asir: I support as well

    <asir> That was Scott G

    SG: I support as well

    OP: No objections

    RESOLUTION: Group agrees to publish CR of PointerEvents v1


    AB: pointer events was a topic for last weekends test the web
    forward in Seattle. Jacob was there.
    ... got test assertions and test cases from some of the

    Asir: do we need to discuss CR exit criteria first?

    AB: Yes

CR exit criteria

    AB: We need to define the CR exit criteria and the time period

    DS: I don't think we have to say anything about what we think
    the duration will be.
    ... we can say what we hope

    <ArtB> [24]http://www.w3.org/TR/2011/CR-touch-events-20111215/

      [24] http://www.w3.org/TR/2011/CR-touch-events-20111215/

    <ArtB> [[

    AB: Can say 'we don't expect to advance to proposed
    recommendation before ....'

    <ArtB> During the Candidate Recommendation period, the WG will
    complete its [25]http://dvcs.w3.org/hg/webevents/ and two or
    more independent implementations must pass each test before the
    specification exits Candidate Recommendation. The group will
    also create an Implementation Report.

      [25] http://dvcs.w3.org/hg/webevents/

    <ArtB> ]]

    DS: Right, we can do that
    ... criteria: at least 2 (preferably more) interoperable

    AB: So what I wrote in IRC above?

    DS: Yes, that's exactly how I would have phrased it [sorry,
    don't have access to IRC right now]

    <ArtB> [[

    <ArtB> This Candidate Recommendation is expected to advance to
    Proposed Recommendation no earlier than 15 March 2012. All
    feedback is welcome.

    <ArtB> ]]

    DS: could give a range - not before and targeting sometime

    AB: Above is from touch events
    ... 3 months

    DS: But didn't say aiming at

    <asir> 3 months is reasonable

    DS: would be nice to set expectations in community, goal for
    implementations, and expectations when to start adressing
    issues for v2
    ... we don't have to do this, but would be a nice touch

    AB: I think it would be a good idea
    ... Any objections to re-using the same language for criteria?

    JR: Is each implementation required to pass every test?
    ... eg. no-one passes all of CSS 2.1

    DS: We decide what the fundamental tests are

    <asir> Should amend the language as 'must pass each feature'

    JR: I think there's value in having tests that aren't
    considered part of the criteria
    ... more testing is great for implementors, but we should be
    able to mark some as lower priority

    DS: We could change language form 'tests' to 'features'

    AB: Ok with me. Intent is not that each implementation must
    pass 100% of every test/feature, it was that each test/feature
    has two passing implementations

    DS: eg. of 100 tests, 3 browsers might each pass 90 of them,
    with each test passing on at least 2 implementations
    ... we're not testing compatibility, we're testing

    JR: Eg. if there's only gecko and IE but IE still has the
    pointercancel/pointerout bug - seems like that shouldn't block

    DS: I disagree - that's not the spirit

    JR: is a feature every normative statement in the spec?

    DS: Yes
    ... pragmatic reason: we need to improve interoperability
    ... also could have political / process implications

    JR: I think this is fine, it also means we must be deliberate
    about tests that we accept into the official test suite

    DS: Yes we do need to be selective - ensuring we test normative
    statements, but not going beyond with too much detail beyond
    what we need

    AB: My expectation is WG will agree on set of tests
    ... Jacob, do you have enough to enter exit criteria into the

    JR: Will use sentences from above, update comment document,
    prep CR ... yep

    <ArtB> "This Candidate Recommendation is expected to advance to
    Proposed Recommendation no earlier than 15 March 2012. All
    feedback is welcome."

    AB: Can't give fixed date yet
    ... Agreement that we should add something like this? Second,
    what's the duration?

    <asir> that is fine to include

    RB: Doug was arguing we should include a statement about when
    we should target?

    DS: Yes
    ... What's the earliest we think this could be passing?

    OP: Do nightly builds count?

    JR: For the purposes of test suites, I thought nightly builds
    ... think we even used IE platform preview in the past

    DS: Yes, I think so

    AB: I support including nightly builds, did that with web
    storage and touch events

    DS: Olli, how quickly could it get into a nightly build?

    OP: Not up to me, but something like 3 months

    DS: Ok, no sooner than 3 months
    ... aim for 5 months?
    ... Would phrase something like 'This candidate recommendation
    is expected to advance to Proposed Recommendation no early than
    15 July 2013 and no later than 1 Oct 2013."

    AB: I don't object but I'd personally stop after the first

    DS: Maybe this isn't the time to be this agressive
    ... why don't we stick to what we have for now, and think about
    it after LC transition - we could make a statement then

    AB: So just include the one date?
    ... any objections?

    RESOLUTION: Use exit criteria and timeframe wording as above
    (from touch events) with a date of July 15th 2013

    AB: Over time, move testing to next week?
    ... I support us moving to GitHub, but will take comments on
    the list


    JR: Quick summary of test the web forward
    ... pointer events group gave both html5 and css quite the
    competition - as a measure of interest it was pretty cool. 15
    or more tests.
    ... and a couple assertions added
    ... we used github, but I intend to port to mercurial along
    with other tests
    ... I'd prefer we stick with mercurial as our main place so
    we're not duplicating
    ... did create pointer events folder in web platform github

    AB: Ok, will start thread - don't feel strongly on test

any other business

    AB: Doesn't look like we'll need a call next week
    ... Hope CR publication will be May 7 or May 9

Summary of Action Items

    [NEW] ACTION: jrossi to open up CR bug for pointer capture
    issues [recorded in

    [End of minutes]
Received on Tuesday, 16 April 2013 17:29:49 UTC

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