W3C

- DRAFT -

Pointer Events WG Voice Conference

12 Mar 2013

Agenda

See also: IRC log

Attendees

Present
Art_Barstow, Scott_Gonzalez, Jacob_Rossi, Cathy_Chan, Matt_Brubeck, Asir_Vedamuthu, Rick_Byers, Peter_Beverloo
Regrets
Doug_Schepers, Sangwhan_Moon
Chair
Art
Scribe
Art

Contents


<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Getting started

AB: I posted a draft agenda yesterday http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0173.html. Any change requests? The main subject is to record the group's consensus on last call comments, assuming we have agreement on a comment. And thanks to Jacob for creating the comment list.
... Before we look at the comments, I will talk about the LC comment process.

Last Call comment process

AB: I want to make sure everyone understands the LC comment process and the various roles and responsibilities.
... please note: the process requires the group "round-trip" all comments. This means the group is responsible for: replying to all comments; notifying the Commenter of the group's decision; asking the Commenter if they agree or not with the group's decision; and recording all of this communication. (See for example http://www.w3.org/2010/webevents/wiki/TouchEvents-LCWD-24-Jan-2013.)
... if you have a Commenter role in this work flow, please make sure your reply to the group is recorded either via e-mail or via meeting minutes.

pointerType Extensibility

AB: based on previous discussions re pointerType extensibility e.g. http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0172.html and http://www.w3.org/2013/02/26-pointerevents-minutes.html#item04.
... I believe we have consensus to not do anything with this for v1
... any objections to that?

[ No ]

RESOLUTION: pointerType extensibility: no additional changes for  for v1

AB: should this be added to the v.Next list?

RB: yes, I think we should

… but I am open to debate

… think we can deal with this better when we have a concrete suggestion

JR: agree

SG: agree too

<scribe> ACTION: barstow add pointerType extensibility to the PEv.Next feature list [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action01]

<trackbot> Created ACTION-24 - Add pointerType extensibility to the PEv.Next feature list [on Arthur Barstow - due 2013-03-19].

add a rotation attribute on PointerEvent?

AB: the question is if there a compelling reason to add? Most recent discussion is http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0171.html
... the only followup was from Jacob. What do people think? Is this something to add to the v.Next feature list?
... we can also defer to the list

RB: we don't have immediate plans to add this

… thus I see no need to address this now

SG: I agree we can postpone this to v.Next

MB: doesn't IE10 support this?

SG: yes it is but people don't build apps that rely on it

… there are some cases where it could be useful

… but I don't see a lot of interest

AB: any objections to resolving this as v.Next potential feature?

<mbrubeck> Nope.

[ None ]

<jrossi2> No

RESOLUTION: add a rotation attribute to PointerEvent?: group agrees "No", although add a related item to the v.Next feature list

<smaug> argh

<scribe> ACTION: barstow add rotation attribute to v.Next feature list [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action02]

<trackbot> Created ACTION-25 - Add rotation attribute to v.Next feature list [on Arthur Barstow - due 2013-03-19].

<smaug> summer time

<smaug> in US, but not in EU

AV: from process perspective, do we need to add these to Bugzilla?

AB: no, we don't have to

… I would only add things to Bugzilla if we are going to make changes to the spec

JR: if I have original comments, and Resolution, as well as replies, I can create the LC comment doc

… and only add issues to Bugzilla if we agree to change the spec

AB: any objections to proceeding that way (i.e. only use Bugzilla for spec changes)?

AV: OK

Should pointerId be an integer?

AB: the discussion thread is http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0170.html.  and we talked about this on Feb 26 http://www.w3.org/2013/02/26-pointerevents-minutes.html#item05.)
... it appears we have agreement the answer is "No", although we could add a non-normative note e.g. the following

[[

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.

]]

<jrossi2> Correct

RB: I think, no change i.e. keep it an integer

AB: sorry, that is indeed what I meant

… any objections to keeping pointerID as integer?

RB: I'm ok with that provided we add that note

AB: any objections to Jacob's proposed text?

[ None ]

RESOLUTION: pointerID should be integer?: group agrees to keep pointerID as Integer, and a related non-normative note will be added to the spec

move examples to the front of the spec

AB: Alex Russell suggested "The spec should lead with examples, i.e., move Section 9 to where Section 2 is now." http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html
... any objections?

[ None ]

RESOLUTION: examples will be moved to the front of the spec

Change buttons field representation?

AB: the relevant thread is http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html
... do we want any changes here?

JR: there could be some benefits of adding some bitmasks

… and hence have multiple models

… but I think we should consider that for v.Next

SG: I think sticking with Mouse Model is best

… I think Alex acknowledged that in his comment

<rbyers> I agree with Jacob's comments - compatibility with MouseEvent is key to the design

AB any objections to staying with buttons as already specified?

[ None ]

AB: add this to v.Next list?

… I think I'm hearing yes

<rbyers> asir: looks like the echo is coming from your end again. Are you muted?

RESOLUTION: change buttons field?: group agrees "No", although a related item will be added to v.Next list.

<scribe> ACTION: barstow add buttons field to v.Next list as a potential new feature [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action03]

<trackbot> Error creating new action - could not connect to Tracker. Please contact sysreq with the details of what happened.

conceptual overlap of new touch-action CSS property and pointer-events property

AB: The question is whether or not the new touch-action CSS property has sufficient conceptual overlap with the pointer-events property to consider merging them http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html.
... some people (including Tab Atkins) recommended not merging them.
... does anyone think they should be merged, or do we keep them separate?

<rbyers> No, they're fundamentally different things in my opinion

AB: anyone think they should be merged?

<asir> agree they are different

[ No one ]

RESOLUTION: the touch-action CSS property will not be merged with CSS'  pointer-event property

<jrossi2> one controls how hit testing works, the other controls what you do in response to a hit test -- so very different

navigator.maxTouchPoints is touch-specific

AB: Alex raised this question http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html
... what, if anything, do we want to do with this?

RB: my concern is that I think we may want to add something in the future

… e.g. some input device API

… might want to ask a device a question about itself

JR: I can see a potential to add something in the future

RB: I don't have a concrete proposal now

… need more experience

JR: similar to pointerType issue in that we need more info

… to decide the right-thing-to-do

RESOLUTION: maxTouchPoints is touch-specific: the group agrees on no spec change needed but we should add this to v.Next

<scribe> ACTION: barstow add maxTouchPoints issue to v.Next list [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action04]

<trackbot> Created ACTION-26 - Add maxTouchPoints issue to v.Next list [on Arthur Barstow - due 2013-03-19].

<rbyers> asir: that echo is really annoying when talking, can you try using a different phone? Eg. you can call Zakim using SIP...

SG: re the name, what about maxPointers?

RB: it would make it harder to pinpoint a definition

SG: agree it could depend on OS and/or hardware

RB: we don't have this in TouchEvents

JR: one way to use this as touch hardware detection i.e. is touch possible

… and then the UI could adapt accordingly

RB: there could be overlap with pointer and hover MQs

JR: the other UC is to know the specific number of devices

<rbyers> asir: much better, thanks

… app could then switch on number of devices

<asir> Zakim-mute worked

MB: may want it for single touch hardware

… so may want to name it MaxTouchPoints

RB: not clear if MQs is the right place or do we need a new API

… could have touch-points MQ

<mbrubeck> I think a media query would be good.

… would be more consistent with pointer and hover MQs

RB: but don't think this is critical to address (now)

… could move this to v.Next

… The UA needs a way to tell app it is on a touch screen

JR: not opposed to pointer and hover

RB: are there sites that rely on the number in practice?

JR: mostly seeing checks for >= 0

AB: do we want to revisit the Resolution?

RB: question about adding a redundant API

SG: want to avoid duplicated APIs in the future

RB: if we could get touch-points added as a MQ

… then there would be no value in adding this API

SG: that would be OK with me

JR: there could be value in querying this from CSS

… there is already some content using this so we need to keep it

RB: understand but we wouldn't add it

AB: so, despite the RESOLUTION, it appears we need some more time to talk about this

JR: not sure how number of points supported is interesting from a view perspective

… I'm open to adding a new MQ

… not sure how that adds anymore than using maxTouchPoints

RB: there could be some scenarios that only want to query from CSS

… e.g. a map app and pinch/zoom

RB: I don't object strongly but I don't like redundant APIs

AB: so, looking at this from CanILiveWithItTest, is the resolution we agreed to earlier ok?

RB: yes, I can live with it as spec'ed

<jrossi2> Would prefer keeping as spec'ed

SG: yeah, it's fine

AB: so the maxTouchPoints RESOLUTION stands
... so, there is the CR phase which is YA opportunity to gather data

Clarifying the spec's positioning

AB: Alex wrote "The pointer event spec does not require other device events be supported (e.g. mouse events, touch

events, etc.)" in http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html.

AB: what needs to be done here? Some additional non-normative text?

<rbyers> One more point on the last topic: many media queries are already redundant with javascript APIs (eg. width, height), so from that perspective it's not terrible for navigator.maxTouchPoints to be largely redundant with the pointer media query.

JR: as I said in my reply, I think this is conceptual.

… if there is a need for some non-normative text, I can add it

AB: any other comments or objections to adding a non-normative statement to address this issue?

[ None ]

RESOLUTION: group agrees some additional non-normative text re spec's "positioning" should be added.

<scribe> ACTION: Jacob propose text re the "spec's positioning" (see LC comment from Alex Russell) [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action05]

<trackbot> Created ACTION-27 - Propose text re the "spec's positioning" (see LC comment from Alex Russell) [on Jacob Rossi - due 2013-03-19].

Click and contextmenu events

<rbyers> jrossi2: probably not necessary to mute and unmute now - the problem was fixed by muting asir

AB: this topic has raised by Rick in http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0163.html and discussed on Feb 26 http://www.w3.org/2013/02/26-pointerevents-minutes.html#item06.
... where are we on this issue?

<jrossi2> rbyers: cool, unmuted

RB: Jacob agreed they are pretty much the same and should be treated the same

JR: click is mentioned

RB: some text in Section 8, non-normative

[ JR reads relevant text … ]

RB: yes, we should just expand the note

… e.g. add double-click too

RESOLUTION: group agrees to add some addtional text to Section 8

<scribe> ACTION: Jacob add text to Section 8 to address Rick's click and context menu issue [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action06]

<trackbot> Error creating new action - could not connect to Tracker. Please contact sysreq with the details of what happened.

Test Assertions:

AB: Cathy, do you have any status on test assertions to share?

CC: no, not yet; should have something in the next couple of weeks

AB: ok, thanks
... if you can help with this effort, please contact Cathy via the list

Any other Business

AB: any new implementation status to share?

<rbyers> Here's the bug tracking adding pointer events to chrome: https://code.google.com/p/chromium/issues/detail?id=162757

<rbyers> Here's the text I wrote there:

<rbyers> Pointer events offers a number of improvements, and solves important problems with touch events. However adding a new (largely redundant) input model to the web is not something we can take lightly. We're actively debating whether the benefits justify the conceptual complexity of having a new input model. I welcome any comments on this bug (especially from site/library developers using both touch and pointer events today).

[ Scott talked about some TE / PE info in jQuery ]

RB: would like to see a blog about that

… there are two polyfills for PE now

… Microsoft has one

… and Google has one

<jrossi2> http://aka.ms/handjs

<rbyers> Google one: https://github.com/toolkitchen/PointerEvents

… the pollyfills are tricky, especially for performance reasons

RB: touch-action CSS property in particular is problematic

AB: thanks for adding those

<scott_gonzalez> https://github.com/borismus/pointer.js

<rbyers> Not perfect (Eg. relies on a touch-action html attribute, instead of trying to parse CSS like hand.js)

SG: there is another polyfill from Boris Smus

RB: yeah, but Boris' isn't as complete so I recommend the Google one I mentioned above

… pointer.js is worth looking at but it isn't complete

SG: we still have some issues we are discussing

RB: are those design discussion done in public?

SG: yes; a lot are in IRC; others are in pull requests

RB: when jQuery makes important decisions, would love to hear about it

SG: I can send that info to the list

AB: on March 19 I have a conflict and will not be available. We will have a meeting if Doug can Chair it.
... regardless, please continue to use the list

<asir> Good progress today in closing issues!!!

AB: anything else?

<rbyers> Yes, thank you Art!

AB: meeting adjourned

<asir> Thank you Art!!!

Summary of Action Items

[NEW] ACTION: barstow add buttons field to v.Next list as a potential new feature [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action03]
[NEW] ACTION: barstow add maxTouchPoints issue to v.Next list [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action04]
[NEW] ACTION: barstow add pointerType extensibility to the PEv.Next feature list [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action01]
[NEW] ACTION: barstow add rotation attribute to v.Next feature list [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action02]
[NEW] ACTION: Jacob add text to Section 8 to address Rick's click and context menu issue [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action06]
[NEW] ACTION: Jacob propose text re the "spec's positioning" (see LC comment from Alex Russell) [recorded in http://www.w3.org/2013/03/12-pointerevents-minutes.html#action05]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-03-12 16:07:41 $

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/Msft/Microsoft/
Found ScribeNick: ArtB
Found Scribe: Art
Present: Art_Barstow Scott_Gonzalez Jacob_Rossi Cathy_Chan Matt_Brubeck Asir_Vedamuthu Rick_Byers Peter_Beverloo
Regrets: Doug_Schepers Sangwhan_Moon
Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0173.html
Got date from IRC log name: 12 Mar 2013
Guessing minutes URL: http://www.w3.org/2013/03/12-pointerevents-minutes.html
People with action items: add attribute barstow buttons extensibility field issue jacob maxtouchpoints pointertype rotation text

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]