Pointer Events WG Voice Conference -- 18 Dec 2012

Jacob: pattern originates in DOM4, above example suggests how to do it for events
... but not yet an actual deliverable
... so can't define dictionary for pointer events that inherits from dictionary for mouse events

<jrossi2> http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0117.html

Jacob: But we could completely define the dictionary now, and inherit in the future to collapse into one?

Art: Believe current charter of webapps includes DOM4 events, and there is an editors draft
... but no first public working draft yet

Jacob: concern is creating normative dependency on that

<ArtB> D4Events ED: http://dvcs.w3.org/hg/d4e/

Art: OK with dependency on DOM3 events for now

Jacob: if there is no functional difference then we can update our spec in errata

Olli: order of properties may be an issue

Jacob: I put them in order for inheritance chain
... but I can check the details. Probably just a matter of making sure that the order we specify in PE spec, matches how they'd come out via inheritance

Olli: doesn't matter what order they are in in the spec, what matters is how the implementation orders them

Jacob: OK, I can check that

<ArtB> -> D4E Editor's Draft: http://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm

Jacob: don't think D4 spec specifies this

Olli: It's in the WebIDL spec
... inheritance may inmply a different order

<scribe> ACTION: jrossi Determine if WebIDL permits us to define our dictionary in a way compatibile with future inheritance from DOM4 mouse event dictionary [recorded in http://www.w3.org/2012/12/18-pointerevents-minutes.html#action01]

<trackbot> Created ACTION-10 - Determine if WebIDL permits us to define our dictionary in a way compatibile with future inheritance from DOM4 mouse event dictionary [on Jacob Rossi - due 2012-12-25].

Jacob: If we did define in relation to DOM4 events, what is the process?

Art: Ideally we'd be at least one stage behind in maturity level. Eg. could prevent us from going to REC status until DOM4 events is CR

<smaug> "The order of the dictionary members on a given dictionary is such that inherited dictionary members are ordered before non-inherited members, and the dictionary members on the one dictionary definition (including any partial dictionary definitions) are ordered lexicographically by the Unicode codepoints that comprise their identifiers. "

Doug: if you have a normative dependency you're not supposed to move forward, but W3C is examining this. I think we're relatively safe here. We could wait until last call to see if we have an issue.
... there are options, will only bite us post-CR

<smaug> http://dev.w3.org/2006/webapi/WebIDL/#idl-dictionaries

Jacob: OK, thanks. If there's no issue I'd still prefer not to take a dependency

Olli: I think there is an issue

Jacob: OK, so we may just have to take the dependency and worry about it later

RESOLUTION: Will add dictionary for event creation. This will add a dependency on DOM4 events, pending confirmation that there is a functional difference between inheritance and flattened dictionaries.

<jrossi2> http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0114.html

Bug 20219 - Making pointerType a string

Jacob: change made in spec with table of normative values
... put in suggested text:

<jrossi2> "If a user agent supports pointer device types other than those listed above, the value of pointerType SHOULD be vendor prefixed to avoid conflicting names for different types of devices. Future specifications MAY provide additional normative values for other device types."

""If a user agent supports pointer device types other than those listed above, the value of pointerType SHOULD be vendor prefixed to avoid conflicting names for different types of devices. Future specifications MAY provide additional normative values for other device types."

Jacob: any concerns over 'SHOULD' here?

Art: this could be an informative note, but this is fine too

Any objections to proposed text in http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0114.html?

None

<ArtB> ACTION: jacob implement the proposal for bug 20219 as proposed in http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0114.html [recorded in http://www.w3.org/2012/12/18-pointerevents-minutes.html#action02]

<trackbot> Created ACTION-11 - Implement the proposal for bug 20219 as proposed in http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0114.html [on Jacob Rossi - due 2012-12-25].

RESOLUTION: Incorporate text from email 0114.html into spec - custom pointerTypes SHOULD be vendor prefixed

<jrossi2> http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0118.html

hardware timestamps - bug 20220

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20220

<jrossi2> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html

Jacob: specifies a timestamp in milliseconds with accuracy up to 1/1000th of an ms
... type change makes perfect sense
... discussion about whether all DOM events should add such an timestamp
... fine as long as defined as defined as hardware time instead of dispatch time

Rick: that was definiately the intention (flackr started this work for touch performance - exactly the scenario envisioned by the current PE spec text)

Jacob: Ok, sounds good

Propose removing hwTimestamp from this spec, but we'd come back if there was an issue getting it added to DOM4 events

No objections

RESOLUTION: remove hwTimestamp from PE spec (under expectation it will get added to all DOM events)

<jrossi2> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20236

Bug 20236 - Is button value -1 impossible?

Jacob: Olli pointed out that button is technically unsigned, so -1 is invalid
... Don't want to churn DOM3 spec
... Doesn't seem to be an interop problem in practice for this to be -1
... So propose that PE change the definition to signed

Olli: Would prefer to change DOM3 event here
... but do we really need a negative value?

<jrossi2> http://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#chorded-button-interactions

Jacob: idea is to optimize for least common denominator
... want to be able to write for mouse and have it work with touch
... mouse behaves as a contact, subsequent up/down just alter the button state
... but DOM3 says that button is only valid on mousedown
... so use -1 as a sentinal value
... alternately could have a 'button state change' event

Olli: worried about libraries seeing a change in behavior on button

Jacob: don't think -1 should cause any interop problem

correction. Jacob: don't think changing unsigned to signed for MouseEvent would have any impact on library

scribe: only way to test is creating synthetic event with negative value, but no interop here
... we're not actually ever going to have a negative value for MouseEvent, only PointerEvent - so can't break libraries that way

Olli: it just seems ugly to redefine a property here

Jacob: What if we changed DOM3 events instead?

Olli: That would be cleaner

<scribe> ACTION: jrossi Ask DOM3 editor whether button could be changed from unsigned to signed without resetting last call. [recorded in http://www.w3.org/2012/12/18-pointerevents-minutes.html#action03]

<trackbot> Created ACTION-12 - Ask DOM3 editor whether button could be changed from unsigned to signed without resetting last call. [on Jacob Rossi - due 2012-12-25].

Jacob: Could make an argument that it's safe, but worried about it
... If it would be a big problem for DOM3 events then we'll bring up changing it in PointerEvents again here

<jrossi2> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20218

bug 20218 - Extent pointer events to support raw trackpad data

Rick: idea is that in the future web apps might want to get raw touch data from trackpads (eg. for defining it's own gestures)

Jacob: we actually considered this in the origina PE design. Currently no standard (non-driver-specific) way to do this on Windows, but that could change.

Rick: MacOS permits readings raw trackpad touch data

Jacob: not just about trackpads on laptops, but also other hardware like large Wacom touchpads - 'indirect touch'
... We thought about it in IE10, but have no plans to do it anytime soon
... May be a good thing for PointerEvents 2

Proposal: create wishlist for v2 features, and add this one

no objections

<jrossi2> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20311

RESOLUTION: Mark trackpad bug 20218 as resolved Later for PE v2

<jrossi2> http://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-touch-action-css-property

Bug 20133 - clarify touchAction applies only to pointerDown

Jacob: this is really already covered by the spec
... but is a good idea to make a tweak to make it more clear
... would prefer to do it at the same time as other touchAction changes in discussion on list

All agreed

ArtB: yes, we're both on Chrome (different office though)

AoB

UNKNOWN_SPEAKER: Next call will be Jan 8, 2013

<asir_> Happy Holidays!!

Doug: please use the mailing list for discussion until our next meeting

<ArtB> Scribe: Rick

- DRAFT -

Pointer Events WG Voice Conference

18 Dec 2012

Attendees

Contents

Getting started

pointer events bugs

Bug 20107 - eraser button for penb

Bug 20221 - mechanism for creating PointerEvent instances

Bug 20219 - Making pointerType a string

hardware timestamps - bug 20220

Bug 20236 - Is button value -1 impossible?

bug 20218 - Extent pointer events to support raw trackpad data

Bug 20133 - clarify touchAction applies only to pointerDown

AoB

Summary of Action Items

Scribe.perl diagnostic output