See also: IRC log
<ArtB> Scribe: Art
<ArtB> ScribeNick: ArtB
Date: 4 December 2012
<smaug> hmm, is it possible to teach Zakim to bind certain nick always to the right person
<smaug> mbrubeck: ping
AB: need a scribe (cheat sheet <http://www.w3.org/wiki/PointerEvents/Meetings#Meeting_Scribes>)
RB: I can take it today but want someone else to help in the future
AB: thanks Rick
<scribe> ScribeNick: rbyers
<ArtB> Scribe+ Rick
Jacob: we should rotate scribe according the bugs
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0077.html
Art: proposal is to go ahead and
publish it
... but Jacob is free to update the doc, eg. to reflect any
decisions made today
... any objections?
None
<ArtB> RESOLUTION: the group agrees to publish a FPWD of Pointer Events
<ArtB> ACTION: Jacob prepare a FPWD and notify Art when it is ready (see http://www.w3.org/wiki/Webapps/SpecEditing) [recorded in http://www.w3.org/2012/12/04-pointerevents-minutes.html#action01]
<trackbot> Created ACTION-6 - Prepare a FPWD and notify Art when it is ready (see http://www.w3.org/wiki/Webapps/SpecEditing) [on Jacob Rossi - due 2012-12-11].
Art: guess is doc will be
published a week from today, or ... <missed>
... last date to publish this year is Dec 13
Jacob: is there a CfC period?
Art: No, resolution is good enough for you to start
Jacob: Think I can get it in sometime this week
<ArtB> ACTION: barstow send Transition Request for FPWD of Pointer Events [recorded in http://www.w3.org/2012/12/04-pointerevents-minutes.html#action02]
<trackbot> Created ACTION-7 - Send Transition Request for FPWD of Pointer Events [on Arthur Barstow - due 2012-12-11].
Jacob: for new bugs, suggest we wait for some discussion on the list
<ArtB> —> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20107
Jacob: current spec doesn't
expose erase, valid feedback.
... default guess: another value for the button property
Rick: how is the button identified?
Jacob: suggest we use the identifier from the USB HID
<jrossi2> http://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#chorded-button-interactions
Jacob: suggest appending to this
table a button #5%
... will send mail with suggested button name
... if everyone agrees, will change the spec
<ArtB> —> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20108
correction
Jacob: what's missing from the
spec are some additional things IE10 does for the capture
APIs:
... see bug for details
... #1 - should it be possible to capture when buttons=0?
Olli: may need other mechanism
for UA to release pointer capture
... gecko is fairly strict in it's set capture
implementation
... probably more so than IE
Jacob: sounds like we need some allowances for UAs to choose to release capture at other times
Olli: Agree
Jacob: in IE10, it also differs
between Win7 and Win8
... I will think through some spec text to give more
freedom
... to clarify, IE10 only has preview on Win7 that doesn't
support pointer events.
... #4 from bug: pointer events aren't dispatched to elements
not in the document
... believe this is consistent with most types of events
Rick: touch events is very different - always capture to the node where they started, even once removed from the document
Jacob: prefer not to allow events for detached element
Rick: agree
Jacob: #5: compat mouse events
are also redirected to captured element
... to be consistent with where pointer events
... hearing no opposition, should we add them?
Olli: should we limited capturing to a single document?
Jacob: I have looked into those
multi-iframe scenarios.
... you're not going to get access to the dom, but you will get
co-ordinate data
... agree we need to be very careful.
... if we come up with a specific issue, we can open a bug to
add a restrictioon
Olli: ok
RESOLUTION: Will add the additional pointer capture conditions to the spec
<ArtB> —> http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0018.html
<jrossi2> http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf
Jacob: Input APIs in Windows are
largely designed around this USB spec
... defines two different ways of looking at pressure, as
discussed on the list
... uses both relative (0..127) and absolute (physical units)
forms of pressure
... get the point that a more capable pen should be able to
provide higher than normal values
... think we should either keep it as is, or switch to physical
units
Olli: clear we can't report some random value that has no meaning
Rick: probably only conforming behavior on Android is to truncate above 1.0
Jacob: want the property to be interoperable and mean the same thing
<Asir> sorry I got dropped and reconnected
Rick: key question is if we have only one anchor, should we anchor against the maximum value or some subjective indication of 'norma' pressure
Jacob: related issue: how to
report no support for pressure
... currently we report 0
Matt: would be nice for
applicatons to have one code path for pressure sensitive and
non-pressure sensitive devices
... using 0 means the app must handle the two cases
seperately
Jacob: we want this to be device agnostic - don't want to become a device properties spec
Jacob/Matt/Rick: agree we should simulate reasonable pressure
Jacob: in particular, if device does not support pressure, value should be 0 when not in active button state, and 1 when it is
RESOLUTION: if device does not support pressure, value should be 0 when not in active button state, and 1 when it is
Jacob: OK, what about max vs. normal?
Art: could rely on implementation feedback
Rick: evidence for using 'normal' is not strong
RESOLUTION: Keep pressure range as speced, but listen for implementation feedback
shepazu: Can emulate pressure via
surface area
... should we account for this?
Jacob: a UA could do this, and web site wouldn't notice. So would be hard to call this not compliant
shepazu: should we mention this as a note?
Jacob: don't want to go too far in specifying device behavior here
<ArtB> ACTION: barstow add doug's use case about varying touch pressure to v.next list [recorded in http://www.w3.org/2012/12/04-pointerevents-minutes.html#action03]
<trackbot> Created ACTION-8 - Add doug's use case about varying touch pressure to v.next list [on Arthur Barstow - due 2012-12-11].
Art: any objections to touch-events mapping being done in webevents WG instead of pointer events wG?
None
RESOLUTION: Touch-event mapping is out of scope for pointer events WG, will be handled by web events WG instead
<ArtB> ACTION: barstow work with Doug and Rick on defining Touch Events mapping in the Web Events WG [recorded in http://www.w3.org/2012/12/04-pointerevents-minutes.html#action04]
<trackbot> Created ACTION-9 - Work with Doug and Rick on defining Touch Events mapping in the Web Events WG [on Arthur Barstow - due 2012-12-11].
Jacob: no opposition to adding to the spec, assuming it's the same definition as for mouse
Art: any objections?
RESOLUTION: Add pointeenter and pointerleave to spec using the same model as mouseenter and mouseleave
Art: extend to 90 minutes?
Rick: Jacob: hope/expect we won't have 90 minutes worth of bugs to discuss
Doug: would have conflict
Jacob: suggest we leave as is for
at least December, and if we're building up a backlog we can
revisit in new year
... if we're active on the mailing list then we can cover more
there
Art: seems to have resolved, follow-up on list
Art: will have meeting next week, Doug will chair
Rick: I may not be able to make it next week
Doug: I will keep track
... and let the list know if there's a meeting next week
Jacob: what do we need to do to get Matt permission to help edit the PE spec?
Art: all members already have permission
Jacob: OK, I'll work with Matt to make him an editor
np Art, a few more times and I may start to get better at it ;-)
<ArtB> rbyers - you are doing a GREAT job!
<ArtB> Scribe: Rick
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/objects/objections/ Found Scribe: Art Found ScribeNick: ArtB Found ScribeNick: rbyers Found Scribe: Rick Scribes: Art, Rick ScribeNicks: ArtB, rbyers Default Present: +1.717.578.aaaa, +1.770.402.aabb, Matt_Brubeck, Art_Barstow, Olli_Pettay, [Microsoft], +1.519.513.aacc, Doug_Schepers Present: Art_Barstow Olli_Pettay Jacob_Rossi Rick_Byers Asir_Vedamuthu Scott_González Doug_Schepers Matt_Brubeck Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0077.html Found Date: 04 Dec 2012 Guessing minutes URL: http://www.w3.org/2012/12/04-pointerevents-minutes.html People with action items: about add barstow case doug jacob pressure s touch use varying[End of scribe.perl diagnostic output]