See also: IRC log
<ArtB> ScribeNick: ArtB
<scribe> Scribe: Art
<jrossi2> phone issues....calling
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.
<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
<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
<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
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
attendees
Asir: do we need to discuss CR exit criteria first?
AB: Yes
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
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
AB: Doesn't look like we'll need
a call next week
... Hope CR publication will be May 7 or May 9
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]