15:03:47 <RRSAgent> RRSAgent has joined #htmlt
15:03:47 <RRSAgent> logging to http://www.w3.org/2011/06/14-htmlt-irc
15:04:55 <krisk> Conf call is up if you want to dial in...
15:06:36 <plh> zakim, list conferences
15:06:41 <Zakim> I see HTML_WG(HTMLT)11:00AM, UW_WebTVIG(Home Net)10:00AM, RWC_WebEven()11:00AM, Team_(dnt)14:57Z, Team_(pf)14:00Z, Team_(wf)13:27Z, Team_(site)13:05Z active
15:06:46 <plh> zakim, this is htmlt
15:06:46 <Zakim> also scheduled at this time are SW_(SPARQL)10:00AM, DIG_weekly()11:00AM, WAI_UAWG(CHAIRS)10:30AM, SW_RIF()11:00AM, T&S_XMLSEC()10:00AM, XML_ET-TF()11:00AM, VB_VBWG()10:00AM,
15:06:51 <Zakim> ... WAI_PFWG(HTML_TF)11:00AM, I18N_ITS IG()11:00AM, SW_HCLS(COI)11:00AM
15:06:54 <Zakim> ok, plh; that matches HTML_WG(HTMLT)11:00AM
15:07:19 <Zakim> +Plh
15:07:28 <krisk> zakim, Microsoft is krisk
15:07:40 <Zakim> +krisk; got it
15:08:10 <krisk> Agenda is a bit light ->  http://lists.w3.org/Archives/Public/public-html-testsuite/2011Jun/0014.html
15:08:43 <krisk> Though I just sent out an email to the list about the test review schedule with some dates
15:08:59 <krisk> http://lists.w3.org/Archives/Public/public-html-testsuite/2011Jun/0016.html
15:11:08 <krisk> Lets get start the meeting...
15:11:20 <krisk> Agenda Item #1 Bugs on approved tests
15:11:30 <krisk> We have two new bugs - 
15:11:32 <krisk> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12896
15:14:54 <krisk> It's hard to really make a call since this test doesn't reference back to a section or statement in the HTML5 specification
15:15:03 <plh> I'm surprised about that one but would need to dig into it to udnerstand it fully
15:15:51 <jgraham> It would be a requirement in the SVG specification
15:16:12 <krisk> doesn't seem like a normative part of the HTML5 spec
15:16:51 <plh> SVG has a class attribute: http://www.w3.org/TR/SVG/styling.html#ClassAttribute
15:17:26 <Ms2ger> But SVG doesn't have an 'x' element
15:17:37 <plh> yes, I'm catching up slowly :)
15:18:02 <jgraham> Ms2ger: Why would that matter?
15:18:33 <Ms2ger> Because it doesn't require the class attribute to work on unknown elements, unlike HTML
15:19:17 <jgraham> Does it require them to not work on unknown elements?
15:19:19 <krisk> basically in the svg namespace the unknown elements should not be in the collection
15:19:37 <plh> seems a bug in the svg spec as well to me
15:20:20 <krisk> does any one believe this is a normative part of the html5 spec?
15:21:03 <plh> HTML class attribute: http://www.w3.org/TR/html5/elements.html#classes
15:21:13 <jgraham> I believe it is something that someone at W3C should be testing
15:21:33 <jgraham> And that punting on such things is harmful to interoperability
15:22:00 <Ms2ger> I believe it's something someone at the W3C should be *speccing*, before we test it
15:22:50 <plh> I'm willing to report a bug against the svg spec
15:23:13 <plh> I agree that html5 is clear for its class attribute on any HTML element
15:23:33 <plh> and svg should consider doing the same probably
15:23:37 <jgraham> SVG just says "This attribute assigns a class name or set of class names to an element"
15:23:52 <plh> but it has a list of those elements
15:23:53 <jgraham> It doesn't say "but only if the element is defined in this specification"
15:23:58 <plh> http://www.w3.org/TR/SVG/attindex.html
15:24:20 <jgraham> "This appendix is informative, not normative."
15:24:27 <plh> yes, just saw that
15:25:05 <plh> I'm willing to ask the question to the svg wg
15:25:11 <krisk> thanks
15:25:25 <jgraham> I am happy to leave the bug open but it is not clear to me that it is a valid issue
15:26:02 <jgraham> (I think requiring the implementation to skip unknown elements in DOM methods would be badness)
15:26:13 <krisk> at a bare minimum the test still at least mention what it is testing and what section of the html5 spec it is attempting to test
15:26:27 <Ms2ger> The problem is that the SVG spec doesn't require either way
15:26:43 <jgraham> I agree that the SVG spec could be clearer
15:26:43 <Ms2ger> And we shouldn't be testing things that aren't clearly specified
15:27:05 <jgraham> That excludes us testing the interaction with SVG, ever, really 
15:27:14 <jgraham> and probably lots of DOM Core too
15:27:43 <Ms2ger> Oh? Anything wrong with DOM Core? :)
15:27:52 <jgraham> Well Web DOM Core is fine
15:28:01 <jgraham> it is also not the official spec :)
15:28:16 <jgraham> (it is just the useful one)
15:28:24 <Ms2ger> Are you arguing that we should be testing HTML4, then?
15:28:49 <Ms2ger> HTML is no more official than DOM Core
15:28:58 <jgraham> No, I am saying that Web DOM Core doesn't have any status within W3C afaik
15:29:04 <plh> we have http://www.w3.org/TR/html5/dom.html#dom-document-getelementsbyclassname
15:29:11 <Ms2ger> w3.org/TR/domcore
15:29:26 <plh> so getElementsByClassName is defined in HTML5 it seems
15:29:34 <krisk> correct
15:29:34 <jgraham> Ms2ger: Oh, then I am behind :)
15:29:48 <krisk> next bug...
15:29:49 <Ms2ger> :)
15:29:51 <jgraham> Anyway, I still don't think the test is wrong
15:29:51 <krisk> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12787
15:30:00 <Ms2ger> I still do :)
15:30:10 <plh> I'll ask the svg wg :)
15:30:16 <Ms2ger> plh++
15:30:42 <jgraham> If the test is wrong SVG needs to change :)
15:31:26 <krisk> This is a class of bugs dealing with exception handling
15:31:51 <jgraham> Yeah, WebIDL is not really stable. I guess we will get more issues like this
15:32:18 <Ms2ger> I'd suggest asking Philip to update his tests, and if he doesn't get to it, I can fix too
15:32:31 <krisk> WebIDL should create a test for each part of the web IDL spec that uses various specifications to test interop
15:33:05 <krisk> I think the best outcome is to make sure that an exception is thrown
15:33:25 <Ms2ger> The best outcome is to test the right exception is thrown
15:34:02 <plh> canvas2d says "If the image is null, the implementation must raise a TYPE_MISMATCH_ERR exception."
15:34:12 <plh> so, the test is correct according to the spec
15:34:23 <plh> now, the spec itself may have a bug
15:34:56 <krisk> Once the HTML5 spec changes then it's a legit bug
15:34:56 <Ms2ger> Are you looking at TR/?
15:35:06 <Ms2ger> The spec has changed yesterday or so
15:35:13 <plh> ah...
15:35:44 <plh> http://dev.w3.org/html5/2dcontext/Overview.html#dom-context-2d-createpattern
15:35:50 <plh> also says the same thing
15:36:59 <plh> it seems to fix the test or close the bug
15:37:03 <plh> s//premature/
15:37:20 <Ms2ger> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-createpattern
15:37:37 <Ms2ger> Not sure why the W3C version isn't up to date
15:37:52 <Ms2ger> In any case, WebIDL takes precedence here
15:38:18 <plh> does HTML5 allow WebIDL to take precedence actually?
15:38:29 <plh> (I'm just curious here)
15:38:56 <Ms2ger> It depends normatively on WebIDL
15:39:38 <Ms2ger> The prose in the spec is only applied after WebIDL has done it work
15:39:59 <krisk> seems a bit early to make this change
15:40:11 <krisk> a number of browsers raise this exception today (TYPE_MISMATCH_ERR)
15:40:22 <krisk> IE9, Chrome and Safari...
15:40:26 <Ms2ger> Fx too
15:40:39 <Ms2ger> Because that's what the spec required until recently
15:41:55 <plh> I would wait until the change is propagated into the w3c dev version and see if anyone raises an issue before jumping to change the test. I suggest not to close the bug at this point and look at it again later
15:42:12 <krisk> sounds good...
15:42:57 <plh> (in any case, we would need philip to change his copy of the test first I think)
15:43:01 <Ms2ger> Regardless of whether the change is propagated though, the test is still wrong
15:43:50 <krisk> next Agenda item...
15:44:19 <krisk> A few new tests - have been submitted to Hg if you have not noticed
15:44:20 <krisk> http://dvcs.w3.org/hg/html
15:44:33 <krisk> Feel free to take a peek and give feedback (history push state)
15:44:47 <krisk> time element
15:45:16 <krisk> james if you have any more information about these tests?
15:46:38 <plh> should assert_true( makeTime(false,'03:04').valueAsDate != null ); use assert_not_equals instead?
15:47:06 <Ms2ger> Probably
15:47:47 <plh> James, for the time element tests, you probably want to apply the same feedback you've got for classList
15:48:33 <krisk> thanks for the submission
15:48:36 <krisk> lets adjourn
15:49:50 <jgraham> I will pass on the feedback to the test author
15:50:10 <jgraham> (the tests were written before assert_not_equals)
15:51:10 <Zakim> -Plh
15:51:17 <krisk> Note we don't have a meeting schedule on the june 28th - though we could meet next tuesday if people would like to meet
15:51:46 <krisk> RRSAgent, make logs public
15:51:55 <krisk> rrsagent, generate minutes
15:51:55 <RRSAgent> I have made the request to generate http://www.w3.org/2011/06/14-htmlt-minutes.html krisk
15:52:58 <Zakim> -krisk
15:52:59 <Zakim> HTML_WG(HTMLT)11:00AM has ended
15:52:59 <Zakim> Attendees were Plh, krisk
17:28:16 <Zakim> Zakim has left #htmlt
18:08:23 <plh> plh has left #htmlt
18:17:38 <plh> plh has joined #htmlt
18:17:44 <plh> http://w3c-test.org/html/tests/approved/getElementsByClassName/011.xml
18:17:52 <plh> is returned as application/xml
18:18:01 <plh> is that the intent?
18:18:12 <Ms2ger> It's .xml, so I suppose yes
18:18:23 <Ms2ger> Does it cause trouble?
18:18:44 <plh> well, I'm wondering why Anne wrote that one as .xml
18:19:03 <plh> and not .xhtml for example
18:19:30 <Ms2ger> Still can't read his mind
18:19:38 <Ms2ger> Not that it wouldn't be useful at times... ;)