- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 16 Apr 2013 13:29:24 -0400
- 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]W3C
[1] http://www.w3.org/
- DRAFT -
Pointer Events WG Voice Conference
16 Apr 2013
[2]Agenda
[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
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
* [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
element
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
[15]http://lists.w3.org/Archives/Public/public-pointer-events/2
013AprJun/0087.html.
... 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_Scrib
es.
[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
<ArtB>
[17]http://lists.w3.org/Archives/Public/public-pointer-events/2
013AprJun/0072.html
[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#ite
m05
[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
[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
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>
[20]http://lists.w3.org/Archives/Public/public-pointer-events/2
013AprJun/0084.html
[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
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
[21]http://www.w3.org/2013/04/16-pointerevents-minutes.html#act
ion01]
<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
<jrossi2>
[23]https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEv
ents.html#the-pointercancel-event
[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
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> [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
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
[26]http://www.w3.org/2013/04/16-pointerevents-minutes.html#act
ion01]
[End of minutes]
Received on Tuesday, 16 April 2013 17:29:49 UTC