Draft minutes: 2014 March 11 call

The draft minutes from the March 11 voice conference are available at 
the following and copied below:

<http://www.w3.org/2014/03/11-pointerevents-minutes.html>

WG Members - if you have any comments, corrections, etc., please send 
them to the public-pointer-events mail list before March 18. In the 
absence of any changes, these minutes will be considered approved.

-Thanks, ArtB

[1]W3C

[1] http://www.w3.org/

- DRAFT -

Pointer Events WG Voice Conference

11 Mar 2014

[2]Agenda

[2] 
http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/0169.html

See also: [3]IRC log

[3] http://www.w3.org/2014/03/11-pointerevents-irc

Attendees

Present
Art_Barstow, Cathy_Chan, Rick_Byers, Asir_Vedamuthu,
Scott_Gonzαlez, Patrick_Lauke, Jacob_Rossi,
Matt_Brubeck, Olli_Pettay

Regrets
Sangwhan_Moon, Doug_Schepers

Chair
Art

Scribe
Art

Contents

* [4]Topics
1. [5]Tweak agenda
2. [6]Add 'manipulation' touch-action property?
3. [7]Bug 21749: Setting a capture on an offshore element
4. [8]Bug 24786: Propose a non-normative note re the
keyboard compat issue
5. [9]Bug 24921: Clarification of "Default Action" for
pointerdown wrt compat mouse
6. [10]Bug 24922: Tweak to 11. Compatibility Mapping with
Mouse Events
7. [11]Bug 24923: What should happen to the mouse events
if pointer event listener removes the target ...
8. [12]Bug 24971: Should got/lostpointercapture be
dispatched asynchronously or synchronously
9. [13]Open Actions for Jacob re spec updates
10. [14]Testing status
11. [15]CR implementation updates
12. [16]AoB
13. [17]moving touch-action to a separate spec
* [18]Summary of Action Items
__________________________________________________________

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

<smaug> hmm, skype didn't like a kernel update

Tweak agenda

AB: draft agenda sent to the list yesterday
[19]http://lists.w3.org/Archives/Public/public-pointer-events/2
014JanMar/0169.html.
... any change requests?

[19] 
http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/0169.html.

RB: we got a Q about putting touch-action in its own spec

… would like to understand the tradeoffs

… could be a diff re process

<patrick_h_lauke> take to list?

<mbrubeck_> I have no strong preference.

AB: we could add it or take it to the list
... let's add it if we have time

RB: OK

Add 'manipulation' touch-action property?

AB: Jacob's proposed text is in
[20]https://dvcs.w3.org/hg/pointerevents/rev/018f1b69c985;
followups on this thread:
[21]http://lists.w3.org/Archives/Public/public-pointer-events/2
014JanMar/thread.html#msg158.
... Need to get agreement on the text and grammar.

[20] https://dvcs.w3.org/hg/pointerevents/rev/018f1b69c985;
[21] 
http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/thread.html#msg158.

JR: I replied last night

[ Scribe is having a hard time hearing Jacob … ]

<rbyers> JR: Either we change the spec/IE to match MSDN docs,
or we just fix the MSDN docs

<rbyers> ... don't see much value in changing IE's behavior

RB: I don't have a strong pref

… agree it's a minor point

… if there is no good reason to have a surprising grammar

… comes down to if think this is a bug in IE, we should spec it
the right way

… but if IE is behaving as design, spec should match IE

JR: API could be more or less forgiving

… think the intent is already clear

<patrick_h_lauke> +1 if it's by design, spec should match IE.
otherwise, i'd have an idealistic spec with "magic" done by UAs
(if that doesn't introduce compat issues down the line)

… but I can see how there would be confusion in some cases

RB: not completely clear how it should be designed

<patrick_h_lauke> RB: how does this impact on IE, if you try to
get computed style, does pan-x get silently dropped

<patrick_h_lauke> JR: computed style should return exactly what
was specified, so pan-x should be returned as well

<patrick_h_lauke> np

JR: could make an argument either way

OP: have we asked CSS WG for feedback?

JR: good Q; no I have not

OP: I think we should ask

JR: I talked to some people and I agree we should ask

<patrick_h_lauke> whatever outcome, i'd like to just make sure
spec is unambiguous and does not open up door to future
incompatibility

<scribe> ACTION: Jacob ask CSS WG (www-style) re the Add
'manipulation' touch-action property issue [recorded in
[22]http://www.w3.org/2014/03/11-pointerevents-minutes.html#act
ion01]

<trackbot> Created ACTION-93 - Ask css wg (www-style) re the
add 'manipulation' touch-action property issue [on Jacob Rossi
- due 2014-03-18].

RB: I think we should just pick something now

AV: yes I agree

JR: agree we should just pick something

… I'll propose mutual exclusive solution

<patrick_h_lauke> +1

RB: that sounds fine with me

… and PL agreed

JR: this is a good example where we don't really need a test
case

<Cathy> +1

… since it isn't likely to impact developers

AB: if we agree on a solution, do we still need to ask CSSWG?

OP: yes, I think we should ask them

… I'll take that action

AB: thanks Olli

RESOLUTION: re manipulation touch-action property, we will
update the spec and consult with CSS WG

Bug 21749: Setting a capture on an offshore element

AB: [23]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21749.
Jacob made a proposal in
[24]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21749#c2.
... any comments, or is more time needed to review the
proposal?
... we need to ask Francois Remy for feedback before closing
the bug but we can record a resolution on the proposal.

[23] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21749.
[24] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21749#c2.

SG: what if pointercap set and then removed from the DOM

JR: in IE when leaves the DOM, looses capture

SG: common to pull elements out of DOM and put them back in

JR: this touches on another issue on the agenda

[ Scribe not getting all of Jacob's comments … ]

<smaug> nor me

OP: not clear what is the next possible target

… target could have moved to another document

… one option is to fire an event on the document

JR: I'd be OK with that

RB: what's the objection to firing lostcapture on the element
removed from the DOM

JR: can be problems with state machines keeping track

<smaug> (some odd background noise )

RB: ok, firing lostpointercapture at the doc is ok

SG: what about firing it on the element and then firing on the
document?

JR: we do something like that in some other scenarios

RB: what about lostcap is fired before the remove

OP: that is what mutation events do

… that's a reason for getting rid of them

RB: for this bug, I think we all agree there is a failure

… when a target is not in the document

JR: yes, agree; we are discussing a separate bug too

AB: do we want to create a new bug?

RB: easier to generalize this bug

<scribe> ACTION: Jacob Bug 21749: update the bug to reflect
discussion on 2014-Mar-11 [recorded in
[25]http://www.w3.org/2014/03/11-pointerevents-minutes.html#act
ion02]

<trackbot> Created ACTION-94 - Bug 21749: update the bug to
reflect discussion on 2014-mar-11 [on Jacob Rossi - due
2014-03-18].

RESOLUTION: Bug 21749 group agree with Jacob's comment #2

Bug 24786: Propose a non-normative note re the keyboard compat issue

AB: [26]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24786.
Patrick's proposal is in comment #6
[27]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24786#c6.
... Rick and Jacob expressed support for Patrick's comment
(although Rick suggested a minor tweek).
... any comments or objections to the proposal, including
Rick's clarification request?

[26] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24786.
[27] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24786#c6.

<patrick_h_lauke> happy with RB's tweak, good catch

RESOLUTION: Bug 24786: group agrees with PL's proposal + RB's
clarification

<scribe> ACTION: Jacob Bug 24796: implement agreement discussed
on 2014-Mar-11 and then Resolve/Fix the bug [recorded in
[28]http://www.w3.org/2014/03/11-pointerevents-minutes.html#act
ion03]

<trackbot> Created ACTION-95 - Bug 24796: implement agreement
discussed on 2014-mar-11 and then resolve/fix the bug [on Jacob
Rossi - due 2014-03-18].

Bug 24921: Clarification of "Default Action" for pointerdown wrt
compat mouse

AB: [29]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24921.
Patrick created this bug to address action-88 and it contains
proposed text to review.
... Jacob said he is fine with the proposal. Any other
comments?

[29] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24921.

<jrossi> yeah i'll contribute from IRC

RB: I like it

JR: ok with me

RESOLUTION: Bug 24921: group agrees with PL's proposed text

<patrick_h_lauke> :)

<scribe> ACTION: Jacob Bug 24921: implement PL's proposed text
as agreed on 2014-Mar-11 and then Resolve/Fix the bug [recorded
in
[30]http://www.w3.org/2014/03/11-pointerevents-minutes.html#act
ion04]

<trackbot> Created ACTION-96 - Bug 24921: implement pl's
proposed text as agreed on 2014-mar-11 and then resolve/fix the
bug [on Jacob Rossi - due 2014-03-18].

Bug 24922: Tweak to 11. Compatibility Mapping with Mouse Events

AB: [31]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24922.
New bug by Patrick including proposed text changes.
... Jacob said he is fine with the proposal. Any other
comments?

[31] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24922.

RB: LGTM

AB LGTM2

RESOLUTION: Bug 24922: group agrees with PL's proposed text

<scribe> ACTION: Jacob Bug 24922: implement PL's proposed text
as agreed on 2014-Mar-11 and then Resolve/Fix the bug [recorded
in
[32]http://www.w3.org/2014/03/11-pointerevents-minutes.html#act
ion05]

<trackbot> Created ACTION-97 - Bug 24922: implement pl's
proposed text as agreed on 2014-mar-11 and then resolve/fix the
bug [on Jacob Rossi - due 2014-03-18].

Bug 24923: What should happen to the mouse events if pointer event
listener removes the target ...

AB: [33]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24923.
New bug by Olli and comments from Scott, Rick, Jacob and a
proposal by Patrick in
[34]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24923#c12.

[33] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24923.
[34] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24923#c12.

<patrick_h_lauke> i have no strong opinions on this bug btw

<patrick_h_lauke> looking at this purely from a noob
perspective, not knowing what the "PROPER" behavior as per DOM
etc should be

<patrick_h_lauke> so more my naive "i know basic JS, enough to
be dangerous" view on it

JR: want some more time to think about this

… we might need some more defns

<mbrubeck> If we go with something like the proposal, perhaps
we should use "an ancestor" instead of "the parent"

RB: agree this is non-trivial if we want to specify this

JR: need to investigate IE behavior

AB: we agree then to continue discussion on the list

<scott_gonzalez>
[35]http://dev-test.nemikor.com/behavior/mouseover-when-element
-is-shown.html

[35] 
http://dev-test.nemikor.com/behavior/mouseover-when-element-is-shown.html

SG: re my comment, and "mouse spec", need to be be clear about
what changes in the DOM
... if put mouse into green box, it will turn red

… a new element is created under the mouse and it will be red

… it will be pink if hovering

JR: I agree this is not in scope for PE

<rbyers> Note this is considered (by some at least) a bug in
blink: [36]http://crbug.com/246304

[36] http://crbug.com/246304

SG: this is a manifestiation of mouse events in general

… think FF does the best

RB: we need to fix this in Blink to make it work like FF

SG: we see issues with autocomplete scenarios and hover

RB: agree it is out of scope for this group

… we need to figure this out though in the appropariate
place/group

OP: yes I agree

SG: there are three scenarios and we need to agree on behavior
for all 3

… 1) remove from doc and stays out

[ Scribe didn't get Scott's 3 scenarios ]

JR: we don't want to have to do hit testing again

RB: agree; that creates issues

AB: please continue discussion in the bug

Bug 24971: Should got/lostpointercapture be dispatched asynchronously
or synchronously

AB: [37]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24971.
New bug by Olli; needs feedback.
... Jacob said he needs to do some investigation. Any other
feedback?

[37] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24971.

OP: why would ever want then to be dispatched asynchronously

RB: Jacob mentioned stack overflow potential
... this could be a web compat issue

OP: this came up as I reviewed a patch for Gecko

JR: I need to look at our code

AB: there's agreement to keep this bug open and for everyone to
noodle on it

Open Actions for Jacob re spec updates

AB: This topic is just a reminder that Jacob has a few actions
to update the spec (Action-51, Action-62, Action-63,
Action-65, Action-70). I wasn't expecting to discuss these
today unless someone has something specific to say.

JR: I'll get to them ;)

MB: I also have an open action re an issue AvK raised

Testing status

AB: any new info re testing?
... status is we are waiting for updates from Jacob/Asir

<patrick_h_lauke>
[38]http://lists.w3.org/Archives/Public/public-pointer-events/2
014JanMar/0172.html

[38] 
http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/0172.html

AB: how about we defer discssion to the list for now if no
resolution, we'll add it to a meeting agenda

CR implementation updates

AB: any new info re implementations?

<patrick_h_lauke> yup sorry, let's continue on list for this
(i'll make a bug). just that it popped into my head

<smaug>
([39]http://mozilla.pettay.fi/moztests/events/event_loop.html
is my old event dispatching loop test for recursion depth)

[39] http://mozilla.pettay.fi/moztests/events/event_loop.html

RB: I sent out an Intent to Ship for touch-action

… I don't expect any major issues

OP: we have some issues to fix

<rbyers> blink touch-action "Intent to ship" thread:
[40]https://groups.google.com/a/chromium.org/forum/#!searchin/b
link-dev/CSS$20touch-action/blink-dev/sc5lHnlcLvM/ntJWuKKHUqYJ

[40] 
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/CSS$20touch-action/blink-dev/sc5lHnlcLvM/ntJWuKKHUqYJ

OP: the issues I filed are blocking Gecko

AB: that's good info. We need to make those bugs high prio

AV: what about auto-loading the pollyfill Rick?

RB: we have some things to do first but that's still in plan

… we need to some research

AV: a Chrome extension to load the polyfill?

RB: yes

AV: ok, thanks

AoB

AB: anything else for today?

moving touch-action to a separate spec

JR: need to think about this

RB: I understand it might not be worth the effort

… but I need to provide an answer

JR: think splitting it out raises too many issues

RB: sounds good; I'll report that and we can go from there

JR: think there is too much info that would need to be moved

AB: we have a `temporary` resolution to not split out
touch-action into a separate spec
... meeting adjourned

Summary of Action Items

[NEW] ACTION: Jacob ask CSS WG (www-style) re the Add
'manipulation' touch-action property issue [recorded in
[41]http://www.w3.org/2014/03/11-pointerevents-minutes.html#act
ion01]
[NEW] ACTION: Jacob Bug 21749: update the bug to reflect
discussion on 2014-Mar-11 [recorded in
[42]http://www.w3.org/2014/03/11-pointerevents-minutes.html#act
ion02]
[NEW] ACTION: Jacob Bug 24796: implement agreement discussed on
2014-Mar-11 and then Resolve/Fix the bug [recorded in
[43]http://www.w3.org/2014/03/11-pointerevents-minutes.html#act
ion03]
[NEW] ACTION: Jacob Bug 24921: implement PL's proposed text as
agreed on 2014-Mar-11 and then Resolve/Fix the bug [recorded in
[44]http://www.w3.org/2014/03/11-pointerevents-minutes.html#act
ion04]
[NEW] ACTION: Jacob Bug 24922: implement PL's proposed text as
agreed on 2014-Mar-11 and then Resolve/Fix the bug [recorded in
[45]http://www.w3.org/2014/03/11-pointerevents-minutes.html#act
ion05]

[End of minutes]

Received on Tuesday, 11 March 2014 16:14:20 UTC