W3C home > Mailing lists > Public > public-webevents@w3.org > July to September 2012

Draft Minutes: 11 September 2012 call

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 11 Sep 2012 12:37:04 -0400
Message-ID: <504F68B0.4090208@nokia.com>
To: "public-webevents@w3.org" <public-webevents@w3.org>
The draft minutes from the September 11 voice conference are available 
at <http://www.w3.org/2012/09/11-webevents-minutes.html> and copied below.

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

-Thanks, ArtB


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


Web Events WG Voice Conference

11 Sep 2012



See also: [3]IRC log

[3] http://www.w3.org/2012/09/11-webevents-irc


Art_Barstow, Cathy_Chan, Rick_Byers, Sangwhan_Moon,
Scott_Gonzαlez, Olli_Pettay




* [4]Topics
1. [5]Tweak Agenda
2. [6]Announcements
3. [7]Testing the Touch Events v1 Candidate
4. [8]Encourage more consistent semantics of
5. [9]AoB
* [10]Summary of Action Items

<scribe> Scribe: Art

<scribe> ScribeNick: ArtB

Date: 11 September 2012

<smaug_> argh

Tweak Agenda

AB: yesterday I submitted a draft agenda
lSep/0020.html. After I submitted the agenda, there was a short
exchange between me and Rick re test results for TEv1 spec and
if there are related follow-ups, we can discuss them during the
Testing topic.
... Any change requests?


<smaug_> ArtB: ^

<smaug_> I'm in a bad place without external mic


AB: any short announcements for today (I don't have any).

Testing the Touch Events v1 Candidate

AB: so, the general topic is "what must be done to complete a
test suite for the TEv1 Candidate?"
[12]http://www.w3.org/TR/2011/CR-touch-events-20111215/. There
are also a few sub-topics I want to discuss.
... re the existing tests ...
... yesterday I did a line-by-line review of Matt's
single-touch tests
... I think they are all good tests. I was pleasantly surprised
by the coverage because the report says 17 tests are run but
depending on how one counts, that file includes over 40
... some related sub-topics are: 1) how does the group comes to
consensus on the "goodness" of a test?; and 2) how are
"good/approved" tests designated as such?
... the WebApps and HTML WGs handle these two issues by having
an explicit "Call for Review" (CfR) for tests with a fixed
period. If no negative comments are submitted, the tests are
copied to an "approved" directory (f.ex.
[14]http://w3c-test.org/webapps/DOMCore/tests/approved/). I'd
say that process work "reasonably well".
... I think we're going to need something like this
... any comments on how we should address these two issues?
... an advantage is that it is lightweight

[12] http://www.w3.org/TR/2011/CR-touch-events-20111215/.
[14] http://w3c-test.org/webapps/DOMCore/tests/approved/).

… and I'm willing to do the admin stuff

AB: any comments?

<smaug_> would be really nice to get tests also from others
than just Mozilla

… hearing none, I propose we adopt a similar model

AB: any objections to WebEvents adoptiong a similar test
approval process?

[ None ]

RESOLUTION: WebEvents will use the same test case approval
process that is used by the WebApps and HTML WGs

AB: I can start a CfR for the single-touch tests and a separate
CfR for Olli's multi-touch tests. How much time do people need?

RB: I already worked reviewed them

SM: the process is a bit different than what we use

… so that is my objection

<smaug_> it varies how many tests one test file actually has

<smaug_> I mean, it varies in webapps too

SM: it's not really an objection

… I may be able to reuse some of Opera's tests

<smaug_> IIRC multi-touch.html was mainly as an example how to
add tests for multitouch

… and that can take some unpredictable amount of tests

RB: but those are two different issues (reviewing existing
tests and submitting new tests)

… I'd like to submit some too

SM: yes, I guess you're right

AB: any objection to two week review for the existing tests?

[ None ]

AB: I can start a CfR for the single-touch tests and a separate
CfR for Olli's multi-touch tests; two week review period
... so Olli, are you OK with starting a CfR for the mulit-touch

<smaug_> I don't think that is needed

<smaug_> IIRC sangwhan or someone was going to write more tests

<smaug_> based on the multi-touch.html test

AB: so Olli, you mean they aren't ready for review?

SM: I'd like to convert our tests to testharness.js

… but I don't have approval for that yet

<smaug_> ArtB: multi-touch.html is ok, but we may want to split
the tests differently

<smaug_> I mean, to more files

RB: I think talking about organization make sense

<smaug_> sounds quite nice

<rbyers> Question on test organization seems coupled to the
question of whether the test suite will be manual-only

<rbyers> If so, organizing to minimize the number of manual
steps required seems critical

AB: yes, that make sense
... my recommendation is that we do a CfR for the multi-touch
tests too and then reviewers can comment on whether or not it
would be better to split the file until multiple files

<sangwhan> my question "has any WG started using
webdriver/selenium/watir?" was sort of related to the point
that rick raised, in a sense that manual tests are no fun so
either make a manual test test multiple things with minimal
user interaction possible, or split everything up but do it in
something like webdriver/selenium/watir to make tests less

AB: any objections to two CfRs now?

[ None ]

AB: so I'll start two different CfRs

<smaug_> webdriver/selenium etc don't work everywhere

<sangwhan> that's true

AB: there is some work being done by the Browser Test Tools WG

… I don't follow that group closely

… but I can find out their status re WebDriver

<scribe> ACTION: report on the status of WebDriver work by the
Browser Test Tools WG [recorded in

<trackbot> Sorry, couldn't find user - report

<rbyers> Right, I propose that the tests should always have the
option of being run manually

<scribe> ACTION: Barstow report on the status of WebDriver work
by the Browser Test Tools WG [recorded in

<trackbot> Created ACTION-97 - Report on the status of
WebDriver work by the Browser Test Tools WG [on Arthur Barstow
- due 2012-09-18].

<rbyers> so that we can test on any sort of browser / mobile

RB: want to make sure the tests can be run manually

… so can run on any mobile devices

AB: I agree

<sangwhan> Fair point, yes

AB: we haven't really talked about basic principles or
constraints or requirements re testing

… if someone wants to do so, that would be good

AB: so the next question is how many more tests are needed to
test the CR?
... some gaps I noticed when reviewing single-touch are: the 3
methods that extend the Document interface
ons-to-the-document-interface; cancelevent (could be hard to
automate?); preventDefault
... I guess there is also Cathy's analysis to use
... how are we doing to determine "the test suite is done"?


<smaug_> ( multitouch case will need plenty of tests for
various touch lists)

… that question could be a bit premature if people haven't yet
reviewed what we do have

RB: one thing I am struggling with is the level of UA details

… e.g. preventDefault

… could be hard f.ex. to determine exact coordinates

AB: that's a good point

… and to extent I think that comes back to some previous
discussions we've had regarding the level of depth testing we
need to do

<smaug_> (Default handling is defined in the spec for certain
cases, so there is stuff to test)

AB: do we have any volunteers to help us figure out a plan for
the testing?

RB: I volunteer to review the spec (as I'm analyzing the
existing tests) and note those areas that are not tested

… What do I do if I want to create some new tests/assertions?

<smaug_> would be nice to get patch files if one decides to
also fix testcases, not only review them

AB: I would say bug fixes and smalll additions could be done

<sangwhan> forking/branching is definitely a option, .patch is
a option, committing directly to tip would be another option

… for more significant additions, a separate file may make more

AB: I'd say that people should make a recommendation

RB: ok, I'll take an action to create one test before the next

<scribe> ACTION: Rick create a new test case for the TEv1 spec
[recorded in

<trackbot> Created ACTION-98 - Create a new test case for the
TEv1 spec [on Rick Byers - due 2012-09-18].

SM: if the spec is underspecified re UA behavior, I'd like to
hear about it

RB: for example the scrolling text in the touch event text
leaves a lot of flexibility for UAs
... perhaps the test suite should just focus on the API and not
UA behavior/semantics at all

AB: in general I agree

… and in that sense, the text as written today is "good enough"

AB: I'll ping Matt about his action related to "so, what test
cases are missing from the v1 test suite"
... anything else for today on testing?

Encourage more consistent semantics of Touch.identifier?

AB: Rick started a thread about Touch.identifier
... I think one of the main questions is if the spec is under
specified re Touch.identifier and/or if should additional
non-normative hints should be provided


RB: this came from a demo I wrote

… it showed colors are different from iOS and Adroid

… I used identifier to influence color

… Behaviour differences can be a problem though

… some people will consider this as a bug

… Re the spec, the existing text re identifier may be OK

… but we should talk about it

<smaug_> IMO the spec is clear enough. id is id, not any
specific number. (Perhaps id should have been string)

… May want all of the implementations to do the same thing here

<Cathy> Is this related to a previous issue we had? -

[20] http://www.w3.org/2010/webevents/track/issues/15

SG: re Msft's PointerEvents, they reserve id 0 for the mouse

… all pointer events that come from the mouse have the same

… SG:


RB: we could say id 0 is reserved

… So Matt raised this issue back in April

… Oh, this explains Chrome's behavior

<smaug_> I haven't seen any bug reports in Mozilla's bugzilla
about this issue. Are there any in webkit's bugzilla or in
Opera's bug database?

… and the spec was changed based on Matt's feedback

SM: I don't think Safari will change its impl

<sangwhan> The main issue is that current implementations will
probably not change based on a constraint that is introduced in
the specification, namely the first implementation of touch

AB: so what do you think Rick?

RB: I didn't realize a previous decision has been made

… I think we will probably mean we will change Chrome to match

… Would like to hear from others

… Should we intentionally constrain impls here?

<sangwhan> Opera does follow the algorithm that Matt mentions
in the issue noted above, with a exception that the non-primary
touch points will change identifiers, which is due to how we
internally handle touch points

AB: there is needs to be a balance

… and need to reflect what's been implemented

<rbyers> sangwhan: what do you mean 'change identifiers'? It
can't change while the touch point is active, right?

<sangwhan> e.g. So first two touches will be [0,1] but the
second will be [0,2] and the third with three touch points will
be like [0,3,4] (I'm not testing this live, so that's just a

<rbyers> Makes sense

SM: need to know the primary touch

… perhaps we can add a small constraint re the primary touch
should be 0

RB: should we put something in the spec that mobile Safari will
never conform to

SM: yeah, this is a tricky call

… if we add that small constraint, I don't think we will have a
large interop issue

<smaug_> why you need to special case the "primary touch".
Shouldn't that be [$1\47] in the touch list

SG: if you have a "primary" touch, then a 2nd and then lift the
first finger, the 2nd becomes the primary

AB: should we take this to the list?

RB: I think it would be OK to keep v1 as is and to consider
this change for v2

… would that be OK?

AB: yes, that would be OK

<smaug_> arg

RB: I don't feel strongly enough about this to not change v1 at
this point

<sangwhan> Either way works for me (less editing, at least ;))

AB: any additional followups should be done on the list

<smaug_> thanks


AB: any other business/topics for today?
... re next meeting ...

… I say in two weeks (CfRs will have been done)

… meeting adjourned

Summary of Action Items

[NEW] ACTION: Barstow report on the status of WebDriver work by
the Browser Test Tools WG [recorded in
[NEW] ACTION: report on the status of WebDriver work by the
Browser Test Tools WG [recorded in
[NEW] ACTION: Rick create a new test case for the TEv1 spec
[recorded in

[End of minutes]
Received on Tuesday, 11 September 2012 16:37:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:54 UTC