- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 26 Mar 2013 13:16:34 -0400
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
The draft minutes from the March 26 voice conference are available at
<http://www.w3.org/2013/03/26-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 2 April 2013. In the
absence of any changes, these minutes will be considered approved.
-Thanks, ArtB
W3C <http://www.w3.org/>
- DRAFT -
Pointer Events WG Voice Conference
26 Mar 2013
Agenda
<http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0212.html>
See also:IRC log <http://www.w3.org/2013/03/26-pointerevents-irc>
Attendees
Present
Art_Barstow, Rick_Byers, Jacob_Rossi, Olli_Pettay, Scott_Gonzalez,
Asir_Vedamuthu
Regrets
Doug_Schepers, Cathy_Chan
Chair
Art
Scribe
Art, Rick
Contents
* Topics <http://www.w3.org/2013/03/26-pointerevents-minutes.html#agenda>
1. Getting started
<http://www.w3.org/2013/03/26-pointerevents-minutes.html#item01>
2. Pointer event behavior across windows
<http://www.w3.org/2013/03/26-pointerevents-minutes.html#item02>
3. 3D Pointers
<http://www.w3.org/2013/03/26-pointerevents-minutes.html#item03>
4. Last Call comments from Yandex
<http://www.w3.org/2013/03/26-pointerevents-minutes.html#item04>
5. Distinguishing input from multiple users
<http://www.w3.org/2013/03/26-pointerevents-minutes.html#item05>
6. extensions to the element interface
<http://www.w3.org/2013/03/26-pointerevents-minutes.html#item06>
7. Testing: status, plans
<http://www.w3.org/2013/03/26-pointerevents-minutes.html#item07>
8. Any other Business
<http://www.w3.org/2013/03/26-pointerevents-minutes.html#item08>
* Summary of Action Items
<http://www.w3.org/2013/03/26-pointerevents-minutes.html#ActionSummary>
------------------------------------------------------------------------
<ArtB> ScribeNick: ArtB
<scribe> Scribe: Art
Getting started
AB:I posted a draft agenda a few days
agohttp://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0212.html.The
main subject is to discuss the LC comments for which we have no recorded
resolution regarding what, if anything, should be done about the comments.
... any change requests?
JR:+ extensions to Element interface
AB:OK
... would someone please agree to scribe with the proviso others will
help fill any gaps and make corrections?
<scribe> Scribe: Rick
<scribe> ScribeNick: rbyers
Pointer event behavior across windows
<ArtB> AB: Rick Byers submitted this
commenthttp://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0180.html
<ArtB> AB: it appears an IE bug was identified but not clear if the spec
needs to be changed e.g. a non-normative note about PEs across windows.
RB:probably outside the scope of the spec
JR:also discussed similar issue on Dom3 events and didn't do anything there
*RESOLUTION: Cross-window issues are out of scope for this spec*
3D Pointers
OP:Agree, out of scope
<ArtB> AB: Bill Fisher submitted this
commenthttp://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0185.html
<ArtB> AB: we discussed this feature request before more generally in
the context of the pointerType extensibility thread and agreed we need
more experience before adding normative text.
<ArtB> AB: Jacob replied as such
inhttp://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0189.html.Bill's
reply to Jacob, he mentions the need for a
z-coordinatehttp://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0200.html
JR:Intriguing discussion, tempting to just jump and support. But this is
a tricky point in the specs lifetime - need to resist the temptation.
... We're probably going to want to have a long discussion, don't think
it's as simple as he describes
... It will be awhile before we see implementations
... If we rush this into V1 we'll probably get something wrong
RB:Seems like if we get extensibility right, this should be successful
being implementation-specific first before being standardized
... To what extent are his concerns here justified?
JR:LeapMotion has shown that prototypes are reasonable
... not beyond the realm of posibility to extend the interface with
additional properties for experimentation
AB:Tend to agree that without more experimentation, this would end up
blocking going to candidate
... Feels like the right thing to do is to do it in V2
SG:I don't think this is necessary in v1. Better to start close to mouse
(what we have now), then once we have people on pointer we can focus
more on how we handle other newer types of input.
OP:I agree
*RESOLUTION: 3d pointers are out of scope for Pointer Events v1, but
will consider for v2 when we have more experimentation*
Last Call comments from Yandex
<ArtB> AB: Chaals' comments are
inhttp://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0184.html.The
comments are from "people at Yandex who implemented Pointer Events for
our services". (BTW, Yandex joined the PEWG a few days ago.)
AB:Yandex has joined this working group
<ArtB> AB: the e-mail raises 3-4 different issues
<ArtB> AB: Jacob's reply to
Chaals/Sergeyhttp://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0197.htmland
Sergey's
replyhttp://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0199.html.
<jrossi2> rbyers: first issue raised is that they prefer
preventDefault() over touch-action
<jrossi2> rbyers: we've talked several times
<jrossi2> rbyers: jacob commented on the reasoning
<jrossi2> rbyers: yandex asked about other browser vendors
<jrossi2> rbyers: I replied with links to a test page and G+ post about it
<jrossi2> rbyers: at this point, no way we're going to change PE to use
preventDefault() model
<asir> Agree with Rick's position
AB:Agree this isn't something we should be considering changing
OP:Agree
*RESOLUTION: declarative-only control over browser default action
(touch-action property) will remain the only mechanism for now*
<ArtB> AB: "Tilt angles are very difficult to work with, why not use
standard
<ArtB> spherical coordinates?"
<asir> Gist from Jacob's response: Tilt angles. This is based on USB
standard
AB:Jacob responded pointing at USB documentation
RB:Not a significant issue, good as is
*RESOLUTION: keep tiltX/tiltY units as defined*
AB:next issue - "pointer capture doesn't add any value, artifact of ie6"
RB:is there a compelling reason why capture needs to be in v1?
... JR: a substantial difference between these APIs and the capture APIs
in IE5/6 is that these handle multi-touch
... using the capturing phase it's tricky to track specific pointers to
specific elements
... could imagine slider scenario extended to mixing board with multiple
sliders, each capturing a pointer
... setCapture makes this easier
... latest comment saying this makes it problematic for component author:
... don't really buy this for 2 reasons:
... 1) there are got/lost events that will let them know when this happens
... 2) there are a million other scenarios where it could be effected
... multi-touch is the primary place this is useful
... I'd like to run this API by our folks working on Web components
... any encapsulation issues here
JR:Agree we want to make sure it plays well there
RB:sounds like worst case and we decided we wanted to think about this a
little longer, it's not a big deal if we wanted to pull from v1
JR:main concern is that it could affect someone's review of the spec -
that it would reset things in the last call process
AB:If we decided we didn't want to include section 9 then we would have
to go back to last call
<scribe>*ACTION:*rbyers to follow-up on web component implications of
pointer capture [recorded
inhttp://www.w3.org/2013/03/26-pointerevents-minutes.html#action01]
<trackbot> Created ACTION-28 - Follow-up on web component implications
of pointer capture [on Rick Byers - due 2013-04-02].
JR:for folks wanting a more straight forward migration from touch
events, this is simpler
... lets you emulate implicit capture model of touch events
RB:agree
... but not sure how important this is in practice - often implicit
capture causes problems
OP:why does the API take pointerId and not a PointerEvent as it's parameter?
JR:not necessary to pass the entire object - just need to identify the
pointer
OP:is the ability to capture a random number a problem?
JR:if it's a valid pointer id then it will get captured (can setcapture
outside of a pointer event_
... if it's not valid then it throws an exception
AB:any other feedback? If Rick doesn't come up with any large issues
with leaving it defined, then we'll leave it in.
OP:agree
... this is kind of related to pointer lock, but only designed for mouse
events
... assume we'd want support for pointer events at some point
<smaug>https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
JR:pointer lock is a lot different than just capture, it also hides the
cursor, gives you deltas, etc.
OP:yes it does more, but at some point we need to think about pointer
lock for pointer events
JR:agree, that's probably pointerlock v2. There's nothing in
PointerEvent spec preventing a 'pointersLock"
<jrossi2> also, there are some sites already using pointer capture APIs
I believe
<ArtB> AB: "Why should the mouse have pointerId == 1? There is no need
for this, since we have a pointerType for detecting input device type,
and it makes it impossible to use two mouse devices simultaneously."
jrossi2:If you could provide a specific example of a site using it, that
might be helpful...
JR:we've talked about this before
... generally mouse is persistent
... felt it simplest to reserve a pointer id for the mouse
... multi-mouse is possible with the spec, but it's not a scenario most
implementers are going after
... don't see this becoming an important thing
RB:does code special-casing 1 protect us or hurt us if we add
multi-mouse in the future?
SG:seems strange to say write for multiple pointers for touch, but there
can only ever be one mouse
RB:also strange to say that pointer Id is an opaque integer, don't
interpret it in any way ... unless it has the value 1
JR:for multi-mouse we'd have to define which pointer fires mouse events
AB:seems like this may not be the perfect model, but meets the "I can
live with it" test
RB:Alex Russel brought this up
<asir> the WG discussed on Mar 3 and Mar 12
*RESOLUTION: supporting multi-mouse is out of scope for v1, will tackle
in v2. The primary mouse having id 1 won't prevent this.*
AB:Last comment on the thread ...
JR:Multi-touch handling and the convenience of having a touch list
RB:there's good reason to encourage more thought on the right way to do
a pointer list API
... has security implications (IE originally had one and it was removed)
AB:let's add this comment to the thread
JR:have get pointer list API on v2 list
*RESOLUTION: an API to return active pointers is out of scope for v1,
but will be tackled in v2*
Distinguishing input from multiple users
<ArtB> AB: Sangwhan Moon submitted this comment on March
24http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0210.html
<ArtB> AB: first, there is a bit of procedural issue here. Since the LC
comment period ended March 19 and Sangwhan's input was submitted on
March 24, strictly speaking we _could_ say this isn't a LC comment.
<ArtB> AB: however, I recommend against that i.e. I think we should
consider Sangwhan's comment as a LC comment.
<ArtB> AB: I say this for a couple of reasons but mainly because we have
what I will call a "social contract" with the Public. We should always
welcome feedback at any time in the process and then on a case-by-case
basis decide what, if anything, to do about the feedback.
<ArtB> AB: any comments on the process-related aspects (separately, we
will talk about the technical nature of Sangwhan's comments)?
<asir> Agree this should be a Last Call comment
JR:no objections, I have one of my own...
RB:agree
JR:want a way to associate pointers with a particular device (or 'user')
... eg. multiple users interacting with the same content [via multiple
input devices]
... one example is the Wii browser
... specific proposal: add a deviceId member to PointerEvent
... is the issue clear to everyone?
AB:I think so
JR:it's not clear to me that pointer events are the only type of input
you want to differentiate
... don't have anything wrong with the approach in principle
... but probably belongs on UIEvent, not on PointerEvent. Eg. to support
multiple keyboards.
... Secondly, we want to make sure we're not exposing a unique
identifier for users (something that persists across pages). needs to be
generic, reset for each page, no guarantees that you get the same ID for
each device after a navigation
... prefer this would be in the scope of the UI Events spec
OP:Fully agree
AB:should we propose to WebApps working group that this get added there?
RB:seems reasonable
JR:I can reply on the thread and see what Sangwhan thinks
<ArtB>*ACTION:*Barstow reply to Yandex comments (Chaals) and include
link to 26-Mar-2013 minutes [recorded
inhttp://www.w3.org/2013/03/26-pointerevents-minutes.html#action02]
<trackbot> Created ACTION-29 - Reply to Yandex comments (Chaals) and
include link to 26-Mar-2013 minutes [on Arthur Barstow - due 2013-04-02].
<jrossi2>*ACTION:*jrossi2 to reply to Sangwhan on the list [recorded
inhttp://www.w3.org/2013/03/26-pointerevents-minutes.html#action03]
<trackbot> Created ACTION-30 - Reply to Sangwhan on the list [on Jacob
Rossi - due 2013-04-02].
<jrossi2>*ACTION:*jacob to reply to 3D pointer thread [recorded
inhttp://www.w3.org/2013/03/26-pointerevents-minutes.html#action04]
<trackbot> Created ACTION-31 - Reply to 3D pointer thread [on Jacob
Rossi - due 2013-04-02].
extensions to the element interface
JR:a glaring omission from the spec here
... section 6 defines extensions to the Element interface, but they
should also be on Window and Document
... wish we would have caught this earlier, don't expect objections
... pretty obvious that's what the model should have been
... but think it's something we'd want to fix
<asir> sort of like a documentation issue
RB:agree, I was assuming that too
AB:consider this a bug in the IDL personally
OP:Definitely they should be on document and window too
*RESOLUTION: Update spec to add all Element extensions to Document and
Window as well*
Testing: status, plans
AB:Matt agreed to be test facilitator, but he's not here today
... Cathy has done preliminary work on assertions
<ArtB>http://www.w3.org/wiki/PointerEvents/TestAssertions
Any other Business
AB:standing action for the group to review and contribute to these
assertions
<ArtB> AB: does anyone have any new implementation status to share?
RB:no change on Google side to report this week
AB:Jacob, do you have last call tracking doc?
JR:Yes, I'll add to it for this week and will check it in
... see change for element extensions as not a substantial change, right?
AB:Yes, non-substantive
... just a bug in the IDL
... None of the changes we've discussed so far result in substantive changes
... everyone agree?
<asir> Yes
AB:We will have a call next week
RB:I also agree, no substantive changes
<jrossi2> yes
<jrossi2> no substantive changes
Summary of Action Items
*[NEW]**ACTION:*Barstow reply to Yandex comments (Chaals) and include
link to 26-Mar-2013 minutes [recorded
inhttp://www.w3.org/2013/03/26-pointerevents-minutes.html#action02]
*[NEW]**ACTION:*jacob to reply to 3D pointer thread [recorded
inhttp://www.w3.org/2013/03/26-pointerevents-minutes.html#action04]
*[NEW]**ACTION:*jrossi2 to reply to Sangwhan on the list [recorded
inhttp://www.w3.org/2013/03/26-pointerevents-minutes.html#action03]
*[NEW]**ACTION:*rbyers to follow-up on web component implications of
pointer capture [recorded
inhttp://www.w3.org/2013/03/26-pointerevents-minutes.html#action01]
[End of minutes]
------------------------------------------------------------------------
Received on Tuesday, 26 March 2013 17:17:02 UTC