| 07:54 | <krijnh> | It's shitty connection day today, yay |
| 10:43 | <heycam> | Hixie, there seems to be an error in my submitted acid3 test (#69). the last string literal in the function-serialised SVG fragment should have an 'A' at the end (i.e., it should be '\uD800\uDC85A' instead of '\uD800\uDC85'), since the rest of the test assumes that there is an A character after the astral character. |
| 11:42 | <virtuelv> | http://www.katemonkey.co.uk/article/48/x-ua-lemur-compatible |
| 12:00 | <hdh> | all of the Internets, lol |
| 12:49 | <Dashiva> | virtuelv: Does Opera plan to support lemurs in the next version? |
| 12:49 | <Dashiva> | It could boost the user base quite a lot! |
| 13:06 | <hsivonen> | Hixie: the W3C boilerplate for HTML5 uses <acronym> instead of <abbr>... |
| 13:07 | <annevk> | that's what the W3C boilerplate is like |
| 13:08 | <hsivonen> | Hixie: there are also two instances of "</pre><", which wouldn't be OK in HTML5. |
| 13:09 | <hsivonen> | annevk: well, it seems that either the boilerplate needs to change or the spec needs to change. otherwise, the ingredients of a permathread are here. |
| 13:09 | <annevk> | cool |
| 13:09 | <annevk> | validator.nu can now validate the spec |
| 13:09 | <annevk> | pretty fast too |
| 13:10 | <hsivonen> | And I didn't even deploy Saxon, yet. |
| 13:10 | <hsivonen> | weird |
| 13:10 | <annevk> | maybe Hixie should hook it up to his publishing process |
| 13:10 | <annevk> | Saxon? |
| 13:10 | <hsivonen> | annevk: a faster XSLT back end |
| 13:12 | <nickshanks> | hat is it using at the moment? |
| 13:12 | <nickshanks> | +W |
| 13:12 | <hsivonen> | nickshanks: Xalan |
| 13:12 | <nickshanks> | i played around with XSLT engines a while ago, and found many bugs |
| 13:13 | <hsivonen> | nickshanks: what's your assesment of Xalan vs. Saxon? |
| 13:13 | <nickshanks> | Xalan wasn't one of them |
| 13:13 | <hsivonen> | nickshanks: was Saxon 9? |
| 13:15 | <nickshanks> | it was whatever was included with http://www.entropy.ch/software/macosx/#testxslt |
| 13:15 | <hsivonen> | nickshanks: that includes Xalan |
| 13:16 | <nickshanks> | hmm, so it does |
| 13:16 | <nickshanks> | okay |
| 13:16 | <nickshanks> | then it was unmemorable :) |
| 13:16 | <nickshanks> | Saxon was better, but libxslt was the best for my purposes |
| 13:16 | <nickshanks> | e.g. saxon introduced whitespace where it shouldn't have |
| 13:16 | <hsivonen> | I'm just about ready to push Saxon 9 out to Validator.nu |
| 13:17 | <hsivonen> | but now Xalan runs fast enough. when I decided to switch it was insanely slow |
| 13:17 | <nickshanks> | in XHTML, <q>Hello</q> should not become <q>\n\t\tHello\n\n</q> |
| 13:17 | <hsivonen> | really unbearably insanely slow |
| 13:17 | <hsivonen> | now I'm puzzled |
| 13:18 | <nickshanks> | one of them did that, libxslt didn't |
| 13:48 | <annevk> | hsivonen, maybe your webhost pushed out an update? |
| 13:50 | <hsivonen> | annevk: changed load on host running the virtual machine would be an explanation |
| 13:50 | <hsivonen> | annevk: on the VM, I control the software |
| 13:51 | <annevk> | are you still planning on taking out schematron? |
| 13:51 | <hsivonen> | not from the entire service, no |
| 13:51 | <hsivonen> | but from the HTML5 presets, yes |
| 13:52 | <hsivonen> | unfortunately, user-provided Schematron is a DoS attack vector |
| 13:52 | <hsivonen> | but it would be a shame to disable it because of that |
| 13:53 | <hsivonen> | I guess trusting the host for benchmarking is a bad idea |
| 13:53 | <hsivonen> | I'm going to run some more tests on my development machine |
| 13:54 | <hsivonen> | but my dev machine runs a different JIT back end on a different CPU arch... |
| 13:59 | <hsivonen> | hmm. I wonder if the W3C WD and the WHATWG draft from earlier this month have notably different document trees |
| 13:59 | <hsivonen> | I'm able to reproduce the insane slowness with my old copy of the spec |
| 14:02 | <hsivonen> | ok. Xalan is sometimes insanely slow |
| 14:02 | <hsivonen> | but Saxon isn't |
| 14:02 | <hsivonen> | so switching to Saxon was the right call |
| 14:02 | <hsivonen> | I just need to polish things a bit before I deploy |
| 15:12 | hsivonen | likes the new Firefox 3 Mac look |
| 15:13 | <MikeSmith> | hsivonen - might be useful to get feedback to Xalan project |
| 15:14 | <MikeSmith> | let them know it is proving to be not usable for your application |
| 15:14 | <MikeSmith> | maybe they can give you some tips on profiling you could do |
| 15:15 | <MikeSmith> | but I think it would be good for them to hear from you at least |
| 15:15 | <MikeSmith> | though seems like probably there's nothing they can/will do |
| 15:15 | hdh | prefers the huge Back button design |
| 15:19 | <Lachy> | hsivonen, has a Firefox 3 build for mac been released with the new look yet? |
| 15:21 | <Lachy> | or are there final mockups available somewhere? Last I saw, there were just some outlines of the planned look |
| 15:21 | <hsivonen> | Lachy: nightlies |
| 15:21 | <hsivonen> | MikeSmith: my trial balloon about getting feedback to Xalan has gone nowhere |
| 15:22 | <hsivonen> | MikeSmith: specifically: http://issues.apache.org/jira/browse/XALANJ-2419 |
| 15:22 | <MikeSmith> | hsivonen - disappointing but not surprised to hear it |
| 15:22 | <MikeSmith> | I guess they just don't care |
| 15:22 | <hdh> | http://tomayko.com/weblog/2008/01/28/firefox3-mac-theme-lands |
| 15:22 | Lachy | downloads the latest trunk |
| 15:23 | <MikeSmith> | thank god there's saxon at least |
| 15:23 | <MikeSmith> | or thank Michael Kay |
| 15:23 | <hsivonen> | MikeSmith: I'm also mighty disappointed that Saxon doesn't do column numbers, but I'm just biting the bullet and patching it (not nearly as simple as it first looked) |
| 15:24 | <MikeSmith> | I swear I thought there was some extension for Saxon for column numbers |
| 15:24 | <MikeSmith> | maybe worth asking Norm Walsh |
| 15:24 | <hsivonen> | MikeSmith: line numbers only |
| 15:24 | <MikeSmith> | damn |
| 15:24 | <MikeSmith> | that sucks |
| 15:24 | <hsivonen> | MikeSmith: I asked on xml-dev and Michael Kay replied already |
| 15:24 | <MikeSmith> | oh, OK |
| 15:24 | <MikeSmith> | no glimmer of hope there? |
| 15:24 | <Lachy> | ooh, it really does look nice :-) |
| 15:25 | <MikeSmith> | is FF3 UI diferrent from Minefield? |
| 15:25 | <hsivonen> | MikeSmith: it seems to be a design decision |
| 15:25 | <hsivonen> | I have a counter-use case, though |
| 15:26 | <MikeSmith> | unfortunate design decision, that |
| 15:26 | <MikeSmith> | counter-use case? |
| 15:26 | <hsivonen> | MikeSmith: a use case that works as a counter-example for the rationale for the design decision |
| 15:27 | <hsivonen> | anyway, my patch now works |
| 15:27 | <hsivonen> | gotta update the build system still |
| 15:54 | <virtuelv> | X-No-Thanks: http://www.b-list.org/weblog/2008/jan/28/ie8/ |
| 17:03 | <csarven> | Authors: Foo, Bar, Baz --- how would you mark this up in HTML4 and in HTML5? |
| 17:04 | <Philip`> | <p>Authors: Foo, Bar, Baz</p> |
| 17:07 | <csarven> | Philip` in which? |
| 17:08 | <csarven> | there are other possibilities in HMTL4; <hX><ul> or <dl> .. |
| 17:10 | <csarven> | re: http://www.w3.org/html/wg/html5/#the-dl "The dl element introduces an unordered association list consisting of zero or more name-value groups (a description list)" is rather vague imo. that suggests that one can mark a list of news stories with its headline and a summary of it with <dl> -- not that there is an issue with that but its just uncommon. most would approach that with a heading and paragraph for instance |
| 17:11 | <csarven> | in an <ul> or <ol> <li>s |
| 17:12 | <Camaban> | probably not appropriate to sue a list for that |
| 17:15 | <hdh> | the W3C specs use <dl> |
| 17:15 | <Philip`> | csarven: In both |
| 17:16 | <Philip`> | (and I'd probably use <p><b>Authors:</b> Foo, Bar, Baz</p> if I wanted it to stand out more) |
| 17:17 | <csarven> | hdh are you referring to an example in HTML4 at W3C? |
| 17:17 | <Philip`> | (because I wouldn't think of a good reason to do anything more complex than that) |
| 17:18 | <hdh> | XML 1.0 |
| 17:18 | <hdh> | the spec document, in its header |
| 17:19 | <csarven> | Philip` see the first example in http://www.w3.org/html/wg/html5/#the-dl |
| 18:07 | <Dashiva> | Hixie: Available? |
| 19:07 | <Hixie> | heycam: fixed |
| 19:10 | <Dashiva> | Hixie: In the reflecting content attributes section, most of the cases have a "if attribute is absent, return default value, or <type-appropriate null value> if none" clause. But the "DOMString that doesn't fall into any of the above" says nothing about this. |
| 19:11 | <Dashiva> | Do you recall off-hand if that's intended? |
| 19:20 | <Hixie> | no idea |
| 19:48 | <zcorpan_> | Hixie: acid3 now reveals a parsing bug in opera that prevents the test from running at all. could you test that in one of the js tests instead using doc.write() or so? (namely < /script> closing the script) |
| 19:48 | <Hixie> | that comment will disappear in due course |
| 19:48 | <Hixie> | i'm editing as we speak |
| 19:48 | <zcorpan_> | ok. food for something to test otherwise :) |
| 19:49 | <Hixie> | that bug is already tested elsewhere actually |
| 19:49 | <zcorpan_> | ah ok |
| 20:24 | <Hixie> | is there some thing wrong with acid3.acidtests.org/empty.xml ? |
| 20:24 | <Hixie> | as in, is my test invalid somehow? |
| 20:25 | <Hixie> | i don't understand why absolutely no browsers pass test 71 |
| 20:26 | jwalden | looks |
| 20:27 | <SadEagle> | konqueror 4.0.1 does :-) |
| 20:27 | <Hixie> | ok good |
| 20:27 | <Hixie> | glad at least someone does |
| 20:28 | <SadEagle> | might be a bug :-) |
| 20:31 | <jwalden> | Firefox replaces it with 0xFFFD -- that's the replacement code point, right? |
| 20:31 | <gsnedders> | jwalden: yea |
| 20:31 | jwalden | has no idea what the spec says about doing that |
| 20:42 | jwalden | shoots the person who decided to use the word "entity" to mean two different things in the XML spec |
| 20:44 | SadEagle | hands jwalden more bullets |
| 20:44 | <jwalden> | heh, you reading too? |
| 20:46 | <SadEagle> | no, just bad memories :-) |
| 20:47 | <jwalden> | It is a fatal error if an XML entity is determined (via default, encoding declaration, or higher-level protocol) to be in a certain encoding but contains byte sequences that are not legal in that encoding. Specifically, it is a fatal error if an entity encoded in UTF-8 contains any irregular code unit sequences, as defined in Unicode 3.1 [Unicode3]. |
| 20:47 | <jwalden> | I call bug |
| 20:48 | <jwalden> | that's weird that only konqueror would pass that |
| 20:48 | <SadEagle> | may be because we're the only ones using QXML? |
| 20:49 | <SadEagle> | and I am not at all sure it passes for the right reason. |
| 20:49 | <SadEagle> | the test isn't exactly standalone |
| 20:50 | <SadEagle> | jwalden: heh, it fails when I open empty.xml |
| 20:50 | <SadEagle> | jwalden: I think it does the replacement char thing as well |
| 20:50 | <jwalden> | haha |
| 20:51 | <SadEagle> | jwalden: I bet the XML parser doesn't even -see- that character |
| 20:51 | <jwalden> | quite possibly not |
| 20:52 | jwalden | guesses in Moz the stream converter is being initialized with the replacement char for errors and not 0 |
| 20:52 | <SadEagle> | OTOH, is the replacement character legal there? |
| 20:52 | <jwalden> | think so |
| 20:52 | <jwalden> | why wouldn't it be? |
| 20:53 | <SadEagle> | well, KWrite passes that test :p |
| 20:53 | <SadEagle> | FFFD is legal, yep. |
| 20:55 | <Hixie> | other than getComputedStyle() and img.height/width, is there any standards-compliant way to detect whether a style rule had an effect? i don't mind which style rule |
| 20:58 | <Dashiva> | I suppose that rules out all the width/height properties |
| 20:59 | <Hixie> | like offsetWidth? yeah. |
| 21:07 | <Dashiva> | Only thing that comes to mind is server hits for resources (e.g. background-image) but that's probably the inverse of what you want to test |
| 21:09 | <SadEagle> | an implementation could reasonably load them even if a rule isn't applied, no? |
| 21:09 | <jwalden> | or not reload if already cached |
| 21:09 | <jwalden> | which might matter for a public-facing test |
| 21:10 | <Dashiva> | Caching could be defeated, but always loading would be a problem, yes |
| 21:36 | <Hixie> | ok |
| 21:36 | <Hixie> | acid3 is basically done |
| 21:36 | <Hixie> | i have room for two more tests if anyone comes up with something good to test |
| 21:36 | <Hixie> | but other than that, it's done |
| 21:37 | <Hixie> | if anyone wanted to review the test, now's the time :-) |
| 21:37 | <nickshanks> | hixie: are you maintaining http://acid3.acidtests.org/ |
| 21:37 | <Hixie> | yes |
| 21:37 | <SadEagle> | I could whine about the nodeiterator tests some more :-) |
| 21:37 | <Hixie> | are they broken? |
| 21:37 | <Hixie> | i thought i fixed them |
| 21:40 | <SadEagle> | re-checking.. Last I looked, IMHO they relied on unspecified behavior |
| 21:45 | <SadEagle> | e.g. I don't believe that the state of the iterator is specified anywhere if the filter throws an exception |
| 21:46 | <hsivonen> | why does loading this page make Safari quit: http://my.opera.com/MacDev_ed/blog/2008/01/22/core-web |
| 21:46 | <gsnedders> | hsivonen: works fine in Saf3/Leopard |
| 21:47 | <hsivonen> | gsnedders: not for me in either Safari 3 or nightly on PPC Leopard |
| 21:47 | <hsivonen> | In NNW, I see the alternative content for SVG |
| 21:47 | <hsivonen> | works in Minefield |
| 21:48 | <Hixie> | SadEagle: what behaviour do you think the test requires that the spec doesn't? |
| 21:48 | <Hixie> | SadEagle: i thought i'd walked very carefully around the spec's holes |
| 21:49 | <SadEagle> | well, I'll start with this quote: "However, the exact timing of these filter calls may vary from one DOM implementation to another." |
| 21:51 | <Hixie> | does your implementation have different timing than expected by the test? |
| 21:51 | <SadEagle> | sort of --- with respect to how it updates the reference node. |
| 21:52 | <Hixie> | in which test? |
| 21:52 | <SadEagle> | 1 & 2 |
| 21:52 | SadEagle | thinks some more |
| 21:52 | <Hixie> | 1 doesn't mutate the dom |
| 21:53 | <nickshanks> | Hixie: can you post percentages for the latest released versions of top browsers as of the release date of Acid3? i.e. "When first released, here's how some browsers score: ..." |
| 21:53 | <SadEagle> | yeah, but it throws an exception. |
| 21:53 | <Hixie> | and as far as i can tell, the mutations in 2 are such that it doesn't matter whether you do the filter calls "when a traversal operation is performed" or "when a NodeIterator's reference node is removed from the subtree being iterated over and it must select a new one", which are the only two allowed options. |
| 21:53 | <Hixie> | so? |
| 21:53 | <Hixie> | behaviour in the face of exceptions seems well-defined |
| 21:54 | <SadEagle> | does it? it only says to propagate them |
| 21:54 | <SadEagle> | I may be missing something, of course |
| 21:55 | <Hixie> | well what behaviour are you saying is compliant that would cause the test to fail? |
| 21:56 | <SadEagle> | updating the reference node position before calling the filter |
| 21:56 | <SadEagle> | that's in #1, that is |
| 21:57 | Hixie | looks |
| 21:57 | <Hixie> | where? |
| 21:58 | <SadEagle> | / 2 in there would be enough |
| 21:58 | <SadEagle> | the line commented with //2, that is |
| 21:59 | <Hixie> | i don't understand how an implementation could ever _not_ get documentElement there |
| 21:59 | <Hixie> | the filter never gave you an answer for the first one, so how can you assume an answer? |
| 22:00 | <SadEagle> | I don't. You would move to the next position regardless of the answer. |
| 22:00 | <SadEagle> | The answer merely determines whether to return the node to the app. |
| 22:00 | <SadEagle> | I am pretty sure at least xerces behaves the same, I guess I should check. |
| 22:03 | <Hixie> | i can't see anything in the spec that justifies having the reference node be something that hasn't been returned except for two cases: one, before any node has been returned, and then it must be the root node, and two, after a mutation. |
| 22:04 | <SadEagle> | ok, that's a somewhat reasonable reading, though I am not sure that's what's intended. |
| 22:05 | SadEagle | double-checks stuff on test 2.. |
| 22:08 | <SadEagle> | that one is indeed my bug. |
| 22:09 | <Hixie> | certainly i don't disagree that traversal/range is a badly written spec full of vagueries and holes |
| 22:10 | <SadEagle> | anyway, my tendency would be to read it as "if your filter isn't purely functional, good luck. You'll need it" |
| 22:10 | <Hixie> | oh i agree |
| 22:11 | <Hixie> | but i don't think that's a really good thing for a web spec to be saying, really :-) |
| 22:11 | <SadEagle> | And unfortunately, when it comes to vagueries, IMHO DOM2 HTML has it beat |
| 22:11 | <Hixie> | if it was server-side only, that'd be one thing |
| 22:11 | <Hixie> | yes |
| 22:11 | <Hixie> | the difference is |
| 22:11 | <Hixie> | dom2html is being replaced by dom5 html |
| 22:11 | <Hixie> | whereas nobody is working on dom traversal/range |
| 22:12 | <MacDome> | hsivonen: http://my.opera.com/MacDev_ed/blog/2008/01/22/core-web does not quit for me in TOT. however any time you see a crash, a bug at http://bugs.webkit.org/ is most appreciated |
| 22:12 | <SadEagle> | I don't know if too many people use it. Does IE support any of it? I know gecko doesn't support NodeFilter, and Opera's 9.2's impl seems buggy. |
| 22:14 | <hsivonen> | MacDome: that's the weird part. it's auto-quit. the crash reporter doesn't catch it |
| 22:15 | <SadEagle> | hsivonen: might be stack overflow |
| 22:16 | <SadEagle> | Hixie: hmm, my impl guarantees that all the nodes it returns are in the physical list, but I don't think that's required.. |
| 22:17 | <Hixie> | SadEagle: lack of good implementations is what is blocking adoption, i'd wager. |
| 22:17 | <Hixie> | SadEagle: lack of a good spec might be blocking implementations |
| 22:17 | <SadEagle> | Hixie: well, actually let me ask you a question: what should happen if the node that just got tested is moved within the view? |
| 22:17 | <SadEagle> | s/view/physical list/ |
| 22:17 | <Hixie> | mvoed when? |
| 22:17 | <Hixie> | in the filter, after teh filter? |
| 22:17 | <SadEagle> | inside the NodeFilter. |
| 22:18 | <SadEagle> | outside it's well-spec'd |
| 22:21 | <hsivonen> | MacDome: filed http://bugs.webkit.org/show_bug.cgi?id=17073 though not much useful info to report |
| 22:22 | <Hixie> | SadEagle: you mean, if the filter moves the node that's being tested? |
| 22:22 | <SadEagle> | yes. |
| 22:22 | jgraham_ | had a vague notion that people disliked SVG fonts |
| 22:23 | <hsivonen> | jgraham_: oh yes indeed |
| 22:23 | <Hixie> | SadEagle: if the node is _moved_, i have no iea |
| 22:23 | <nickshanks> | i don't get SVG fonts |
| 22:23 | <nickshanks> | how re they better than truetype? |
| 22:23 | <hsivonen> | jgraham_: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5253 would be a much more useful approach |
| 22:23 | <Hixie> | the svg fonts tests can be removed, all it takes is for someone to send me a better test |
| 22:24 | <Hixie> | they were requested by opera |
| 22:24 | <SadEagle> | Hixie: let's make it simpler... what if it's just deleted, from inside the filter, of course |
| 22:24 | <SadEagle> | nickshanks: might be patent issues? |
| 22:24 | <hsivonen> | jgraham_: and as far as visual presentation goes, compatible with deployed SVG renderers |
| 22:24 | <Hixie> | and i checked, and at least safari and mozilla either implement, or plan to implement, svg fonts |
| 22:24 | <Hixie> | so... |
| 22:24 | <Hixie> | SadEagle: well |
| 22:24 | jgraham_ | knows very little about SVG fonts |
| 22:25 | <jgraham_> | I just thought they were unimplemented and disliked, so I was surprised to see them in ACID 3 :) |
| 22:26 | <hsivonen> | SVG fonts in Acid3? well that sure is a surprise |
| 22:26 | <SadEagle> | hmm, this one I am pretty sure is just a test typo: expect(13, i.previousNode(), t4); |
| 22:26 | hsivonen | didn't actually inspect the SVG tests |
| 22:26 | <SadEagle> | since the connects suggest it should be t3 |
| 22:26 | <hsivonen> | I got distracted with reporting a WebKit bug |
| 22:26 | <Hixie> | SadEagle: the spec says "For instance, if a NodeFilter removes a node from a document, it can still accept the node, which means that the node may be returned by the NodeIterator or TreeWalker even though it is no longer in the subtree being traversed." |
| 22:27 | <SadEagle> | Hixie: yeah, but what happens to the reference node, in particular if it skipped over some nodes? |
| 22:29 | <Hixie> | SadEagle: the reference node doesn't change, according to the spec, since the node was removed while the reference node was something else |
| 22:29 | <Hixie> | SadEagle: so i guess the last test of test 2 is wrong |
| 22:30 | <SadEagle> | could you please re-check expectation 13 of test 2 first? :-) |
| 22:30 | <SadEagle> | hmm, for extra fun, the iterator can be reentered. |
| 22:31 | <Hixie> | oops, yeah, that should be t3 |
| 22:31 | <Hixie> | yeah, i was just thinking about that |
| 22:31 | <Hixie> | the spec doesn't even mention that |
| 22:31 | <SadEagle> | anyway, implementation-wise, this sort of scenario is a pain, since you either have to watch multiple nodes per iterator, or re-check membership (which is where the move case comes from) |
| 22:33 | <Hixie> | i agree that it is a pain |
| 22:33 | <Hixie> | we need someone to step up and take this spec and rewrite it to be decent and proper |
| 22:33 | <Hixie> | andunambiguous |
| 22:33 | <Hixie> | i'll happily change acid3 to match whatever spec is made |
| 22:35 | <SadEagle> | the Java/standalone impls are probably something to check.. |
| 22:36 | <Hixie> | not really, since those don't need interop |
| 22:36 | <Hixie> | i would expect the dom specs to cut loose the non-web implementations |
| 22:41 | <SadEagle> | I think if I was writing the spec, my tendency would be to say that if the list is modified from within a filter, an exception is thrown, and the iterator is reset to the beginning of the physical list |
| 22:43 | <Hixie> | that's also non-trivial, you'd have to actually pay attention to the whole tree |
| 22:43 | <SadEagle> | though you get the funny case of the filter throwing an exception -and- modifiying. |
| 22:43 | <Hixie> | personally i'd just say that you change the reference node before calling the filter, and that, like with treewalker, you keep following the reference node |
| 22:43 | <SadEagle> | Not really. You kind of have too, since the reference node may be nested within a tree that is removed. |
| 22:44 | <SadEagle> | heh, which is how I implemented it :-) |
| 22:44 | <Hixie> | you wouldn't have to track that either, with my version |
| 22:44 | <Hixie> | and you could use nodeiterator outside of a document, too |
| 22:48 | <SadEagle> | don't see why that's not possible now. |
| 22:50 | <Hixie> | SadEagle: i mean, outside of the root |
| 22:51 | <SadEagle> | oh, I see, so you wouldn't move the reference node for deletions while the filter is running? |
| 22:51 | jgraham_ | wonders exactly what Charles wants the HTML 5 spec to say about <video> |
| 22:56 | <Hixie> | SadEagle: i wouldn't move the reference node for deletions at all. |
| 22:57 | <SadEagle> | ah. I see what you meant by not needing to track that either. |
| 23:06 | jwalden | curses namespaces |
| 23:23 | <Dashiva> | html:curses |
| 23:25 | <nickshanks> | i think he meant xmlns:curses="http://voodoo.org/ns/curses"; |
| 23:26 | <SadEagle> | would that go with the dumbTerminal module of xhtml3? |
| 23:26 | <nickshanks> | you're thinking of ncurses rahter than voodoo curses |
| 23:27 | <nickshanks> | anyway, i am sleep |
| 23:27 | <nickshanks> | nightall |
| 23:34 | <SadEagle> | heh, all this talk of video makes me want to implement it. But I guess <audio> to go with Audio should be first |