| 00:50 | <heycam> | hi people. are there ecmascript objects that stringify in non-default ways, apart from window.location and window.getSelection()? |
| 00:51 | <MacDome> | one can always override toString... |
| 00:52 | <heycam> | yeah. i'm wondering what other (host) objects do that. (or perhaps stringify in a different way, e.g. by having a different [[DefaultValue]] method.) |
| 01:06 | <othermaciej> | heycam: in WebKit, Range and HTMLAnchorElement also have custom toString methods (though not sure if that is necessary or correct) |
| 01:07 | <othermaciej> | javascript:alert(document.links[0]) on most pages will show the result |
| 01:07 | <heycam> | ok, thanks |
| 01:10 | <othermaciej> | heycam: looks like Mozilla does at least the HTMLAnchorElement one as well (serializing as its own href) |
| 01:10 | <heycam> | yeah i just noticed. maybe the spec should say something? |
| 01:10 | <othermaciej> | heycam: it's also possible that there are more classes in WebKit which serialize in a custom way, but do it too obscurely for my simple search to find |
| 01:11 | <othermaciej> | (I found Selection, Location, Range and HTMLAnchorElement) |
| 01:11 | <heycam> | (ie7 also does the HTMLAnchorElement thing) |
| 01:12 | <othermaciej> | I suspect serializing anchors that way is needed for compatibility, so yes, HTML5 should probably say something |
| 01:18 | <gavin__> | Gecko appears to have custom toStrings for HTMLAnchorElements and HTMLAreaElements, Range, Selection |
| 01:19 | <gavin__> | and some CSSOM related objects that I don't really know about |
| 01:19 | <gavin__> | othermaciej's caveat applies |
| 01:20 | <heycam> | thanks gavin__ |
| 01:20 | <gavin__> | I didn't find Location because its magical, for example |
| 01:20 | <heycam> | how's the magic implemented there? |
| 01:20 | <gavin__> | well it's magic for reasons other than having a custom tostring |
| 01:21 | <heycam> | ah |
| 01:21 | <gavin__> | oh, actually I'm wrong |
| 01:21 | <gavin__> | I just missed it |
| 01:21 | <gavin__> | http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsLocation.cpp#979 |
| 01:22 | heycam | wonders if [[DefaultValue]] is ever overridden in imlementations |
| 03:22 | <Hixie> | ok now IE is just TRYING to fail these tests |
| 03:22 | <Hixie> | i finally found something that EVERY BROWSER EXCEPT IE failed |
| 03:23 | <Hixie> | and i added it to acid3 |
| 03:23 | <Hixie> | and now it fails in IE, because IE handles code in eval() differently from code in a js block |
| 03:23 | <Hixie> | so IE still fails every test |
| 03:23 | <Hixie> | EVEN THE ONES I ADDED SPECIFICALLY TO GIVE IT A NON-ZERO STARTING SCORE |
| 03:24 | <hober> | heh |
| 04:26 | <othermaciej> | Hixie: code in eval() is supposed to be treated differently from code in a JS block in some ways |
| 04:26 | <MacDome> | sadly Acid3 seems to have borked again... oh well |
| 04:26 | <MacDome> | and we're now 92%! |
| 04:26 | <MacDome> | huaazh |
| 04:45 | <Hixie> | othermaciej: different how? |
| 05:53 | <MacDome> | Hixie: sadly the HMTL5 spec does not support your form.elements.length == form.elements testcase. http://bugs.webkit.org/show_bug.cgi?id=16656 |
| 05:53 | <MacDome> | unless I missed something in my reading thereof |
| 05:54 | <Hixie> | FIXED |
| 05:54 | <Hixie> | er |
| 05:54 | <Hixie> | fixed |
| 05:54 | <Hixie> | that was a typo |
| 05:54 | <Hixie> | i meant to test form.elements.length against form.length |
| 06:29 | <MacDome> | Hixie: oh good. well, I just sent an email about it :) |
| 06:29 | <MacDome> | Hixie: said email contained a list of all WebKit bugs re: Acid3 |
| 06:29 | <MacDome> | which I imagine you will find interesting :) |
| 06:29 | <Hixie> | cool |
| 06:30 | MacDome | goes to look at why the latest Acid3 file causes webkit to fail completely |
| 06:30 | <MacDome> | ah, it's fixed again, good |
| 06:30 | <MacDome> | except now we're 88% instead of 91% :( |
| 06:32 | <Hixie> | teehee |
| 06:32 | <Hixie> | do you know of any bugs in safari or mozilla that i should test? |
| 06:33 | <MacDome> | well, XHTML support is riddled w/ bugs :) |
| 06:33 | <MacDome> | embedding bugs are a big deal for me |
| 06:33 | <MacDome> | Hixie: I really think the test could benefit from using something like these: http://trac.webkit.org/projects/webkit/browser/trunk/LayoutTests/fast/js/resources/js-test-pre.js |
| 06:33 | <Hixie> | i mean DOM or JS things |
| 06:33 | <MacDome> | for making it easier to debug |
| 06:34 | <MacDome> | Hixie: I'll think about it next time I'm sorting through old bugs |
| 06:34 | <Hixie> | you mean reporting something more than the test number? |
| 06:34 | <Hixie> | i'm not sure exactly what one would need to report |
| 06:34 | <MacDome> | Hixie: breaking the ifs down into single tests |
| 06:35 | <MacDome> | instead of if (foo || bar || baz) fail! |
| 06:35 | <MacDome> | it could be |
| 06:35 | <MacDome> | assert(!foo); |
| 06:35 | <MacDome> | assert(!bar) |
| 06:35 | <MacDome> | etc |
| 06:35 | <Hixie> | and have assert thrown an exception or something? |
| 06:35 | <Hixie> | i could i guess |
| 06:35 | <MacDome> | sure |
| 06:35 | <MacDome> | and then the wrapper could catch it |
| 06:35 | <Hixie> | seems tdious |
| 06:35 | <MacDome> | it would certainly make debugging easier. to have things be single-line. but maybe it's not worth it |
| 06:36 | <MacDome> | it could throw an exception containing the assertion text. |
| 06:36 | <MacDome> | which would allow you to report things better |
| 06:36 | <Hixie> | then only the first bit that fails would be run |
| 06:36 | <MacDome> | but again, maybe not worth it |
| 06:36 | <Hixie> | but i guess that's ok |
| 06:37 | <Hixie> | (of each test) |
| 06:37 | <MacDome> | well, you obviously have lots of time to play with differnet methods for differnet tests |
| 06:38 | <MacDome> | perhaps you'll find one you like better than the current |
| 06:38 | <MacDome> | from a debugging standpoint, watching for when "ok" turns false, and then checking each part of an if () clause can be a bit tedius |
| 06:38 | <Hixie> | true |
| 06:38 | MacDome | goes back to debugging the latest build |
| 06:41 | <Hixie> | how do i distinguish a DOMException object from a string thrown by 'throw' in a spec-compliant way that works in IE? |
| 06:42 | <MacDome> | Hixie: ha! it looks like test 56 is impossible to pass. You never set ok to true! :) |
| 06:43 | MacDome | assumes he meant to initialize ok to true |
| 06:43 | <Hixie> | fixed |
| 06:43 | <MacDome> | Hixie++ # for testing reserved words! |
| 06:43 | <MacDome> | Hixie: that was one thing I *really* wanted to see moz fix |
| 06:44 | <Hixie> | any others? |
| 06:44 | <MacDome> | or rather.. to see all browsers agree on |
| 06:44 | <Hixie> | i have no idea how to handle this exception thing |
| 06:44 | <MacDome> | Hixie: can't you grab the prototype off of an object in IE? |
| 06:44 | <MacDome> | Hixie: or maybe .toNumber() the exception? |
| 06:45 | <Hixie> | is there a spec that guarantees either of those do anything sane for DOMException? (specifically, a spec that was in CR or better in 2004) |
| 06:46 | <Hixie> | i'll just throw an object with a 'message' property |
| 06:46 | <Hixie> | that works everywhere |
| 06:47 | <Hixie> | i'm amused that test 85 is the only test ie can pass |
| 06:47 | <Hixie> | i'm not especially targetting IE either |
| 06:47 | <Hixie> | i'm really only worrying about mozilla and safari bugs, by and large |
| 06:48 | <Hixie> | (except for things other people have told me to test) |
| 06:48 | <Hixie> | (like ie's attribute mess) |
| 06:48 | <MacDome> | Hixie: it woudl appear that the 30s are misnumbered in comment |
| 06:48 | <MacDome> | it says we fail "39" but according to the comments there is no 39 :) |
| 06:49 | MacDome | goes to look at the DOMException spec |
| 06:50 | <MacDome> | what the hell is an "exception" instead of an "interface" in idl |
| 06:51 | <Hixie> | how is there no 39 |
| 06:52 | MacDome | reads http://www.w3.org/TR/DOM-Bindings/#idl-exceptions |
| 06:53 | <MacDome> | Hixie: so is e.code accessible within IE? |
| 06:54 | <othermaciej> | Hixie: maybe not the difference you noticed, but there are some intended behavior differences for eval code, for example "var" declarations create bindings that are *not* DontDelete under eval |
| 06:54 | <Hixie> | MacDome: that's one of the things i test i believe |
| 06:54 | <Hixie> | othermaciej: ah |
| 06:54 | <Hixie> | othermaciej: is that in the spec? |
| 06:55 | <MacDome> | Hixie: you were just asking for ways to identify DOMExceptions, I had assumed you were looking to replace the e.HIERARCHY_.... check |
| 06:55 | <MacDome> | which fails in Safari and seems to disagree w/ the spec |
| 06:55 | <othermaciej> | Hixie: some differences are spec'd here: http://bclary.com/2004/11/07/#a-10.2.2 |
| 06:56 | <MacDome> | interesting. IE always makes .constructor DontEnum |
| 06:57 | <MacDome> | even if it might be |
| 06:57 | <othermaciej> | Hixie: ah, in fact that section includes the difference I mentioned |
| 06:57 | <Hixie> | MacDome: no, i was looking for ways to change the framework to handle custom exceptions. i cheated instead. |
| 06:57 | <Hixie> | othermaciej: cool |
| 06:57 | <MacDome> | Hixie: I wonder if you can grab at e.constructor and check to see if it's a DOMException that way... I'm not actually sure what e.constructor will get you, othermaciej would probably know |
| 06:58 | <Hixie> | i can only rely on things that either work 100% reliably from DOM Level 0, or things that were in specs at CR or later in 2004 |
| 06:58 | <Hixie> | DOM Bindings wasn't even close to either |
| 06:59 | <MacDome> | november 2000: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-17189187 ? |
| 06:59 | <Hixie> | MacDome: where's the ".constructor" part of that? |
| 06:59 | <MacDome> | I was thinking .constructor was on Object |
| 07:00 | <Hixie> | exceptions aren't necessarily Objects |
| 07:00 | <Hixie> | they're host objects |
| 07:00 | <Hixie> | which basically (as of 2004) had no defined behaviour |
| 07:00 | <Hixie> | insofar as .constructor goes |
| 07:00 | <Hixie> | as far as i can tell |
| 07:00 | MacDome | wonders what an exception can be if not an "Object" in JS. I guess it could be another primitive type... |
| 07:01 | <Hixie> | host objects don't have to be any primitive type as i understand it |
| 07:09 | <MacDome> | Er r or Obj e c t s |
| 07:09 | <MacDome> | I nst ances of Er r or obj ect s ar e t hr own as except i ons when r unt i me er r or s occur . The Er r or obj ect s may al so |
| 07:09 | <MacDome> | ser ve as base obj ect s f or user - def i ned except i on cl asses. |
| 07:10 | <MacDome> | Hixie: according to ECMA e.constructor.prototype.name == "Error" for all runtime exceptions |
| 07:11 | <MacDome> | Hixie: assuming I'm reading 15.11 correctly |
| 07:11 | <Hixie> | sure, but user-thrown exceptions and DOM-thrown exceptions aren't runtime exceptions |
| 07:11 | <MacDome> | correct, they are not required to be based from Error |
| 07:11 | <MacDome> | Hixie: user exceptions at least |
| 07:11 | <MacDome> | Hixie: I'm not sure about DOM exceptions |
| 07:11 | <Hixie> | DOM exceptions are effectively user-defined |
| 07:11 | <Hixie> | or rather, host-defined |
| 07:11 | <Hixie> | (which is even less useful to us) |
| 07:11 | <Hixie> | dom bindings addresses all this, luckily |
| 07:13 | <MacDome> | well, throw can throw any arbitrary value, so that's no hel |
| 07:13 | <MacDome> | p |
| 07:14 | <Hixie> | yeah, i just settled on throwing a { message: "" } object |
| 07:14 | <MacDome> | nice new error messages! |
| 07:14 | <MacDome> | I just reloaded and saw them |
| 07:14 | <Hixie> | i'm up to test 36 |
| 07:15 | <MacDome> | bah. once again you check e.NAMESPACE_ERR which isn't supported by any spec I've seen |
| 07:16 | MacDome | bitches instead of fixing the "bug" |
| 07:16 | <Hixie> | DOM2 Core, appendix E |
| 07:18 | <MacDome> | nice new tests, btw. |
| 07:19 | <MacDome> | Hixie: sure, and javascript:alert(DOMException.HIERARCHY_REQUEST_ERR) is valid in Safari |
| 07:19 | <MacDome> | Hixie: but just because it's a property on the constructor funtion doesn't mean it's a property on the prototype |
| 07:20 | <Hixie> | do you agree that instances of Node have the node type constants on their objects? |
| 07:21 | <MacDome> | sure. it's defined for any object conforming to the Node interface: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1950641247 |
| 07:21 | <MacDome> | http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-17189187 DOMException seems to have no such requirement |
| 07:21 | <Hixie> | the text defining that for JSis exactly the same as the text defining the constants should be on all exception objects |
| 07:22 | <MacDome> | I don't follow |
| 07:22 | <MacDome> | Foo.bar != (new Foo).bar |
| 07:22 | <Hixie> | the only reason Node objects have those constants is the text in appendix E that says that Node.ELEMENT_NODE on the "Prototype Object Node" is present |
| 07:23 | <MacDome> | (the easy solution is obviously for us to implement these constants as part of the DOMException interface), I'm just not sure I understand how that's implied form the spec yet |
| 07:23 | <Hixie> | which is the same text as the text that says that DOMException.INDEX_SIZE_ERR on the "Prototype Object DOMException" is present |
| 07:23 | <MacDome> | ah... |
| 07:23 | <Hixie> | so either the constants should be present in both cases, or in neither cae |
| 07:24 | <Hixie> | case |
| 07:24 | <MacDome> | Prototype Object DOMException |
| 07:24 | <Hixie> | now i agree that the text in the spec sucks, which is why we need the DOM Bindigns spec |
| 07:24 | <MacDome> | I can see how that could be used to mean that the prototype for the object DOMException shoudl have those constants |
| 07:24 | <MacDome> | ok, I'll concede Prototype Object DOMException saves your case |
| 07:24 | <Hixie> | but i can't see any way to interpret that spec which leads to exceptions being different from nodes in this regard |
| 07:25 | <MacDome> | Hixie: well, ignoring appendix E, I think my point is valid |
| 07:25 | <Hixie> | appendix E is the only reason we have anything in JS at all |
| 07:25 | <MacDome> | Hixie: the rest of the spec clearly demands that (new Node).ELEMENT_NODE be valid. |
| 07:25 | <MacDome> | and demands that HIERARCHY_REQUEST_ERR be defined |
| 07:25 | <MacDome> | but makes no such demand on (new DOMException).HIERARCHY_REQUEST_ERR |
| 07:25 | <Hixie> | i disagree; i don't see anything that says how to interpret that idl other than appendix E |
| 07:26 | MacDome | shrugs |
| 07:26 | MacDome | goes to prepare the fix |
| 07:27 | <Hixie> | hehe |
| 07:27 | <Hixie> | i've done half the tests with error messages |
| 07:27 | <Hixie> | i'll do the other half in a bit |
| 07:28 | MacDome | enjoys having such a formidable spec opponent. :) |
| 07:28 | <Hixie> | :-) |
| 07:31 | MacDome | sighs. DOMException.idl appears non-autogenerated :( |
| 08:03 | <MacDome> | sigh. Hixie's got webkit down to 85% :( |
| 08:05 | <MacDome> | actually 85% for 3.04, 88% for TOT |
| 08:06 | <MacDome> | Hixie: soooo much easier to debug, btw. thanks. |
| 08:46 | <othermaciej> | I think MacDome doesn't realize that the test will not seem legit if WebKit passes out of the box |
| 08:49 | <Hixie> | i'm far more interested in seeing compliant browsers than in having my life be easy in making the test seem legit |
| 08:50 | <othermaciej> | yeah, but if he keeps fixing bugs, you'll have to keep adding tests |
| 08:50 | <Hixie> | that is a problem i welcome with open arms |
| 08:50 | <othermaciej> | I mean, not that I'm against people fixing more bugs |
| 09:06 | <hsivonen> | Hixie: you could test that XHTML docs implement HTMLDocument and check that document.body and stuff works |
| 09:06 | <Hixie> | is there a way to do that purely from DOM? |
| 09:07 | <Hixie> | (i'm trying to avoid external files) |
| 09:09 | <hsivonen> | Hixie: I'm not sure if it is possible with 2004 specs. with HTML 5 it should be. :-) |
| 09:09 | <hsivonen> | Hixie: unless there's a spec for DOMParser |
| 09:10 | <Hixie> | testing html5 in an acid test will be for acid4, maybe :-) |
| 09:10 | <hsivonen> | which I doubt |
| 09:10 | <Hixie> | there's dom3 load and save, but i'm pretending that doesn't exist |
| 09:10 | <hsivonen> | (I doubt DOMParser has a spec that is) |
| 09:11 | <hsivonen> | Hixie: anyway, document.body would be a test that'd help acid3 look legitimate by WebKit not passing :-) |
| 09:11 | <hsivonen> | in XHTML that is |
| 09:11 | <Hixie> | heh |
| 09:12 | <Hixie> | i could createDocument() an XHTML doc |
| 09:18 | <othermaciej> | hsivonen: XHTML documents implementing HTMLDocument is not required by any spec but HTML5 afaik |
| 09:18 | <Hixie> | and dom2 html |
| 09:18 | <othermaciej> | I thought it was allowed but not required by dom2 html |
| 09:18 | othermaciej | checks his references |
| 09:19 | <Hixie> | it's required as much as HTMLDocument is required for text/html, as far as i can tell |
| 09:19 | <Hixie> | of course back in those days specs were so vague... |
| 09:20 | <othermaciej> | yeah, it seems to be required for XHTML 1.0 as much as for HTML 4.01, which is to say, not very clearly required at all |
| 09:20 | <othermaciej> | wow, so many statements in DOM 2 HTML are just outright factually false |
| 09:20 | <Hixie> | do paste them here |
| 09:21 | <othermaciej> | "In many cases, these enhancements are not applicable to a general DOM because they rely on the presence of a predefined DTD." |
| 09:21 | <krijnh> | http://www.digg.com/software/Ian_Hickson_s_having_a_bit_of_trouble_writing_ACID3 :P |
| 09:22 | <othermaciej> | Hixie: I do know of one DOM Level 1 Core thing that I think every browser gets wrong per spec (but which probably can't be fixed) |
| 09:22 | <Hixie> | yeah i'm avoiding those |
| 09:23 | <Hixie> | and yeah, the DTD stuff is funny |
| 09:23 | <othermaciej> | elt.getAttribute("nonexistentAttribute") is supposed to return empty string instead of null |
| 09:23 | <Hixie> | back in those days people believed it |
| 09:23 | <hsivonen> | DTDs have the questionable honor of being the second most misunderstood part of XML right after namespaces |
| 09:27 | <othermaciej> | out of the official w3c DOM tests, WebKit fails 6 of the DOM1 Core ones, 1 of the DOM2 Core, 1 of the DOM2 Events, and 5 of the DOM2 HTML |
| 09:27 | <othermaciej> | (in some cases a few more than that in xhtml instead of html, not sure why) |
| 09:29 | <Hixie> | othermaciej: is there a summary of those failures somewhere? |
| 09:29 | <Hixie> | e.g. bugzilla query? |
| 09:30 | <othermaciej> | not in bugzilla |
| 09:31 | <othermaciej> | if you have a WebKit tree checked out, WebKitTools/Scripts/check-dom-results gives counts of tests that appear to succeed, and you can search for "fail" in .txt files in LayoutTests/dom/* to find which specific tests fail |
| 09:31 | <othermaciej> | a lot of the DOM3 Core ones fail due to unimplemented useless features |
| 09:31 | <Hixie> | i do not have a checkout right now |
| 09:31 | <othermaciej> | most of the others are deliberate failures for web compatibility I think |
| 09:31 | <Hixie> | k |
| 09:31 | <othermaciej> | but not sure |
| 09:31 | <othermaciej> | I looked at the DOM 1 Core failures |
| 09:32 | <othermaciej> | 3 are because we allow implicit adoption when inserting a node from another document |
| 09:32 | <othermaciej> | which we added because Gecko allowed it and some sites started to depend on it |
| 09:32 | <othermaciej> | (or maybe it was intranet "enterprise" products w/ a web interface) |
| 09:33 | <othermaciej> | one is due to returning null for getAttribute of a nonexistent attribute |
| 09:33 | <Hixie> | yeah we should just allow that |
| 09:33 | <Hixie> | i don't understand why implicit adoption wasn't allowed |
| 09:33 | <Hixie> | and getAttribute's null thing needs fixing |
| 09:33 | <Hixie> | in the spec |
| 09:33 | <othermaciej> | yes, yes it does |
| 09:34 | <Hixie> | Web DOM Core 4 |
| 09:34 | <othermaciej> | asking for that to be fixed was one of my first unpleasant experiences with the w3c |
| 09:34 | <Hixie> | or 5 i guess :-) |
| 09:34 | <othermaciej> | many years ago |
| 09:34 | <Hixie> | oh? |
| 09:34 | <othermaciej> | let me see if I can find the thread in the archives |
| 09:35 | <othermaciej> | ah, the two other failures are also due to not throwing WRONG_DOCUMENT_ERR |
| 09:35 | <othermaciej> | so 5 failures for allowing implicit adoption, one for returning null from getAttribute |
| 09:35 | <othermaciej> | I can tell you that last time I tested, every other browser failed a lot more of these |
| 09:35 | <othermaciej> | even the DOM1 Core tests |
| 09:36 | <othermaciej> | I think the DOM2EV test we fail is due to dispatching events in both capture and bubble phases to the target node |
| 09:36 | <othermaciej> | (technically they should only bubble, but that causes web compat issues due to Gecko's longstanding behavior in this regard) |
| 09:37 | <Hixie> | yeah, i'm not testing that one either |
| 09:37 | <Hixie> | i'm not testing anything that we want to change |
| 09:38 | <othermaciej> | http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0024.html |
| 09:38 | <othermaciej> | http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0025.html |
| 09:38 | <othermaciej> | both had floods of angry responses |
| 09:39 | <othermaciej> | here's another interesting message from around the same time: http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0076.html |
| 09:39 | <othermaciej> | (incompatibility between DOM 2 Core and DOM 3 Core) |
| 09:40 | <othermaciej> | (on a minor extremely boring edge case issue though) |
| 09:46 | <othermaciej> | hey, proof that I'm stubbornly consistent in my beliefs: http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0047.html |
| 09:52 | <Hixie> | proof that i am: http://lists.w3.org/Archives/Public/www-html/1998Dec/0003.html |
| 09:57 | <Hixie> | heh, i found that html4 had no real conformance criteria back in 1999: http://lists.w3.org/Archives/Public/www-html/1999Feb/0010.html |
| 09:59 | <othermaciej> | heh |
| 09:59 | <othermaciej> | well, we have higher standards now |
| 10:00 | <Hixie> | it's sad that from 1998 to 2004 we basically made no progress |
| 10:00 | <Hixie> | i'm glad we have finally shaken ourselves free of the old guard |
| 10:00 | <othermaciej> | well, some of that was the state of affairs in the browser market during that period |
| 10:23 | <Hixie> | i need more tests |
| 10:23 | <Hixie> | let me know if you come up with any |
| 10:23 | <Hixie> | bed time now |
| 13:42 | <Philip`> | http://www.natural-innovations.com/wa/xhtml.html - hmm, XHTML was sometimes referred to as HTML 5.0? |
| 13:46 | <webben> | Philip`: http://groups.google.com/group/mail.www-html/browse_thread/thread/140306dc90e21ce3/a0bef1d6fde4d332?lnk=st&q=voyager+w3c+%22html+5.0%22#a0bef1d6fde4d332 perhaps |
| 13:57 | <Philip`> | webben: Ah, thanks |
| 13:58 | <Philip`> | http://www.w3.org/TR/1998/WD-html-in-xml-19981205/ talks about Voyager, but I can't find any 'official' references to an HTML 5.0 so I guess that term just fell out of favour before catching on |
| 22:21 | <Philip`> | http://intertwingly.net/blog/?q=%00 - yay for XML |
| 22:25 | <Philip`> | (Also http://golem.ph.utexas.edu/instiki/search?query=%00 etc) |
| 22:26 | <Philip`> | (Also http://golem.ph.utexas.edu/instiki/save/HomePage etc) |
| 22:26 | <Philip`> | Are there any non-trivial dynamically-generated XHTML sites that successfully ensure well-formedness? |
| 22:32 | <hsivonen> | Philip`: Validator.nu used to be a dynamically-generated app (even if not site) that ensured well-formedness, but now it may have holes like that--I have not tested properly for forbidden characters after I did some major rework in the front end |
| 22:33 | <hsivonen> | bullet-proofing it against \0, etc. is one of the many items I should take care of |
| 22:34 | <hsivonen> | actually, I could find out right now |
| 22:35 | <hsivonen> | yep, Validator.nu is broken after the major rework :-( |
| 22:35 | <hsivonen> | my options are: |
| 22:35 | <hsivonen> | 1) Hacking the Xalan serializer (hard) |
| 22:35 | <hsivonen> | 2) Writing a SAX filter (easy but potentially inefficient) |
| 22:35 | <hsivonen> | and |
| 22:36 | <hsivonen> | 3) Writing my own XML serializer (tedious with namespaces) |
| 22:38 | <hsivonen> | hmm. and 4) filtering in a Writer after the serializer |
| 22:39 | <Philip`> | Those all sound like great fun |
| 23:49 | <G0k> | oy all |
| 23:49 | <G0k> | are there any test cases for cross-document messaging? |