- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 12 Mar 2013 12:12:23 -0400
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
The draft minutes from the March 12 voice conference are available at
<http://www.w3.org/2013/03/12-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 19 March 2013. In the
absence of any changes, these minutes will be considered approved.
-Thanks, Art
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Pointer Events WG Voice Conference
12 Mar 2013
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0173.html
See also: [3]IRC log
[3] http://www.w3.org/2013/03/12-pointerevents-irc
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
* [4]Topics
1. [5]Getting started
2. [6]Last Call comment process
3. [7]pointerType Extensibility
4. [8]add a rotation attribute on PointerEvent?
5. [9]Should pointerId be an integer?
6. [10]move examples to the front of the spec
7. [11]Change buttons field representation?
8. [12]conceptual overlap of new touch-action CSS
property and pointer-events property
9. [13]navigator.maxTouchPoints is touch-specific
10. [14]Clarifying the spec's positioning
11. [15]Click and contextmenu events
12. [16]Test Assertions:
13. [17]Any other Business
* [18]Summary of Action Items
__________________________________________________________
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
Getting started
AB: I posted a draft agenda yesterday
[19]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/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.
[19] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0173.html.
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
[20]http://www.w3.org/2010/webevents/wiki/TouchEvents-LCWD-24-J
an-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.
[20] http://www.w3.org/2010/webevents/wiki/TouchEvents-LCWD-24-Jan-2013.)
pointerType Extensibility
AB: based on previous discussions re pointerType extensibility
e.g.
[21]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0172.html and
[22]http://www.w3.org/2013/02/26-pointerevents-minutes.html#ite
m04.
... I believe we have consensus to not do anything with this
for v1
... any objections to that?
[21] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0172.html
[22] http://www.w3.org/2013/02/26-pointerevents-minutes.html#item04.
[ 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
[23]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion01]
<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
[24]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/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
[24] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0171.html
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
[25]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion02]
<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
[26]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0170.html. and we talked about this on Feb 26
[27]http://www.w3.org/2013/02/26-pointerevents-minutes.html#ite
m05.)
... it appears we have agreement the answer is "No", although
we could add a non-normative note e.g. the following
[26] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0170.html.
[27] http://www.w3.org/2013/02/26-pointerevents-minutes.html#item05.)
[[
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."
[28]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0169.html
... any objections?
[28] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html
[ None ]
RESOLUTION: examples will be moved to the front of the spec
Change buttons field representation?
AB: the relevant thread is
[29]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0169.html
... do we want any changes here?
[29] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html
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
[30]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion03]
<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
[31]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0169.html.
... some people (including Tab Atkins) recommended not merging
them.
... does anyone think they should be merged, or do we keep them
separate?
[31] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html.
<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
[32]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0169.html
... what, if anything, do we want to do with this?
[32] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html
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
[33]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion04]
<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
[34]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0169.html.
[34] 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
[35]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion05]
<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
[36]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0163.html and discussed on Feb 26
[37]http://www.w3.org/2013/02/26-pointerevents-minutes.html#ite
m06.
... where are we on this issue?
[36] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0163.html
[37] http://www.w3.org/2013/02/26-pointerevents-minutes.html#item06.
<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
[38]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion06]
<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:
[39]https://code.google.com/p/chromium/issues/detail?id=162757
[39] 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> [40]http://aka.ms/handjs
[40] http://aka.ms/handjs
<rbyers> Google one:
[41]https://github.com/toolkitchen/PointerEvents
[41] 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> [42]https://github.com/borismus/pointer.js
[42] 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
[43]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion03]
[NEW] ACTION: barstow add maxTouchPoints issue to v.Next list
[recorded in
[44]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion04]
[NEW] ACTION: barstow add pointerType extensibility to the
PEv.Next feature list [recorded in
[45]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion01]
[NEW] ACTION: barstow add rotation attribute to v.Next feature
list [recorded in
[46]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion02]
[NEW] ACTION: Jacob add text to Section 8 to address Rick's
click and context menu issue [recorded in
[47]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion06]
[NEW] ACTION: Jacob propose text re the "spec's positioning"
(see LC comment from Alex Russell) [recorded in
[48]http://www.w3.org/2013/03/12-pointerevents-minutes.html#act
ion05]
[End of minutes]
Received on Tuesday, 12 March 2013 16:12:43 UTC