See also: IRC log
<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[End of scribe.perl diagnostic output]