| 00:30 | <Hixie> | hsivonen: you sent four mails right? |
| 00:30 | <Hixie> | about the parser? |
| 00:38 | <webben> | hsivonen: re http://lists.w3.org/Archives/Public/public-html/2007Jul/0064.html and http://lists.w3.org/Archives/Public/public-html/2007Jul/0067.html, a problem with FIrefox 1.04 (of all things) is not really a problem with AT, is it? I'm also not sure why we're evaluating old methods of embedding Flash rather than the newest techniques: http://alistapart.com/articles/flashembedcagematch/ . (These methods are continuing to evolve.) |
| 00:39 | <webben> | (Firefox 1.04 didn't have effective screen reader support.) |
| 00:48 | <Philip`> | I was beginning to think that browsers weren't that bad at drawing lines, but then I reached arcTo and my hopes were shattered :-( |
| 07:54 | <Hixie> | sweet |
| 07:54 | <Hixie> | it works |
| 07:55 | <Hixie> | the "table model" algorithms for forming a table totally work and generate actual tables that are what the markup was! |
| 07:55 | <Hixie> | i guess i shouldn't be so surprised but that's pretty damn cool. |
| 07:56 | <Hixie> | tomorrow i can do the scope="" and headers="" stuff |
| 07:56 | <Hixie> | now that i have actual tables |
| 08:08 | <annevk> | what language did you wrote your model in? |
| 08:13 | <hsivonen> | Hixie: yes, I sent 4 emails. |
| 08:49 | <annevk> | "were many things which WHATwg want to delete, are mentioned (ACRONYM, non-visual rendering of TABLES amongst them.)" |
| 08:50 | <annevk> | FO 4 |
| 08:50 | <annevk> | these people are crazy |
| 10:06 | <zcorpan_> | what's the reason that i like testing parsing more than testing other things? :) |
| 10:07 | <annevk> | parsing is trivial? :p |
| 10:07 | <zcorpan_> | perhaps :) |
| 10:07 | <zcorpan_> | but not really |
| 10:07 | <annevk> | btw, any chance you'll make some script that converts html5lib testdata to browser usable tests? |
| 10:08 | <annevk> | because making html5lib tests is trivial |
| 10:08 | <zcorpan_> | hmm, i could look into that |
| 10:08 | <annevk> | someone from mozilla already did some work |
| 10:08 | <zcorpan_> | pointer? |
| 10:08 | <annevk> | I'm afraid I don't have a pointer |
| 10:09 | <annevk> | the only thing you need to do is get the result DOM |
| 10:09 | <annevk> | iterate over it |
| 10:09 | <zcorpan_> | load the tests in an iframe |
| 10:09 | <annevk> | yeah |
| 10:09 | <annevk> | and from the restult DOM you make a string and compare that with the #document data |
| 10:09 | <zcorpan_> | ah yep |
| 10:10 | <zcorpan_> | seems pretty straightforward |
| 10:11 | <zcorpan_> | do the existing tests assume that scripting is enabled? or disabled? |
| 10:11 | <annevk> | I think enabled, but scripting support is not there |
| 10:12 | <zcorpan_> | might perhaps be good to split up the tests that assume that scripting is enabled or disabled (or neither) |
| 10:13 | <annevk> | I suppose we could make extensions |
| 10:13 | <annevk> | #data --scripting-disabled |
| 10:13 | <zcorpan_> | perhaps |
| 10:15 | <annevk> | don't know what's best |
| 10:16 | <zcorpan_> | not sure if it's possible to enable/disable scripting on a per test basis |
| 10:17 | <zcorpan_> | my port would probably only work with tests that don't assume that scripting is disabled |
| 10:18 | <annevk> | sure |
| 10:18 | <annevk> | you could have some server-side script that organizes the tests for you or something |
| 10:18 | <annevk> | in that case you can simply make a scripting-enabled and scripting-disabled folder |
| 10:18 | <annevk> | dunno |
| 10:21 | <annevk> | to start it would be nice to have some JS that does DOM -> #document\n... |
| 10:21 | <zcorpan_> | yeah |
| 10:21 | <annevk> | then we can compare browsers to html5lib more easily |
| 10:22 | zcorpan_ | looks at the live dom viewer code |
| 10:23 | <zcorpan_> | hmm, what if the dom isn't a tree |
| 10:24 | <annevk> | Hixie has solved that issue |
| 10:24 | <annevk> | I suppose you just keep a pointer around and check if you haven't encountered the node before |
| 10:24 | <zcorpan_> | yeah, but the html5lib test output format doesn't support non-trees |
| 10:25 | <annevk> | oh |
| 10:25 | <annevk> | elementname - graph |
| 10:25 | <annevk> | just output something that makes it non-conforming |
| 10:38 | <annevk> | (if we have that script it can be integrated with the thing david has) |
| 10:39 | <jgraham> | http://lxr.mozilla.org/seamonkey/source/parser/htmlparser/tests/mochitest/ |
| 10:39 | <annevk> | http://hasather.net/html5/parsetree/ |
| 10:39 | <annevk> | jgraham, cool |
| 10:48 | <hsivonen> | I wonder if sayrer is writing a new HTML parser or changing the old one |
| 10:49 | <hsivonen> | (I wouldn't want to change the old one) |
| 10:49 | <annevk> | dunno, seems like mrbkap is still fixing the old one |
| 10:49 | <annevk> | (from the couple of bug numbers referenced there) |
| 10:50 | <annevk> | they also checked out all the old tests |
| 10:55 | <annevk> | jgraham, btw, how easy is it to extend all treebuilders to support two more variables for DOCTYPE? |
| 11:36 | <zcorpan_> | http://simon.html5.org/temp/dom-tostring.html |
| 11:44 | <zcorpan_> | please tell me if i can improve the function, i think it is doing some unnecessary things (looping too many times or something) |
| 11:44 | <zcorpan_> | or if i got the format wrong |
| 11:50 | <hsivonen> | zcorpan_: well, if you wanted to optimize performance (which isn't really necessary), you could traverse the DOM using an iterative algorithm instead of a recursive one |
| 11:56 | <zcorpan_> | hsivonen: hmm, ok. i think i'll leave it as is for now |
| 12:58 | <zcorpan_> | the selectors api naming issue will never end |
| 13:02 | <annevk> | I wonder when HTML 5 will get issues like that |
| 13:02 | <annevk> | hopefully when everything is already shipped in implementations |
| 13:08 | <zcorpan_> | selectorQuery/selectorQueryAll seem to be good names |
| 13:10 | <annevk> | wfm |
| 13:25 | <Lachy> | yeah, I like those names too. It looks like a reasonable compromise between selectElement and cssQuery, but I have a feeling there's going to be someone that doesn't like it |
| 13:27 | <zcorpan_> | of course someone won't like it |
| 15:12 | <zcorpan> | so why doesn't this work? http://simon.html5.org/temp/html5lib-tests/wrapper.html |
| 15:14 | <annevk> | you're not invoking send()? |
| 15:14 | <annevk> | with my XHR2 that would not be necessary but it seems that it will not going to fly :) |
| 15:17 | <Lachy> | how is XHR2 going to know when to implicitly invoke send()? |
| 15:17 | <annevk> | much like Audio(src) |
| 15:17 | <annevk> | anyway, not going to happen |
| 15:18 | <annevk> | new XMLHttpRequest(method, src) is likely the only shortcut that makes some sense |
| 15:18 | <Philip`> | Sounds like about the same as setTimeout(fn, 0) too (i.e. as soon as possible after the current script has finished) |
| 15:18 | <annevk> | yeah |
| 15:23 | <zcorpan__> | hmm, is tests1.txt parsed as xml or something? |
| 15:25 | <annevk> | shouldn't matter for responseText |
| 15:26 | <zcorpan__> | Error: syntax error |
| 15:26 | <zcorpan__> | Source File: file://loca.....l5lib-tests/tests1.txt |
| 15:26 | <zcorpan__> | Line: 1, Column: 1 |
| 15:26 | <zcorpan__> | Source Code: |
| 15:26 | <zcorpan__> | #data |
| 15:27 | <annevk> | oh, in Firefox? |
| 15:27 | <zcorpan__> | yeah |
| 15:28 | <annevk> | they have some issues there I believe |
| 17:17 | <virtuelv> | hm, wonder which version of Safari the iPhone is based on |
| 17:18 | <virtuelv> | Row 1 and 4+5 of Acid2 fails |
| 17:19 | <Philip`> | virtuelv: It calls itself "Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3" which sounds like a possibly old WebKit |
| 17:21 | <virtuelv> | then this too: http://www.johnmurch.com/2007/07/01/iphone-javascript-and-spec-benchmark/ makes sense |
| 17:22 | <Philip`> | Looks like someone tried running Canvex on an iPhone - I wonder what kind of performance they get... |
| 19:35 | <jgraham> | annevk: The only issue I can think of with adding more doctype stuff to the treebuilders is several tree types don't really support the concept of doctypes |
| 19:36 | <jgraham> | There have been hacked in various ways to support the concept e.g. by having elements with tagnames like "<!doctype>" |
| 19:37 | <jgraham> | But where we hacked we can hack a little more |
| 19:37 | <jgraham> | :) |
| 19:45 | <hsivonen> | jgraham: my plan is not to expose the doctype by default through APIs designed for XML |
| 19:46 | <jgraham> | hsivonen: We need it for running tests. By default it is stripped when a special flag is not set |
| 19:46 | <hsivonen> | annevk: the doctype node stuff is for browsers. it is rather pointless for parsing libraries meant for non-browser use cases |
| 19:47 | <hsivonen> | jgraham: OK. I guess I have to support doctypes in SAX (buffered and streaming) |
| 19:47 | <hsivonen> | but supporting them in the DOM just sucks without a backdoor API |
| 19:48 | <jgraham> | (that is, it is stripped where it not supported by the underlying tree) |
| 19:49 | <hsivonen> | if the use case is making a drop-in library for apps that now use an XML parser, exposing the doctype might be more harm than good |
| 19:50 | <hsivonen> | but yeah, supporting doctype exposure in SAX and XOM is reasonable |
| 23:53 | Hixie | narowly misses flinging his ipod acress his cube |
| 23:53 | <Hixie> | oops |
| 23:57 | <Hixie> | right, done scope="" |
| 23:57 | <Hixie> | now headers="" |