Web Events WG Voice Conference -- 14 Jun 2011

<shepazu> ArtB: didn't smaug take that on?

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Date: 14 June 2011

<mbrubeck> dialing...

Tweak Agenda

AB: I submitted a draft agenda yesterday ( http://lists.w3.org/Archives/Public/public-webevents/2011AprJun/0124.html ). Any change requests?

Announcements

AB: any short announcements for today?

Issue-3 Click event target after DOM mutation during touchstart

AB: Issue-3 is one of our older issues ( http://www.w3.org/2010/webevents/track/issues/3 ) and Doug has one open action for it ( http://www.w3.org/2010/webevents/track/actions/23 )

OP: I was wondering if we can specify in a more exact way
... but it depends on the device
... perhaps it is enough to say impls should dispense mouse up

MB: I agree with that

AB: we discussed this issue on June 7 ( http://www.w3.org/2011/06/07-webevents-minutes.html#item05 ). On June 13, Olli followed up with an e-mail that closed his related Action-51 and proposed a spec change ( http://lists.w3.org/Archives/Public/public-webevents/2011AprJun/0123.html )

[ group pauses to read Olli's proposal ]

DS: this looks OK to me

LG: looks ok
... but the device specific
... part isn't clear

OP: the OS may give some additional info

MB: scrolling can be done via diff gestures
... some cases may not want to wait

LG: so, this is more about product decisions
... and not really about the OS per se

DS: should we say something about why it is not a MUST?

MB: I can take an action to integrate OP's proposal into the spec
... and to add some non-normative rationale

OP: my proposal is a bit stronger then what is in the spec

DS: agree that SHOULD is better here

<scribe> ACTION: matt integrate Olli's proposal for Issue-3 (action-51) [recorded in http://www.w3.org/2011/06/14-webevents-minutes.html#action01]

<trackbot> Created ACTION-52 - Integrate Olli's proposal for Issue-3 (action-51) [on Matt Brubeck - due 2011-06-21].

AB: after Matt completes Action-52, do we consider this issue as closed?

<smaug> ACTION-23 can be probably closed

AB: I don't think we need any additional followup
... anything else on this issue?

DS: so Matt will close the issue after addressing action-52?

MB: yes

AB: please include the changeset number

MB: will do

Issue-16 Should the spec be silent or prescriptive re Object Identity

AB: Issue-16 ( http://www.w3.org/2010/webevents/track/issues/16 ) actually raises 2 questions/issues. Laszlo submitted feedback for this issue before our June 7 call ( http://lists.w3.org/Archives/Public/public-webevents/2011AprJun/0121.html ). We briefly talked about this issue on June 7 ( http://www.w3.org/2011/06/07-webevents-minutes.html#item06 ) and everyone was actioned to read Laszlo's e-mail.
... perhaps it would be helpful to look at each question in the issue separately: 1) "Should the Touch Events standard specify whether certain operations return the same object?" and 2) "Should different touch events refer to the same objects?".
... re question #1, Matt - do you have a proposal for an answer?

MB: not sure but lean toward Yes
... it could be an interop issue
... and need to think about LG's input

LG: most objects aren't the same
... if they are, we can note that

DS: re question #2, I would expect each touch event would have a unique identifier

MB: I think that is a reasonable expectation
... but PPK noted that in some Webkit impls, events were reused

DS: that seems like a but to me

MB: agree and that bug has been fixed in newer version of Webkit

<smaug> not events but touch objects were reused in webkit, I think

DS: if we are going to do some mapping b/w low to high events

<mbrubeck> from http://www.quirksmode.org/blog/archives/2010/02/persistent_touc.html it sounds like it was the TouchEvent object that was reused.

<smaug> huh

DS: then we may need identify to refer to specific touch events
... but it seems like we need unique id for every touch event (but not every touch point)

MB: no other DOM type spec talks about this
... this came up because of earlier versions of Webkit
... and their inconsistency with newer impls and other DOM specs
... Given the new impls, perhaps we don't even need to mention this

DS: even if we don't spec a binding from low to high level events, I think developers will need to do that
... I think there is value in defining unique touch events

<smaug> ah, looks like iPhone used to cache/reuse the touchpoint *list*, at least based on the quircksmode example

DS: would be good to talk to others, like Sencha about this
... We want to specify things where the current unspecified behavior is leading to interop probs
... We coud spec something and then if feedback is negative, we can remove it

LG: sounds OK to me

OP: yes (the old WK behavior is a bug)

AB: is anyone willing to create a proposal for text to address issue-16?

DS: I can make a proposal

<scribe> ACTION: doug create a proposal to address issue-16 [recorded in http://www.w3.org/2011/06/14-webevents-minutes.html#action02]

<trackbot> Created ACTION-53 - Create a proposal to address issue-16 [on Doug Schepers - due 2011-06-21].

AB: do you need anything else from us Doug?

DS: if I need anything, I'll ask on the list

<scribe> ACTION: barstow move issue-16 to Open [recorded in http://www.w3.org/2011/06/14-webevents-minutes.html#action03]

<trackbot> Created ACTION-54 - Move issue-16 to Open [on Arthur Barstow - due 2011-06-21].

AB: anything else on issue-16?

[ No ]

Issue-17 Page X and Y parameters to createTouch

AB: Issue-17 ( http://www.w3.org/2010/webevents/track/issues/17 ). We talked about this issue on June 7 ( http://www.w3.org/2011/06/07-webevents-minutes.html#item04 ). The status is that Matt submitted changeset #94 for this issue ( http://dvcs.w3.org/hg/webevents/rev/53491ff3514b ). Olli agreed with this patch and Laszlo said he needed to review the changeset vis-à-vis Webkit.
... changeset #94 removes clientX/Y from initTouchEvent since they can be computed. Olli noted WebKit is inconsistent here (initTouchEvent vs. document.createTouch)
... so there are two related things here: 1) are there any objections to changeset #94 and 2) the spec's initTouchEvent method ( http://dvcs.w3.org/hg/webevents/raw-file/default/touchevents.html#methods-1 ) which has no screenX/Y nor clientX/Y is not consistent with WebKit's implementation ( http://trac.webkit.org/browser/trunk/Source/WebCore/dom/TouchEvent.cpp#L55 ) and ( http://www.opensource.apple.com/source/WebCore/WebCore-658.28/dom/TouchEvent.idl )

<mbrubeck> initTouchEvent in WebKit takes a bunch of parameters that it simply ignores. For full compatibility, we'd need to add a bunch of dummy parameters to initTouchEvent...

AB: let's start with changeset #94. Any objections to that i.e. remove clientX/Y?
... any objections to changeset #94?

[ None ]

AB: consider that changeset accepted

<mbrubeck> well, I guess it doesn't totally ignore them... need to do more research

AB: ok, initTouchEvent signatures - what, if anything do we want to do here to align the APIs?

<smaug> TouchEvent.idl is bizarre. You can pass clientX/Y as parameters but can't you them

DS: I don't think we need to totally align the interfaces

<mbrubeck> http://www.opensource.apple.com/source/WebCore/WebCore-658.28/dom/UIEvent.idl (the parent interface) has pageX/pageY accessors)

DS: we could make our API identical to Webkit
... A script lib can take care of the diffs
... e.g. give the "right" initializer

MB: I haven't seem any code in the wild that uses these initializers
... I have seen some test cases for it

DS: so that says if Webkit wants to align with our spec, it would be easy for them to do
... there are other differences, I think

LG: I haven't looked into the details of this

<mbrubeck> ah, and it looks like layerX/layerY correspond to the pageX/pageY parameters - http://www.google.com/codesearch#N6Qhr5kJSgQ/WebCore/dom/MouseRelatedEvent.cpp&q=initCoordinates&l=104

LG: I don't fully understand why we want to remove this
... but if this change is going in the right direction, perhaps Webkit woud follow
... The main rationale here is what?

MB: in WK, initTouchEvents takes one set of params and our spec uses another set of params
... in some cases, we don't understand why WK uses the coordinates

<smaug> webkit's TouchEvent doesn't have .clientX/Y or .screenX/Y, only .pageX/Y .layerX/Y (which are in UIEvent)

DS: has anyone done any testing to see about the use of 'clientX/Y'

<smaug> http://trac.webkit.org/browser/trunk/Source/WebCore/dom/UIEvent.idl http://trac.webkit.org/browser/trunk/Source/WebCore/dom/UIEvent.idl

<smaug> http://trac.webkit.org/browser/trunk/Source/WebCore/dom/TouchEvent.idl

LG: there is some code shared among WK ports and there is some device-specific code
... not clear where these APIs fall
... I can look into this before the next call

DS: I can understand that f.ex. the 1st or last touch points may have some semantics

MB: the scenarios can get complex with multi-touch

DS: perhaps there is some convenience for them

MB: I don't want to include params if we don't have real need for them

DS: I think some WK testing would be useful
... cases: not used, 1st touch event, most recent [last]
... Laszlo, can you do some testing here?

LG: yes, I can take an action for that

<scribe> ACTION: laszlo do some analysis of Webkit's implementations re Issue-17 [recorded in http://www.w3.org/2011/06/14-webevents-minutes.html#action04]

<trackbot> Created ACTION-55 - Do some analysis of Webkit's implementations re Issue-17 [on Laszlo Gombos - due 2011-06-21].

AB: can anyone help LG with this?

DS: we need some tests
... I can test on other platforms if that is helpful?

LG: what other platforms other than WK?

MB: Opera Mobile 11 supports touch events

DS: so step 1 is to create tests; step 2 is to test on WK; step 3 is to test on Opera

<mbrubeck> If current implementations don't actually have specific semantics for TouchEvent.pageX/Y, I don't want to add them because I feel they will be a trap for authors. Using them will be convenient, but will lead to surprise. Using the TouchList properties is a little less convenient, but forces authors to think about what happens when more than one TouchPoint is present, so they won't be surprised.

AB: any last comments about issue-17?

Any Other Business (AOB)

<smaug> vacation? what is that?

<mbrubeck> :)

AB: next meeting, I'm thinking 2 weeks from now

DS: most issues are now closed
... where are we with this spec?
... are there other things missing?

OP: I think we need to clarify the various lists
... what are they for example

LG: in one of my e-mails I mentioned some of this

MB: last week I checked in some changes that do some of these clarifications

<mbrubeck> http://dvcs.w3.org/hg/webevents/rev/457c2df41b66

AB: is this an issue or an action?

DS: prefer to create an Issue
... so we can create associated actions
... track the discussions, etc.

<lgombos> smaug: info on changedTouches - http://trac.webkit.org/changeset/58323/trunk/WebCore/page/EventHandler.cpp.

AB: agree, it gives a good paper trail

MB: but we still need some examples

ISSUE: the spec needs more examples related to the various lists

<trackbot> Created ISSUE-18 - The spec needs more examples related to the various lists ; please complete additional details at http://www.w3.org/2010/webevents/track/issues/18/edit .

DS: are we close to Last Call?

<mbrubeck> We need more tests. I'll be able to add more as the Mozilla Mobile team starts work on multi-touch.

AB: yes, it looks like we are gettig close
... to LC, that is

DS: are we using the text markup to facilitate test case extractions

MB: we discussed this on a call when Doug wasn't here
... Sangwhan and I agreed it would be good to use that markup

DS: OK, I'll take an action to do so

<mbrubeck> Past discussion here: http://www.w3.org/2011/04/26-webevents-minutes.html

<mbrubeck> http://www.w3.org/2011/04/26-webevents-minutes.html#item03

<scribe> ACTION: Doug update the Touch Event spec to use markup to facilitate test case extraction [recorded in http://www.w3.org/2011/06/14-webevents-minutes.html#action05]

<trackbot> Created ACTION-56 - Update the Touch Event spec to use markup to facilitate test case extraction [on Doug Schepers - due 2011-06-21].

AB: will action-56 block LC?

DS: it shouldn't block it
... if that process creates issues, that's good
... does it appear the touch shape area is adequately spec'ed?

MB: we have already received comments on that and it appears solid
... we are lacking TouchLeave and TouchEnter feedback
... they are new parts

DS: well, LC is a great way to get feedback

AB: yes, LC is important because it says "the group thinks it is done"
... I think a LC in July or August is possible

DS: would like to get it ready in the next two weeks

MB: how important is a good set of test cases re going into LC

DS: I would like to have a good set of test cases before LC

MB: a colleague of mine has some relevant test cases
... I will see if they can be ported to our test framework
... that could get some tests for us within a few weeks

DS: the test suite is required in Candidate phase
... but it's always better to have test cases earlier

MB: the spec is already being written around existing impl

DS: some rigor about what needs to be tested
... and a plan to flesh it out
... should be considered the minimum before going to LC
... My action-56 should give us a very good idea of the scope of the test suite
... and I will try to do this within the next two weeks
... and I *LOVE* creating test cases!

AB: excellent! You Da' Man Doug!
... in summary, we have a few issues to address and a couple of high priority actions to complete
... and a more complete test suite
... and then we will be ready for LC
... But that all seems do-able in July (or August)
... it would be good if we had an idea about the Intentional Events spec

DS: agree but this can help others with their decision to participate

[ Some discussions about how to test the various features on multi-touch ... ]

DS: if we have some stuff in the spec that isn't widely implemented, we could put those features in a v2 spec
... and then we can advance v1 quicker

MB: yes, I can see some value in that

DS: the 3 things: TouchEnter, TouchLeave and Touch Area
... may be better to move into v2 spec
... and v1 is the "this works today" spec

<mbrubeck> (where "Touch Area" refers to radiusX/radiusX/rotationAngle)

<mbrubeck> also, "force"

DS: how to do people think about this v1 and v2 idea?

MB: I like it

SM: makes sense (kinda' like widgets v1 and v2)

AB: I don't have a strong opinion either way

OP: make sense to me to have a v2 now
... then it is like XHR1 and XHR2

LG: yes, I think it makes sense but don't have a strong opinion

CC: yes, agree with LG

AB: propose resolution: Touch Enter, Leave, Area and Force are moved to a v2 spec immediately

MB: from a logistics view,
... we should add a v2 branch in the Mercurial repo

DS: can you do that Matt?

MB: yes

DS: are merges easy?

MB: usually but may need some manual intervention

AB: any objections to the proposed resolution above?

[ None ]

RESOLUTION: Touch Enter, Leave, Area and Force will be moved to a v2 spec

AB: so, next meeting
... next week?
... any objections to a meeting on June 21?
... next meeting is June 21
... please address Open Actions as soon as you can!
... meeting adjourned

- DRAFT -

Web Events WG Voice Conference

14 Jun 2011

Attendees

Contents