See also: IRC log
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
Date: 11 September 2012
AB: yesterday I submitted a draft
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
... 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).
AB: so, the general topic is
"what must be done to complete a test suite for the TEv1
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 http://w3c-test.org/webevents/tests/touch-events-v1/submissions/Mozilla/.
... 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 assertions.
... 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. 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
… 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 tests?
<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 painful
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 http://www.w3.org/2012/09/11-webevents-minutes.html#action01]
<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 http://www.w3.org/2012/09/11-webevents-minutes.html#action02]
<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 device...
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 http://www.w3.org/TR/2011/CR-touch-events-20111215/#extensions-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 directly
<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 sense
AB: I'd say that people should make a recommendation
RB: ok, I'll take an action to create one test before the next meeting
<scribe> ACTION: Rick create a new test case for the TEv1 spec [recorded in http://www.w3.org/2012/09/11-webevents-minutes.html#action03]
<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
... 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
... anything else for today on testing?
AB: Rick started a thread about
... 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? - 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 identfier
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 events
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 iOS
… 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 idea)
<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  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
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
AB: any other business/topics for
... re next meeting ...
… I say in two weeks (CfRs will have been done)
… meeting adjourned
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/FF/Safari/ Succeeded: s/can a/can add a/ Found Scribe: Art Found ScribeNick: ArtB Default Present: +358.718.00aaaa, sangwhan, Scott_González, Olli_Pettay Present: Art_Barstow Cathy_Chan Rick_Byers Sangwhan_Moon Scott_González Olli_Pettay Agenda: http://lists.w3.org/Archives/Public/public-webevents/2012JulSep/0020.html Found Date: 11 Sep 2012 Guessing minutes URL: http://www.w3.org/2012/09/11-webevents-minutes.html People with action items: barstow report rick WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]