See also: IRC log
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
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.
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.
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].
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
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
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
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.
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
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
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].
<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.
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
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!!!
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]