W3C

- DRAFT -

Pointer Events WG Voice Conference

16 Apr 2013

Agenda

See also: IRC log

Attendees

Present
Art_Barstow, Rick_Byers, Asir_Vedamuthu, Olli_Pettay, Scott_González, Doug_Schepers, Jacob_Rossi
Regrets
Cathy_Chan(until_July)
Chair
Art
Scribe
Art

Contents


<ArtB> ScribeNick: ArtB

<scribe> Scribe: Art

<jrossi2> phone issues....calling

Getting started

AB: I posted a draft agenda yesterday http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0087.html.
... it may make sense to move topic #2 (LC comment processing) after #3, #4 and #5. Is that OK?

[ Yes'es ]

AB: any other change requests?
... can I get a volunteer to scribe today's meeting? Scribe "cheat sheet" is http://www.w3.org/wiki/PointerEvents/Meetings#Meeting_Scribes.

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

<rbyers> ScribeNick: rbyers

<ArtB> http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0072.html

<ArtB> Feb 26 Alex argued pointerID should be opaque 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 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 change....
... 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 with.
... 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 implementation?
... would it change someone's review of the specification?
... an implementation might change, but wouldn't force them to change
... 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 implementations

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 change?

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?

None

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

<ArtB> 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 comment
... this is brand new

AB: any objections?

none

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 dangerous
... 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 is.
... 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 spec

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 something
... tag it as CR as some way

<jrossi2> ACTION: jrossi to open up CR bug for pointer capture issues [recorded in http://www.w3.org/2013/04/16-pointerevents-minutes.html#action01]

<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> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21686

<jrossi2> 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 already
... so either IE10 doesn't match or we change the spec
... don't have a strong preference, don't view it as being too important

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

testing

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 attendees

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

<ArtB> ]]

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

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 before

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 implementibility

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

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 document?

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

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

testing

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 location

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 http://www.w3.org/2013/04/16-pointerevents-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-04-16 16:16:05 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/DS/AB/
Succeeded: s/DS: I thought/AB: I thought/
Succeeded: s/DS: We deal/AB: We deal/
WARNING: No scribe lines found matching ScribeNick pattern: <Art> ...
Found ScribeNick: ArtB
Found Scribe: Art
Found ScribeNick: rbyers
ScribeNicks: ArtB, rbyers
Default Present: +1.519.513.aaaa, +1.717.578.aabb, scott_gonzalez, rbyers, Art_Barstow, Olli_Pettay, Doug_Schepers, asir
Present: Art_Barstow Rick_Byers Asir_Vedamuthu Olli_Pettay Scott_González Doug_Schepers Jacob_Rossi
Regrets: Cathy_Chan(until_July)
Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0087.html
Got date from IRC log name: 16 Apr 2013
Guessing minutes URL: http://www.w3.org/2013/04/16-pointerevents-minutes.html
People with action items: jrossi

[End of scribe.perl diagnostic output]