<jgraham> I think gsnedders and I will not be around much

Will anyone else be dialing in?

<jgraham> We have to leave at 17:25

That is fine - should be a quick meeting

<scribe> Scribe: krisk (note most folks are on IRC)

Agenda Item #1 Check for any bugs on approved tests (currently zero)

Ms2ger - posted about XHTML5 tests see -> http://lists.w3.org/Archives/Public/public-html-testsuite/2010Aug/0011.html

I'll take a peek at this feedback and report back, if others have feedback (not on default == automated) please respond

Now the other feedback is to have automated be the default for tests - manual tests need a reason

<Ms2ger> krisk, FWIW, I can rewrite those xhtml test as reftests if you'd like

<plh> the problem is that we have no way to run reftests

<jgraham> Ms2ger: (I have a mild preference for javascript tests since there is somewhat less that can go wrong)

<plh> ie, the tests would still be ran manually

For simple DOM tests (e.g. getElementsbyClassName) they should be automated

<jgraham> plh: The CSSWG are using reftests exclusively for CSS3

<plh> and do they have a way to run them?

<jgraham> Not sure, I will talk to fantasai/Tab

<plh> I doubt they do

<jgraham> But browser vendors can all run reftests now

Nope - they are device/os dependent

<plh> I guess one thing we can do: let the harness run the reftests manually, and if someone has a better way to run those tests, good for them

<jgraham> That is better

<plh> so, maybe we need to modify the harness to allow reftests to be ran manually for now

Let's agree to that

<plh> at least, we'll be able to accept reftests

<Ms2ger> Sounds good

<jgraham> In practice being able to run reftests is necessary to automate other W3C testsuites so I don't think it is any problem for us to have the same requirement

<jgraham> Having manual tests is always a problem though

<jgraham> and is causing problems in practice with CSS 2.1

<plh> yes, but I also don't want to exclude some class of mobile user agents for example in the process of developing reftests

<jgraham> Nor do we

OK then let's state this as our plan...

<jgraham> So reftests should always be possible to run manually too

<plh> sounds great to me

Tests that can be tested via javascript should not be manual

<plh> so Kris, how hard would it be for you to allow reftests in the harness?

<jgraham> i.e. they should always have human-readable instructions

Tests that need some non-javascript verification need to have manual instructions in the test

<plh> for reftests, it's a simple comparison

That should not be a problem

<plh> so you need to be able to display two files

Let's move on to the next agenda item

<jgraham> You want to display them in a way that allows you to flip between them with the tests in the same place in the viewport

<jgraham> Like in two tabs

<jgraham> Makes spotting small differences easier

<Ms2ger> What jgraham said

<plh> and the default instruction should be "For this test to pass, the two following pages must be exactly identically."

sounds good

glad to see we are making progress

<plh> I guess, we need a file naming convention or something

a simple .ref. in the file name - e.g. test.html and test.ref.html

<plh> yep

<Ms2ger> Mozilla uses -ref, btw

<plh> we're using names like a-href at the moment

<plh> using -ref might clash with that

they only do internally - not for tests on the w3 site

Agenda Item #2 #2 Approve 25 more of Philip Taylors Canvas Tests

I looked at tests from http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/size.attributes.setAttribute.trailingjunk.html to http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/toDataURL.arguments.3.html

The look fine to me - any objections?

<plh> no objection from me

gsnedders - I assume you are OK given the past IRC chats

<plh> let's assume so

OK

Agenda item #3 Conditionally approve Opera and Microsofts getElementsByClassName tests - additional work is test harness integration.

I'd like to approve these and move them into the harness so they can be good examples of automated tests

<plh> sounds good to me as well. do we have overlap between the two series of tests?

We have discussed this in the past, I just want to formalize this work

I don't think so - their is only like ~40 total tests

<plh> I'm fine with approving both series of tests

Given the ways that this API can be used, it's possible to create alot more tests

Though the value of additional tests goes down pretty fast...

Which is why the API works well today across borwsers (except in cases like namespaces)

OK then let's conditionally approve these tests

Any other items people want to discuss? Or shall we adjourn?

<Ms2ger> krisk, I'd like to submit some of my own tests

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/top/to/
No ScribeNick specified.  Guessing ScribeNick: krisk
Found Scribe: krisk (note most folks are on IRC)

WARNING: No "Topic:" lines found.

Default Present: krisk, Plh
Present: krisk Plh

WARNING: Fewer than 3 people found for Present list!


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 24 Aug 2010
Guessing minutes URL: http://www.w3.org/2010/08/24-htmlt-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report