| 00:38 | <zcorpan_> | http-equiv=page-enter is a hack to make ie not flash when navigating between pages |
| 00:43 | <Dashiva> | Good times |
| 01:12 | <zcorpan_> | http://eric.van-der-vlist.com/blog/2008/01/31/html-5-turns-documents-into-applications/ |
| 01:12 | zcorpan_ | is confused |
| 01:16 | <marcosc_> | "While many people agree that web applications should be designed as documents, HTML 5 appears to propose to move from documents to applications. This seems to me to be a major step… backward!" :) |
| 01:16 | <Hixie> | gotta love the members of the xml crowd who are now desperately trying to back track away from xml requiring fatal handling of errors |
| 01:17 | <Hixie> | (the spec is pretty damn clear about it, it's not easy to argue out of it) |
| 01:18 | <marcosc_> | "no, by fatal we meant kill a kitten, not stop processing the document" :P |
| 01:19 | <Hixie> | so i don't really understand what that article is saying, other than apologising for xml, except maybe that html5 should not define interop as much as it does |
| 01:19 | <Hixie> | in which case my response to that feedback would have to be "Thanks but no thanks". |
| 01:19 | <Ketsuban> | But Hixie, I like having my weblog break every time some jackass posts a comment and forgets to close his <p> tag. :D |
| 01:22 | <Philip`> | marcosc_: That's not quite sufficient error handling - you'd have to add an OUT_OF_KITTENS_ERR exception to cope with all contingencies |
| 01:22 | <marcosc_> | hehe |
| 01:23 | <Philip`> | Ketsuban: You don't want weblog commenters to add <script>s to your page, so you've got to pass comments through an HTML parser anyway, and then you can whitelist and reserialise with correctly closed tags |
| 01:24 | <Ketsuban> | True. |
| 01:24 | <Ketsuban> | The headache only comes when your comment parser starts spitting out invalid code. =P |
| 01:25 | <Philip`> | Nobody cares about invalid code as long as it's well-formed |
| 01:25 | <Philip`> | and well-formedness is less impossible to get right |
| 01:25 | <Philip`> | (though evidence suggests nobody gets it right anyway) |
| 01:26 | <Philip`> | (but they just need better tools that output proper XML for them, and then it'll all be fine) |
| 01:35 | <marcosc_> | "The HTML Working Group doesn’t expect that HTML 5 becomes a recommendation before Q3 20010 and before that date everything can happen." We have 18,000 years to build the spec! |
| 01:40 | <Philip`> | If two interoperable implementations of a spec have been released, but they have been lost for thousands of years and are known only in legends, does that still let you go to REC? |
| 01:40 | <Hixie> | no, you need to be able to demonstrate interoperability |
| 01:41 | <Philip`> | You could have a copy of the test report that was printed out by an earlier civilisation |
| 01:41 | <Hixie> | no, _you_ need to be able to demonstrate interoperability |
| 01:41 | <Hixie> | (as in the working group) |
| 01:41 | <Hixie> | a test report is not such a demonstration |
| 02:20 | <Dashiva> | So we need to contiuously demonstrate interoperability to maintain REC status? Like, daily? |
| 02:41 | <Hixie> | Dashiva: nah, once you're in REC you're done |
| 02:42 | <Dashiva> | What about if you publish an update, like HTML 4.01? |
| 02:42 | <Hixie> | depends if it changes something normative or not |
| 02:44 | <Dashiva> | But would you need to demonstrate interop for the entire spec, or just the delta? |
| 02:46 | <Hixie> | the spec |
| 02:53 | Philip` | wonders how many successful SIGCOMM submissions have been missing entire sections and pages on the day before the deadline |
| 03:40 | <Hixie> | blimey, firefox is way too eager to put <script> elements in the <head> |
| 03:41 | <jruderman> | https://bugzilla.mozilla.org/show_bug.cgi?id=402537 ? |
| 03:42 | <Hixie> | yeah. it's in acid3 even. |
| 03:43 | <jruderman> | hah, nice |
| 03:43 | <SadEagle> | ah. That might explain some difficulties I had w/my testcase in ff |
| 03:43 | <Hixie> | basically they will put <script>s in the <head> unless they've seen some non-whitespace text |
| 03:43 | <Hixie> | and they'll execute the script before the other elements are added to the tree |
| 03:44 | <Hixie> | it's crazy stuff |
| 03:44 | <Hixie> | gecko so needs to have its parser ripped out and replaced by an html5 parser |
| 03:45 | <SadEagle> | I think I got in habbit of having all my testcases run scripts from onload and not inline since getElementById("foo") would mysteriously not work. |
| 03:46 | <SadEagle> | Of course, I should shut up, since khtml's parser doesn't do so hot on acid3 |
| 03:46 | <Hixie> | hehe |
| 03:47 | <Hixie> | is it very different from webkit's? |
| 03:47 | <SadEagle> | not sure, same codebase, but details matter here. It does some pretty egreggious things. In particular, it finds the iframes tasty. |
| 03:47 | <Hixie> | k |
| 03:47 | <Hixie> | i know webkit had to change stuff in the parser as part of their acid3 fixes |
| 03:48 | <SadEagle> | With that fixed, it somehow eats the 'fail' child of the iframe, which is absolutely mysterious, seeing how the internal DTD allows it (unlike iframe-under-map) |
| 03:48 | <SadEagle> | hmm, may be I should debug that now. |
| 03:48 | <Hixie> | yeah, webkit does that too |
| 03:49 | <Hixie> | i recommend writing an html5 parser implementation from scratch, and using it in webkit and khtml :-) |
| 03:49 | <SadEagle> | I suspect both would behave pretty similarly with the DTD relaxed sufficiently. |
| 03:50 | <SadEagle> | And, to be honest, the parser is -mostly- fine. The tokenizer, OTOH, is a crime against humanity |
| 03:50 | <Hixie> | well the tokeniser part of html5 is even easier to implement than the parser |
| 03:51 | <Hixie> | and is relatively separate |
| 03:51 | <SadEagle> | do you expect it to have a chance at the stuff in the wild? |
| 03:52 | <Hixie> | yes |
| 03:52 | <Hixie> | it's what i use to run over google's index, and it's what html5lib implements, and what henri uses in his validator |
| 03:52 | <Hixie> | amongst other things |
| 03:53 | <Hixie> | there are open issues (see http://whatwg.org/issues and search for "tokeniser") |
| 03:53 | <marcosc_> | the acid3 reference rendering does not look as it should on my ipod? hixie, is that correct? |
| 03:53 | <Hixie> | but they are relatively minor |
| 03:53 | <Hixie> | marcosc_: checking... |
| 03:53 | <SadEagle> | I guess the most important thing is quick recovery. though messing up a </script> boundary could be trouble.. |
| 03:54 | <Philip`> | http://canvex.lazyilluminati.com/misc/parser/tokeniser.html lets you play with a non-document.write-supporting version of the HTML5 tokeniser |
| 03:54 | <Hixie> | wow, my ipod only gets 27/100. not the worst rendering i've seen, though. |
| 03:54 | <Hixie> | oh no |
| 03:54 | <Hixie> | 40/100 |
| 03:54 | <Hixie> | it's just slow around the two perf tests |
| 03:54 | <jruderman> | ipod touch with webkit? |
| 03:55 | <Hixie> | jruderman: yes |
| 03:55 | <marcosc_> | yeah, not too bad :) |
| 03:55 | <Hixie> | marcosc_: looks fine to me, except the text goes out of the box |
| 03:55 | <SadEagle> | Philip`: may be I should be a good boy and pull up some of those nasty testcases :-) |
| 03:55 | <jruderman> | maybe you should make it indicate when it's doing the perf test |
| 03:55 | <jruderman> | (or pull the perf test from acid3) |
| 03:55 | <marcosc_> | hixie, I was wondering if the text going out was ok. So that's ok then. |
| 03:55 | <Hixie> | marcosc_: but that's caused by the wacky font zooming "feature" |
| 03:55 | <Hixie> | marcosc_: well, it's not "ok" per se |
| 03:56 | <Hixie> | marcosc_: but it's intentional on their part |
| 03:56 | <Hixie> | it looks like it's basically a minimum font size |
| 03:56 | <marcosc_> | Hixie, thanks for the clarification. |
| 03:57 | <Hixie> | (they couldn't claim to pass like this, but they don't claim to pass acid2, either) |
| 03:58 | <jruderman> | do you consider having a minimum font size by default to be a spec violation? |
| 04:02 | <Hixie> | http://damowmow.com/playground/demos/font-size/a.html suggests it's not actually as simple as it being a minimum font size thing |
| 04:03 | <Hixie> | jruderman: not really, but there are certain cases (like the way gecko lets the min font size pref override even the font size of elements with no text) that i think are wrong |
| 04:03 | <Hixie> | not sure how strongly the spec backs me up |
| 04:13 | <SadEagle> | Hixie: heh, I am pretty sure the text-under-iframe-eater is in the tokenizer. uh-oh. |
| 04:14 | <Hixie> | marcosc_: this is really weird behaviour. i don't understand why the text takes so much room on the ipod |
| 04:15 | <marcosc_> | Hixie, that's what I thought... which prompted me to ask ;) I thought maybe there was something wrong in the css or something. |
| 04:15 | <Hixie> | that text is definitely bigger than 16px |
| 04:15 | <Hixie> | but i don't understand why |
| 04:17 | <marcosc_> | unfortunately, I can't do any testing atm because I don't have wireless here |
| 04:21 | <SadEagle> | (grmbl. it explicitly discards stuff within an iframe... Wonder why, it should hide content just fine) |
| 04:28 | <SadEagle> | yikes. going to the html5 spec with tokenizer on full debug is not fun |
| 04:31 | <Hixie> | hah |
| 04:31 | <SadEagle> | BTW, FF2.0 seems to parse everything inside <iframe> literaly. Well, at least the elements, anyway |
| 04:32 | <Hixie> | anyone here have a graphics package up who could throw me a data: URL to a 1x1 PNG of #000080 ? |
| 04:32 | <Hixie> | SadEagle: yeah, see the spec for what should happen |
| 04:32 | <Hixie> | html5 spec, that is |
| 04:33 | <SadEagle> | I see. That actually specs that. |
| 04:33 | <SadEagle> | I have a webbrowser, one sec. |
| 04:37 | <Hixie> | nevermind |
| 04:37 | <Hixie> | got one |
| 04:37 | <Hixie> | yay for convert(1) |
| 04:38 | <Hixie> | convert -size 1x1 xc:transparent -fill '#008' -draw 'rectangle 0,0 1,1' blue.png |
| 04:39 | <SadEagle> | I did this: http://pastebin.ca/887193 -- before trying to get too cute |
| 04:39 | <Hixie> | hah |
| 04:39 | <Hixie> | yeah, i guess that would be another way! |
| 04:39 | <Hixie> | shoulda thought of that |
| 04:41 | <SadEagle> | well, test 4 fails on expectation 43 now. progress :-) |
| 04:41 | <Hixie> | looks like the iphone's "minimum font size" isn't a fixed size |
| 04:42 | <Hixie> | it's just a dampening, as the font size gets smaller, it bumps it up a bit |
| 04:44 | <Hixie> | and it only does it if the text is multiline |
| 04:46 | <Hixie> | http://www.hixie.ch/tests/adhoc/css/fonts/size/007.html is a minimised test case for the iPod acid3 reference image bug |
| 04:48 | <SadEagle> | uhm, hixie, in test 4, is the 2nd half supposed ot be all backwards-going? |
| 04:48 | <Hixie> | did i screw up? |
| 04:48 | <SadEagle> | 'cause you got a couple of nextNode calls in there |
| 04:48 | <Hixie> | fixed |
| 04:48 | <SadEagle> | thanks |
| 04:49 | <SadEagle> | yey, 63! |
| 04:54 | <SadEagle> | Hixie: where is the stuff for test 70 loaded? |
| 04:54 | <Hixie> | around test 65 |
| 04:55 | <SadEagle> | I see. a whee bit of cascade there. |
| 04:55 | <Hixie> | yeah. i tried to do it earlier to give browsers a chance to get it done in the 50ms i give them |
| 04:55 | <Hixie> | instead of requiring it to happen in 10ms |
| 04:56 | <Hixie> | (the resources for the test are all given cache ages of about a year, so everything should be cached if you're running the test the second time to get timings) |
| 04:56 | <Hixie> | (the final part of the test is getting the speed up, hence the timer at the end of the debug log. :-D ) |
| 04:56 | <Hixie> | (acid3 has to be the most fucked up benchmark ever, but there ya go) |
| 04:57 | <SadEagle> | hmm, looks like fraime-onload being bad. |
| 04:58 | <SadEagle> | I see you've never seen the 24fun "JavaScript" benchmark :-) |
| 04:59 | <Hixie> | it's worse? because that would surprise me :-) |
| 04:59 | <Hixie> | http://www.city-data.com/city/Hardy-Iowa.html uses <canvas> for its intended purpose. sweet. |
| 05:00 | <SadEagle> | Hixie: it's first benchmark tries to measure how fast an empty'ish for loop counter runs. It 'helpfully' displays its progress on the statusbar once every 100 iterations or so. You can guess what it's -really- measuring, right? :-) |
| 05:00 | <Hixie> | (nice, firefox's "view image" feature on a canvas shows you the data: URI) |
| 05:00 | <Hixie> | SadEagle: hahaha |
| 05:01 | <Hixie> | nice |
| 05:08 | <SadEagle> | ugh, cnn.com is using flash for content stuff. |
| 05:11 | <SadEagle> | anyway, good night |
| 09:17 | <hsivonen> | Surely Eric van der Vlist knows that fatal errors in XML were meant as "halt and catch fire" |
| 09:53 | <hsivonen> | http://www.jezuk.co.uk/arabica/log?id=3591 looks like we need to beat the drum about the existence of the HTML5 parsing algorithm more |
| 10:04 | <hsivonen> | the Frech Wikipedia says: "Il semblerai qu'en 2008 le XHTML 2.0 soit abandonné au profit du HTML 5" |
| 10:04 | <hsivonen> | French even |
| 10:06 | <Camaban> | well, it does seem that way.... |
| 10:07 | <hsivonen> | Camaban: yes. my point is that the French wikitruthiness is more pro-HTML5 than the English wikitruthiness |
| 10:08 | <Camaban> | ah |
| 10:09 | <Philip`> | Are there any people who were working on XHTML2 and then abandoned it once HTML5 started? Or had they all decided to stay away years ago, when there was no sign of the W3C ever doing HTML5? |
| 12:37 | <hsivonen> | any suggestions for a UI name for the datatype that the content attribute takes when meta is in the content-type state? |
| 12:45 | <hsivonen> | "legacy character encoding declaration"? |
| 12:46 | <hsivonen> | Hixie: surely the meta charset should be ASCII-case-insensitive |
| 13:07 | <hsivonen> | why on earth are ' ` { and } allowed in MIME charset names? |
| 13:35 | <thomas______> | hey folk, anybody here who has some experience using crossfade effects using a canvas |
| 13:36 | <thomas______> | because i currently wrote a mootools effect for that but its not the fastest one |
| 13:43 | <Dashiva> | http://www.ietf.org/rfc/rfc2397 |
| 13:43 | <Dashiva> | Is it just me, or are they sending plain text as text/html? |
| 13:43 | <Philip`> | Dashiva: It's not just you |
| 13:44 | <hsivonen> | how the mighty have fallen |
| 13:44 | <Philip`> | For compatibility with web content, browsers will have to start sniffing plain text that is served as text/html |
| 13:44 | <Dashiva> | It's kinda bad when even the ietf gets it wrong :) |
| 13:47 | <Philip`> | http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04511.html - sounds like this is an expected time for problems |
| 14:08 | <Dashiva> | annevk: around? |
| 14:23 | <hsivonen> | what's the right way to do case-insensitive attribute value matching in XPath? do I need to use translate? |
| 15:01 | <Lachy> | Hixie, is acid3 finished now? I noticed that /003/NOT_READY_PLEASE_DO_NOT_USE.html is redirecting to /003/ now |
| 15:01 | <hsivonen> | hmm. I should probably make v.nu check the contents of well-known but obsolete container elements |
| 15:40 | <gsnedders> | Lachy: it's under review, per what he said yesterday |
| 15:43 | <Lachy> | gsnedders, ok. I wasn't paying attention yesterday |
| 16:00 | hsivonen | notes that neither MIT nor W3C are acronyms in the dictionary sense of the word even if marked up as <acronym> in the spec boilerplate |
| 16:02 | gsnedders | doesn't even ask the eternal question of, "what is an acronym anyway?" |
| 16:03 | jgraham_ | choses not to read any mail mentioning <acronym> vs <abbr> (I think this is the only topic I skip entirely) |
| 16:09 | <didymos> | hsivonen, MIT isn't? How come? |
| 16:11 | <hsivonen> | didymos: it is pronounced em eye tee -- not mit |
| 16:11 | <didymos> | hsivonen, my Webster's lists radar and FBI as acronyms -- MIT seems to fall under the latter |
| 16:11 | <gsnedders> | hsivonen: oh, you've forgetting the issue that dictionaries don't agree on what an acronym is. |
| 16:12 | <gsnedders> | hsivonen: in some dictionaries MIT is, in others it isn't |
| 16:12 | <hsivonen> | didymos: Webster's is then closer to the actual usage than some other dictionaries |
| 16:12 | gsnedders | has OED compact. edition downstairs (i.e., the full OED in 3pt type) |
| 16:12 | <didymos> | hsivonen, But I see your point on W3C not being an acronym |
| 16:13 | <gsnedders> | apparently the second edition OED changed the type to being even smaller so it was just one volume. |
| 16:13 | <webben> | no |
| 16:13 | <webben> | still 2 volume |
| 16:14 | <webben> | (there might have been special editions of 2nd edn. in one vol though) |
| 16:14 | <hsivonen> | does the New Oxford American Dictionary have anything to do with the real OED? |
| 16:15 | <webben> | http://en.wikipedia.org/wiki/New_Oxford_American_Dictionary |
| 16:15 | <webben> | seems like a helpful guide to it |
| 16:15 | <webben> | (yes, something to do with it, seems the answer) |
| 16:15 | <gsnedders> | it was written from scratch, though |
| 16:15 | webben | wonders whether they reflect the Websters vs Oxford difference in acronym. |
| 16:16 | <hsivonen> | webben: thanks |
| 16:16 | <webben> | it's worth noting that OED does include American usages and spellings |
| 16:16 | <webben> | I'd imagine these things are based in sharing corpus to some degree |
| 16:17 | <gsnedders> | yeah, even if the text it different |
| 19:04 | Hixie | commented on http://eric.van-der-vlist.com/blog/2008/01/31/html-5-turns-documents-into-applications/ after al |
| 19:04 | <Hixie> | l |
| 19:39 | <annevk> | Hixie, http-equiv="Content-Language" does affect :lang() in some implementations |
| 19:39 | <annevk> | Hixie, we could of course revisit that as only testcases rely on it |
| 19:40 | <annevk> | maybe that would be better as its slightly less code and less weird cases to test and implement |
| 19:46 | <annevk> | Also, the new security policy is not good enough |
| 19:46 | <annevk> | Roundtripping of data: URIs is made impossible :( |
| 19:50 | <krijnh> | "The HTML Working Group doesn�t expect that HTML 5 becomes a recommendation before Q3 20010 and before that date everything can happen." |
| 19:53 | <gsnedders> | Philip`: yeah, I haven't done any revision for the prelims which just finished |
| 19:54 | <gsnedders> | krijnh: yeah, I noticed that. Issues of storing years as a single digit. |
| 19:58 | <jgraham_> | For what definition of the word "everything" does "everything" have a chance of happening in the next 18002 years? |
| 19:58 | <krijnh> | I think I'll have a beard by then |
| 20:55 | gsnedders | notes RFC4287 (The Atom Syndication Format) despite saying what elements are doesn't require (or even suggest) that the elements must be used and interpreted as meaning what it says they are |
| 21:15 | <Philip`> | Hmm, ten hours of reading and writing LaTeX makes my eyes hurt :-( |
| 21:34 | <Philip`> | Also, LaTeX's interpretation of /[A-Z]\. / as being a middle initial in a name and therefore deserving of less whitespace than a sentence ending was clearly not designed by someone thinking of the modern computing world of acronyms :-( |
| 21:35 | <Philip`> | ...or abbreviations or initialisms or whatever they are today |
| 22:07 | <annevk> | Microsoft bid on Y? wow |
| 22:07 | <Dashiva> | I liked Ballmer's comment |
| 22:07 | <Dashiva> | >> "Today, the market is increasingly dominated by one player who is consolidating its dominance through acquisition," Ballmer wrote in the letter. |
| 23:04 | <webben> | Dashiva: Yes. The solution to monopolisation is a bigger monopoly. ;) |
| 23:07 | <webben> | krijnh: ironically a later date than can be expressed with TIME DATETIME= |
| 23:34 | <Hixie> | i wonder how to require that UAs support infinity on canvas. |
| 23:35 | <Philip`> | Any Turing-complete computer should be able to handle infinitely large canvases just fine |
| 23:36 | <annevk> | by allowing them to clamp? |
| 23:37 | <Philip`> | annevk: What would ctx.rotate(Infinity) be clamped to? |
| 23:39 | <Hixie> | what should happen with that? |
| 23:40 | <annevk> | 2π |
| 23:40 | <Hixie> | so no effect then? |
| 23:40 | <Hixie> | i guess i could say that |
| 23:40 | <annevk> | actually, i'll leave this up to whatever Philip` says |
| 23:41 | <Philip`> | I don't have any good ideas |
| 23:41 | <Hixie> | well i've made rotate(Infinity) be ignored, and all others be honoured |
| 23:41 | <Hixie> | not sure what to do with NaN |
| 23:41 | <annevk> | makes sense to ignore that too, no? |
| 23:42 | <annevk> | if we don't want to throw anymore |
| 23:42 | <Philip`> | rotate("45 anticlockwise") |
| 23:42 | <Philip`> | Maybe it'd help debugging if that threw an exception since it's NaN |
| 23:42 | <Hixie> | annevk: there's a mathematically correct solution for infinite coordinates and transformations (other than infinite rotations) |
| 23:43 | <Philip`> | but that seems a pretty unlikely situation |
| 23:43 | <Hixie> | Philip`: i'm more thinking about maths that ends up doing 0/0 or some such |
| 23:44 | <jgraham_> | NaNslipping into calculations silently has never helped me, so I'f favour an exception, but I don't think that's always right |
| 23:44 | <Philip`> | Only for some infinite coordinates - e.g. moveTo(-Infinity,-Infinity);lineTo(Infinity,Infinity);lineTo(-Infinity,Infinity);fill() has no mathematically correct solution |
| 23:45 | <Hixie> | wouldn't it be a single diagonal line? |
| 23:45 | <Hixie> | tl to br |
| 23:45 | <Hixie> | ? |
| 23:46 | <Philip`> | What angle would the line be? |
| 23:47 | <Philip`> | and why wouldn't it be a different angle? |
| 23:48 | <Hixie> | pi/4, because otherwise the infinities would be different infinities? :-) |
| 23:48 | <Hixie> | (and crossin 0,0) |
| 23:49 | <Ketsuban> | Infinity could be defined as the screen edges. =P |
| 23:49 | <Hixie> | i could also just say that all infinities and NaNs cause rendering to stop for whatever the inf or NaN value touches |
| 23:49 | <Hixie> | basically, tell me what to do and i'll do it :-) |
| 23:50 | <Ketsuban> | So if the canvas covers the whole screen a line from (inf,inf) to (-inf,-inf) would be the top left corner to the bottom right corner. If the canvas is smaller then it captures that line bounded by the edges of the canvas. |
| 23:50 | <Philip`> | If you rotated that pi/4 line by a bit, it'd be a different line but it'd still be going from -inf to +inf on each axis, and unfortunately the IEEE people weren't considerate enough to allow lossless encoding of values like 2*Infinity :-( |
| 23:50 | <Hixie> | Philip`: sure, i was mostly being flippant |
| 23:51 | <Philip`> | Causing rendering to stop sounds about as fatal as throwing an exception, but without providing a nice message in the error log to help people debug it |
| 23:52 | <Hixie> | Philip`: ok, so what should i require? |
| 23:56 | <aseem> | Hi. I am trying to write some tests for some modification I made to the sanitizer to allow stripping of risky elements |
| 23:56 | <Philip`> | I suppose I can't see anything particularly wrong with just ignoring any function calls (or assignments etc) with +/- Infinity or NaN, and I guess it'd be reasonably easy to implement since it's just a test at the top of each function |
| 23:56 | <aseem> | I was looking at the tests1.dat file in the testdata folder and am unsure as to what the rexml field represents |
| 23:58 | <annevk> | sounds like something for ruby |
| 23:59 | <jgraham_> | aseem: which file exactly? |
| 23:59 | <annevk> | http://html5lib.googlecode.com/svn/trunk/testdata/sanitizer/tests1.dat |
| 23:59 | <annevk> | i suspect it's about Ruby's XML parser |