See also: IRC log
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
<smaug> hmm, skype didn't like a kernel update
AB: draft agenda sent to the list
yesterday
http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/0169.html.
... any change requests?
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
AB: Jacob's proposed text is in
https://dvcs.w3.org/hg/pointerevents/rev/018f1b69c985;
followups on this thread:
http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/thread.html#msg158.
... Need to get agreement on the text and grammar.
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 http://www.w3.org/2014/03/11-pointerevents-minutes.html#action01]
<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
AB: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21749.
Jacob made a proposal in 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.
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 http://www.w3.org/2014/03/11-pointerevents-minutes.html#action02]
<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
AB: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24786.
Patrick's proposal is in comment #6 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?
<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 http://www.w3.org/2014/03/11-pointerevents-minutes.html#action03]
<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].
AB: 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?
<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 http://www.w3.org/2014/03/11-pointerevents-minutes.html#action04]
<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].
AB: 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?
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 http://www.w3.org/2014/03/11-pointerevents-minutes.html#action05]
<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].
AB: 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 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> 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: 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
AB: 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?
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
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
AB: any new info re
testing?
... status is we are waiting for updates from Jacob/Asir
<patrick_h_lauke> 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
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> (http://mozilla.pettay.fi/moztests/events/event_loop.html is my old event dispatching loop test for recursion depth)
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: 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
AB: anything else for today?
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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/remove from doc/1) remove from doc/ Found ScribeNick: ArtB Found Scribe: Art 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 Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/0169.html Got date from IRC log name: 11 Mar 2014 Guessing minutes URL: http://www.w3.org/2014/03/11-pointerevents-minutes.html People with action items: jacob WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]