| 00:01 | <annevk> | Hixie, should access control and postMessage() align formats for origin etc? |
| 00:01 | <annevk> | (actually, the answer is yes, so we should probably resolve it...) |
| 00:03 | <Hixie> | scheme://hostname:port |
| 00:03 | <Hixie> | it's just the uri format without a path |
| 00:05 | <annevk> | the differences were that your proposed format included a trailing slash and omitted the default port |
| 00:05 | <annevk> | from a very brief scan |
| 00:05 | annevk | hasn't actually checked the spec though |
| 00:05 | annevk | just the e-mail |
| 00:07 | <annevk> | sees that the spec doesn't have the trailing slash but does omit the default port |
| 00:08 | <Hixie> | yeah, i don't figure most people will include the port |
| 00:09 | <annevk> | ok, I suppose I could make that change to Access-Control-Origin |
| 00:10 | <annevk> | access-item is already flexible enough (does not allow / though) |
| 00:10 | <Hixie> | the / is part of the path |
| 00:10 | <annevk> | right |
| 00:10 | <annevk> | i was wondering whether to allow a trailing slash for copy & paste friendlyness |
| 00:11 | <Hixie> | well, postMessage() actually allows the entire URI |
| 00:11 | <Hixie> | it just ignores the path |
| 00:11 | <Hixie> | and it doesn't include it in event.origin, though that's poorly defined right now |
| 00:12 | <annevk> | k, i'm not going to change that for access-item |
| 00:15 | <annevk> | Hixie, maybe you should use the same syntax as access-item... |
| 00:16 | <Hixie> | annevk: elaborate? |
| 00:18 | <annevk> | for the second argument of postMessage() |
| 00:18 | <Hixie> | i mean, elaborate on what you would want changed in the syntax :-) |
| 00:18 | <Hixie> | right now, it's just a plain old uri/iri |
| 00:18 | <annevk> | so you can use postMessage("...", "example.org") |
| 00:19 | <Hixie> | oh |
| 00:19 | <Hixie> | why? |
| 00:19 | <Hixie> | that just seems like asking for confusion... |
| 00:19 | <Hixie> | i guess i'd recommend that access-item be simplified too :-) |
| 00:21 | <annevk> | hmm |
| 00:22 | <Hixie> | (in particular, i may just make postMessage("...", "example.org") resolve the uri locally instead of throwing an exception) |
| 00:23 | <annevk> | oh, and postMessage("...", "*.example.org") would work |
| 00:24 | <Hixie> | that would make it way more complex |
| 00:24 | <annevk> | probably not so relevant for postMessage, indeed |
| 00:24 | <Hixie> | 99% of the time, you'll just do postMessage("...", e.origin); |
| 00:24 | <Hixie> | to prevent sending messages to new hosts |
| 00:24 | <Hixie> | and on the long run, you'll use endPoints, anyway |
| 00:25 | <Hixie> | and just use postMessage() to set up the original connection |
| 00:28 | <annevk> | suggestions for simplifying access-item are welcome on public-appformats btw :) |
| 00:29 | <Philip`> | Hmph, Opera (9.5) apparently doesn't let me add a doctype to a document |
| 00:29 | <Dashiva> | Opera only supports ninja doctypes |
| 00:30 | <Philip`> | Uhhh |
| 00:33 | Philip` | makes it add a comment instead of a doctype |
| 00:37 | annevk | -> bed |
| 00:37 | <Philip`> | Also, Opera deletes "--" from inside comments |
| 00:39 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cbody%3E%0D%0A%3Cscript%3Edocument.body.appendChild(document.createComment('a-b--c---d----e'))%3C%2Fscript%3E |
| 00:39 | <Philip`> | Looks like an Opera bug |
| 00:52 | <Hixie> | does anyone have anything they'd like me to prioritise? |
| 00:56 | <chrismurf> | No, but thank you for asking :-) |
| 00:58 | <Philip`> | Someone should make something like JSON that can handle 'var x=[];x[0]=x' |
| 01:22 | <kingryan> | Philip`: yaml can probably do that |
| 01:25 | <Philip`> | I think YAML has "&label" and "*label" to mark and refer to bits of structure when you want non-trees, and it seems to be quite handy when writing by hand |
| 01:25 | <Philip`> | (I've no idea how useful or ugly it is when automatically serialising, though) |
| 01:29 | <Philip`> | (But YAML is too crazy and complex to be used where interoperability matters - the spec is a hundred pages long) |
| 01:31 | <Hixie> | so should U+0085 NEXT LINE (NEL) be a space character in html5? |
| 01:31 | <Hixie> | i'm thinking no. |
| 01:33 | <Philip`> | I'd like no because then I could pass UTF-8 through my ASCII parser and it'd still work alright |
| 01:34 | Hixie | is randomly replying to feedback from random folders |
| 01:36 | <Dashiva> | Pick me, pick me! |
| 01:37 | <Hixie> | which folder are you? :-) |
| 01:37 | <Hixie> | does dir="" always default to ltr? |
| 01:37 | <Dashiva> | Dunno, I just felt like saying it |
| 01:37 | <Hixie> | or is there a UA pref for the default? |
| 01:46 | <kingryan> | Hixie: I would suspect that that's based on locales |
| 07:50 | <hsivonen> | Hixie: re: NEL, please no |
| 07:51 | <hsivonen> | Reason: non-ASCII syntax-significant chars => bad |
| 08:16 | <annevk> | Hixie, parsing could use an update |
| 08:29 | <hsivonen> | webben++ http://www.w3.org/mid/47B1B887.7040205⊙gc |
| 11:07 | <annevk> | the DOM is so bloated :( |
| 11:07 | <annevk> | it's pretty sad |
| 11:07 | <annevk> | mostly because it's hard to change at this point |
| 11:10 | <hsivonen> | the DOM is very sad. |
| 11:11 | <hsivonen> | but the Attribute node thing might be changeable at this point |
| 11:11 | <hsivonen> | also getAttribute when the attribute is absent |
| 11:11 | <annevk> | so I was thinking about that |
| 11:11 | <annevk> | it seems to me that Attr is important because it has namespaceURI |
| 11:12 | <annevk> | so can we really change that? |
| 11:12 | <hsivonen> | do you mean enumerating the attributes instead querying one? |
| 11:13 | <annevk> | yeah |
| 11:16 | <annevk> | though maybe Attr could be changed in a way that it does not inherit from Node |
| 11:17 | <annevk> | because Note is fricking bloated |
| 11:17 | <annevk> | s/Note/Node/ |
| 11:18 | <hsivonen> | it would be interesting to know if Attr is in practice used by any scripts except serializers |
| 11:18 | <hsivonen> | do Ajax libraries do that kind of looping over all attributes? |
| 11:22 | <annevk> | element.attributes is used I think |
| 11:56 | <annevk> | hsivonen, btw, do you have a list of things where the DOM assumes UTF-16? |
| 11:57 | <hsivonen> | annevk: I don't. |
| 11:58 | <hsivonen> | annevk: perhaps saying that the DOM requires it misses the point. it's JavaScript strings that assume 16-bit units |
| 11:59 | <harri> | DOM Range is a place where utf-16 is assumed |
| 11:59 | <annevk> | thanks |
| 12:00 | <annevk> | i think i'll raise this with the SVG WG |
| 12:00 | <annevk> | Opera does "UTF-16 units" for getNumberOfChars() and I think it makes sense to keep it that way |
| 12:00 | <annevk> | and not have a slightly different API just for SVG |
| 12:15 | <gsnedders> | hmm, Zs doesn't include u0009–u000D |
| 12:22 | <annevk> | http://lists.w3.org/Archives/Public/www-svg/2008Feb/0017.html |
| 13:21 | <hsivonen> | was there someone on this channel working on Comet stuff? |
| 13:22 | <annevk> | at some point |
| 13:39 | <annevk> | man, who uses nodeiterator anyway? |
| 13:39 | <annevk> | complex :( |
| 13:41 | <annevk> | and not just a little bit |
| 14:03 | <hsivonen> | should OPTIONS on a non-existent URI path return 404? |
| 14:04 | <hsivonen> | presumably yes |
| 14:06 | <annevk> | as in, a non-existent GET URI path? |
| 14:08 | <hsivonen> | annevk: yes |
| 14:08 | <hsivonen> | annevk: if the URI would be 404 on GET or POST |
| 14:09 | <annevk> | either that or maybe METHOD NOT ALLOWED (405 or so?) |
| 14:11 | <gsnedders> | the method is allowed thoguh |
| 14:11 | <gsnedders> | *though |
| 14:11 | <gsnedders> | so that status code can't be used |
| 14:30 | <annevk> | Hixie, where in DOM Level 2 Traversal is it defined what to do with incorrect return values for filters? Such as 'true' and 'false'? |
| 14:36 | <hsivonen> | something tells me Dmitry Turin hasn't paid good attention to what others (Hixie in particular) have written on public-html |
| 14:37 | <annevk> | i always forget to bookmark those posts for reuse as I expect people to understand... |
| 15:45 | <hsivonen> | I wonder if access-control is *now* stable enough to implement in Validator.nu... |
| 15:49 | <hsivonen> | annevk: surely the GET algorithm should apply to HEAD as well |
| 15:49 | <hsivonen> | in access-control |
| 15:53 | <annevk> | I'm not sure how I far I want to open that door |
| 15:54 | <hsivonen> | hmm. looks like Gecko source now has OPTIONS but still the Method-Check stuff |
| 15:54 | hsivonen | implements per spec |
| 15:58 | <annevk> | hsivonen, I'd wait for Firefox 3 to ship |
| 15:59 | <hsivonen> | annevk: do you expect changes to the single-URI policy version? |
| 16:04 | <gsnedders> | "from xxx import *" works fine as a normal import in Python, but how can you deal with such a thing when the module is bound to a variable? |
| 16:05 | Philip` | wonders why #dom li:last-child::before doesn't work right in Firefox |
| 16:05 | <gsnedders> | jgraham__: maintaining backwards compat. is harder than I thought, because everything refers to specific classes/functions in the dom treebuilder |
| 16:09 | <Philip`> | Oh, it does work right in Firefox once you make it reflow or something |
| 16:17 | <hsivonen> | hrm. OPTIONS * seems like a useless complication that doesn't have an upside |
| 16:20 | <hsivonen> | annevk: access-control could use a companion guide for server-side devs |
| 16:33 | <annevk> | hsivonen, I hope on no changes whatsoever |
| 16:33 | <annevk> | however, I have hoped that for the past year |
| 16:37 | <annevk> | hsivonen, OPTIONS *? I'll remind you that you argued for using OPTIONS too :) |
| 16:38 | <hsivonen> | annevk: yeah, OPTIONS is the right way to go, but OPTIONS * is still an unnecessary complication in RFC 2616 |
| 16:39 | <hsivonen> | annevk: I've now deployed access-control on v.nu |
| 16:39 | <annevk> | have fun |
| 16:40 | <hsivonen> | annevk: but it seems that OPTIONS * stuff never reaches the servlet |
| 16:40 | <hsivonen> | not a problem. just weird |
| 16:40 | <hsivonen> | and useless |
| 16:41 | <hsivonen> | oops. And I broke html5.validator.nu and parsetree.validator.nu, it seems |
| 16:42 | <annevk> | that promises something for when less competent people start doing this :( |
| 16:43 | <hsivonen> | annevk: that's not related to handling options. it is another "fix" in the same checkout |
| 16:57 | <hsivonen> | fixed |
| 16:58 | gsnedders | sighs, thinking his change to html5lib is finally working |
| 16:58 | <gsnedders> | Now, to commit. |
| 17:00 | gsnedders | isn't sure if he ever has actually commited before, even though he's had perms for a while |
| 17:22 | <zcorpan> | so the main reasons people use Transitional seems to be (1) be able to use target=_blank and (2) using software that emits markup that only validates as transitional (also mainly due to target=_blank) |
| 17:54 | <webben> | zcorpan: Isn't iframe also a factor? |
| 17:55 | <webben> | (a major factor, I mean) |
| 17:56 | <zcorpan> | webben: less so than target=_blank, it seems. however, iframe is already valid html5 |
| 17:56 | <hsivonen> | zcorpan: is this based on 10 answers to the sitepoint survey? |
| 17:57 | <zcorpan> | hsivonen: yes, and the comments |
| 17:59 | <zcorpan> | s/people/people who are on sitepoint and read the thread and care enough to vote or comment/ |
| 18:08 | <gsnedders> | ergh. |
| 18:08 | <gsnedders> | html5lib relies on minidom's brokenness. |
| 18:10 | <Philip`> | http://philip.html5.org/tools/parser/ |
| 18:11 | <Philip`> | Currently missing quite a few bits (especially anything to do with CDATA or RCDATA etc) but generally it seems to work |
| 18:11 | <gsnedders> | Philip`: that your JS impl? |
| 18:11 | <Philip`> | Yes |
| 18:14 | <gsnedders> | <http://code.google.com/p/html5lib/source/browse/trunk/python/src/html5lib/treebuilders/dom.py#97>; — why do we set a readonly property? |
| 18:16 | <Philip`> | It's irritating that the DOM interface doesn't let you create as many DOMs as an XML parser or HTML parser can |
| 18:17 | <gsnedders> | Philip`: huh? |
| 18:17 | <gsnedders> | we set that readonly property to work around a bug in minidom, seemingly |
| 18:20 | <Philip`> | Oh, I suppose for ownerDocument you can just pass the doctype into createDocument and it'll work alright, so maybe you can do as much as an XML parser |
| 18:20 | <Philip`> | (but it's still not possible to write a proper HTML5 parser in JS because the DOM won't let you create elements and attributes with funny names) |
| 18:22 | <zcorpan> | Philip`: that's really useful |
| 18:23 | gsnedders | wonders how else to work around that bug in minidom |
| 18:23 | <Philip`> | gsnedders: Why does the current workaround not work? |
| 18:24 | <zcorpan> | Philip`: are you catching invalid names for attributes? |
| 18:24 | <gsnedders> | Philip`: if you aren't using minidom, and you're using something that enforces the readonly-ness of the property, it breaks |
| 18:24 | <gsnedders> | How can I check if "Dom" is the module xml.dom.minidom? |
| 18:24 | <Philip`> | gsnedders: If the minidom bug doesn't affect any other DOMs, you could perhaps wrap the property-setting line in try/except and ignore failures |
| 18:25 | <gsnedders> | Philip`: the exception raised depends on what impl you're using, though |
| 18:27 | <zcorpan> | Philip`: is <foo:bar> handled correctly? |
| 18:27 | <Philip`> | zcorpan: Oops, I wasn't checking attributes - fixed now |
| 18:28 | <Philip`> | zcorpan: Depends on what you mean by "correctly" |
| 18:28 | <zcorpan> | Philip`: local name "foo:bar" rather than "bar" |
| 18:29 | <gsnedders> | zcorpan: some DOM's don't allow attributes to be created containing with a ":" |
| 18:29 | <Philip`> | zcorpan: It just does createElementNS('http://www.w3.org/1999/xhtml';, 'foo:bar'), which seems to work with localName correctly |
| 18:29 | <zcorpan> | gsnedders: the w3c dom does |
| 18:30 | <gsnedders> | s/'// |
| 18:30 | <zcorpan> | Philip`: i think that ends up being a "bar" element |
| 18:30 | <Philip`> | s/work/not work/ |
| 18:30 | <Philip`> | I agree now :-) |
| 18:30 | <Philip`> | <foo:p><p> gets parsed wrongly |
| 18:30 | <Philip`> | (because my code just tests localName) |
| 18:30 | <gsnedders> | zcorpan: I get a "foo:bar" in Saf3 |
| 18:31 | Philip` | wonders how he should fix that |
| 18:32 | <zcorpan> | Philip`: either createElement() or throw when there are colons |
| 18:32 | <Philip`> | zcorpan: Could createElement work when I want these things to be in the HTML namespace? |
| 18:33 | <zcorpan> | Philip`: if the browser puts them in the html namespace then yes :) |
| 18:35 | <Philip`> | Why would it put them in the HTML namespace, when they're not being added into an existing HTML document? |
| 18:36 | <zcorpan> | ah. hmm. perhaps because dom5 core will require it? :) |
| 18:36 | <Philip`> | document.implementation.createDocument('a', 'b', null).createElement('foo:bar').namespaceURI only works in Opera :-( |
| 18:40 | <zcorpan> | Philip`: how come <foo:p><p> and <foo:a><a> are different? |
| 18:48 | <Philip`> | zcorpan: <foo:a> doesn't get added to the list of active elements, since it's not an "a" start tag, and so the <a> doesn't realise there's already an active "a" |
| 18:48 | <Philip`> | where <foo:p> does get added to the stack of open elements, and so the <p> does think there's already a "p" |
| 18:51 | <Philip`> | zcorpan: I've updated it to distrust anything that's not /^[a-zA-Z_][a-zA-Z0-9_.-]*$/, which will hopefully avoid those problems |
| 18:53 | <zcorpan> | Philip`: that seems a bit harsh |
| 18:53 | <zcorpan> | are there other characters than the colon that are problematic? |
| 18:54 | <Philip`> | zcorpan: Anything that's not an XML Name should cause an exception |
| 18:54 | <zcorpan> | Philip`: yeah, but it did that before too, no? |
| 18:55 | <zcorpan> | (modulo browser bugs) |
| 18:55 | <Philip`> | It used to cause an exception and then catch it and get rid of anything that's /[^a-zA-Z_]/ |
| 18:55 | <Philip`> | (except in browsers that failed to throw the exception) |
| 18:56 | <Philip`> | (in which case it'd act inconsistently with other browsers, which is probably undesirable) |
| 18:57 | <zcorpan> | well, i guess there are few valid reasons to use <embed ☺> anyway |
| 18:57 | <Philip`> | Or maybe I should just use createElement and forget about the namespace thing, at least for the DOM-viewer version |
| 18:57 | <zcorpan> | sounds reasonable |
| 18:58 | <Philip`> | except that shouldn't help because createElement and setAttribute should still throw exceptions if it's not an XML Name |
| 18:58 | <zcorpan> | it solves the colon problem |
| 18:58 | <Philip`> | (and the only difference is it doesn't have to be a QName) |
| 18:59 | <zcorpan> | and that createElement() takes local name as input rather than qname |
| 19:02 | <Philip`> | zcorpan: Okay, I've changed it to just use createElement by default, and to be more permissive about characters |
| 19:04 | <Philip`> | (It accepts /^[a-zA-Z:_][a-zA-Z0-9:_.-]*$/, else it gets rid of all /[^a-zA-Z_]/) |
| 19:04 | <zcorpan> | why not check against the Name production? |
| 19:04 | <Philip`> | Because that seems long and complex and not very useful |
| 19:05 | <zcorpan> | ok, why not let the browser throw then? |
| 19:06 | <Philip`> | Because then it'll give different output in different browsers (depending on the browser's bugs), which will be a little confusing |
| 19:09 | <zcorpan> | but testing nonascii or random junk is useful |
| 19:10 | zcorpan | is off for food |
| 19:10 | <Hixie> | "Either they continue to use HTML4 Transitional, or they stop to care about conformance, or they use |
| 19:10 | <Hixie> | scripts to insert the target attribute or use window.open(). |
| 19:10 | <Hixie> | " |
| 19:10 | <Hixie> | the last two options are the same as the second option |
| 19:11 | <Philip`> | "the stop to care about the output of conformance checkers" |
| 19:11 | <Philip`> | s//y/ |
| 19:12 | <Hixie> | conformance checkers should check script too |
| 19:13 | <Hixie> | would be interesting to write a conformance checker that supported rewinding |
| 19:13 | <Hixie> | that just went down every branch |
| 19:13 | <Hixie> | checking arguments to every method, etc |
| 19:14 | <Philip`> | Bonus points if it doesn't take infinite time |
| 19:14 | <Hixie> | well obviously it wouldn't check everything |
| 19:15 | <Hixie> | but you could catch a number of simple things |
| 19:16 | <Philip`> | So some well-intentioned person will write some obfuscated code that opens windows in a way the conformance checker can't detect, and then other well-intentioned people will copy-and-paste that so that their pages validate successfully |
| 19:16 | <Hixie> | and they'll get a warning "warning: script could not be verified" |
| 19:17 | <Hixie> | if people want to ignore a validator, why would they use a validator? |
| 19:17 | <Philip`> | They'll ignore those warnings because every non-trivial script will give that warning |
| 19:17 | <Hixie> | i think most people don't realise that setting target from script is non-conforming |
| 19:19 | <Philip`> | It's hard enough trying to decide that some code will always terminate, without always giving up and saying "can't verify code" |
| 19:24 | <Hixie> | i'm just sayin', it'd be useful |
| 19:24 | <Philip`> | Many impossible things would be useful :-) |
| 19:24 | <Philip`> | s/impossible/hard/ |
| 19:25 | <weinig> | annevk: just to update you on what olliej mentioned last night |
| 19:25 | <weinig> | annevk: I am in the process of implementing the new postMessage |
| 19:26 | <weinig> | annevk: it has not landed yet though |
| 19:26 | <gsnedders> | Hixie: can you fix the occurrence of title"" in source? |
| 19:38 | <Hixie> | gsnedders: i thought i had |
| 19:39 | <gsnedders> | Hixie: oh, wait. I doing this from a local copy. |
| 19:39 | gsnedders | looks at the current copy |
| 19:39 | <gsnedders> | yeah, it's fixed. |
| 19:39 | <Hixie> | k |
| 19:40 | gsnedders | is too tired |
| 19:41 | <gsnedders> | Hixie: for the cross-referencing (per HTML 5) should I do any normalisation (of whitespace? of Unicode? or case?) before calculating cross references? |
| 19:42 | <Hixie> | space characters should go to one space, yeah |
| 19:42 | <Hixie> | several of the title attributes and element contents span multiple lines |
| 19:42 | <gsnedders> | currently the spec says it must be exactly identical |
| 19:43 | <gsnedders> | Hixie: (I mean in the HTML 5 def of dfn) |
| 19:43 | <Hixie> | probably best to normaline case too |
| 19:43 | <Hixie> | yeah that's all gonna be dropped i think |
| 19:43 | <gsnedders> | ah. |
| 19:46 | gsnedders | notes that on his private playing around copy that actually processing the DOM is now slower than parsing |
| 19:47 | <Philip`> | import psyco |
| 19:47 | <Philip`> | Makes things much faster! |
| 19:48 | gsnedders | ponders |
| 19:48 | gsnedders | expands graph |
| 19:48 | <gsnedders> | Okay, that isn't good. |
| 19:49 | <gsnedders> | Python is definitely too slow. That sucks. |
| 19:49 | <Philip`> | You could use Java |
| 19:50 | <gsnedders> | I know no Java, which is a slight issue. |
| 19:50 | <Hixie> | python is slow, generally, but i wouldn't bet on python's speed being the gating factor unless you're making a ray tracer or something |
| 19:51 | <gsnedders> | Hixie: or maybe `cat header_whatwg source` is too big for a python spec-gen :) |
| 19:51 | <Hixie> | shouldn't be |
| 19:51 | <Hixie> | i mean, the overhead isn't going to be _that_ big, regardless of what language you use |
| 19:52 | <Hixie> | (the spec splitter is a python script, e.g.) |
| 19:53 | <zcorpan_> | Hixie: ok, s/conformance/validating their documents/ |
| 19:54 | gsnedders | thinks he could try doing this another way, actually |
| 19:54 | <zcorpan_> | Hixie: also, window.open() isn't non-conforming, is it? |
| 19:54 | <Hixie> | zcorpan_: window.open with _blank is |
| 19:54 | <Hixie> | iirc |
| 19:54 | <zcorpan_> | window.open(url) works |
| 19:55 | <Hixie> | iirc that's non-conforming |
| 19:55 | <Hixie> | oh, i guess it's not explicitly non-conforming |
| 19:55 | <Hixie> | oh well |
| 19:55 | <Hixie> | anyway i think you're right, and _blank will just have to be made valid. we'll just have to make it optional to implement instead. |
| 19:56 | gsnedders | thinks he'll be able to do it in a more memory expensive way |
| 19:56 | <zcorpan_> | makes sense |
| 19:56 | <gsnedders> | (but the overhead is still not that big) |
| 19:56 | <Hixie> | zcorpan_: any time the spec requires opening a new top-level browsing context, i think the current one should be selected instead |
| 19:56 | <Hixie> | zcorpan_: i'm getting more and more annoyed by sites that decide when i'm opening a page in a new tab |
| 19:57 | <Hixie> | and since all i have is a spec-hammer, all problems look like spec-nails to me |
| 19:57 | <zcorpan_> | Hixie: yeah, but that's configurable in the browser |
| 19:57 | <bradee-oh> | Hixie: weinig has a question for you (and he's a pansy) |
| 19:57 | <Hixie> | not currently, but yeah |
| 19:57 | <Hixie> | bradee-oh: brt |
| 19:58 | <zcorpan_> | Hixie: using the spec-hammer doesn't stop sites opening new windows, it just makes it harder to configure because it becomes an arms race |
| 19:58 | <gsnedders> | jgraham__: ping |
| 19:58 | <Hixie> | zcorpan_: yeah |
| 19:58 | <weinig> | Hixie: hey, we were just curious what an <ihost> refers to? |
| 19:59 | <Hixie> | weinig: same as <host>, but for IRIs |
| 19:59 | <weinig> | Hixie: ah, ok |
| 19:59 | <Hixie> | weinig: did i use it in a paragraph without a reference? |
| 19:59 | <gsnedders> | Hixie: in Resource metadata management |
| 20:00 | <Hixie> | oops |
| 20:00 | <Hixie> | someone send mail :-) |
| 20:00 | <gsnedders> | weinig: can you? |
| 20:00 | <weinig> | gsnedders: sure |
| 20:01 | <weinig> | Hixie: I will also send mail regarding this, but, is postMessage supposed to work with file: urls? |
| 20:01 | <gsnedders> | (i.e., not the guy who pointed out where it was, but the one who found it) |
| 20:01 | <Hixie> | weinig: basically, anything involving file: URIs is not my concern, since you don't need interop for anything that's using file: URIs. so it's up to you. |
| 20:01 | <Hixie> | weinig: but generally i would say i guess it would work, but origin would be null |
| 20:02 | weinig | nods |
| 20:02 | <gsnedders> | Hixie: when replacing spaces for x-refs, what space characters should be done? just ASCII ones? |
| 20:04 | <Hixie> | i'd just do whatever falls under the "space character" definition in html5 |
| 20:04 | <gsnedders> | k. |
| 20:04 | <Hixie> | but for me, it just needs to be space and linefeed |
| 20:04 | <gsnedders> | all "me" Hixie :) |
| 20:13 | gsnedders | doesn't particually want to commit this to html5lib because he expects he'll be shot for it |
| 21:03 | <jgraham__> | gsnedders: I'm kinda here |
| 21:04 | <gsnedders> | jgraham__: would I be shot if I committed a "except Exception"? |
| 21:04 | <gsnedders> | specifically, to work around a bug in minidom |
| 21:04 | <jgraham__> | No, well you would unless you just write except: (no need for the Exception bit) :) |
| 21:05 | <jgraham__> | gsnedders: Yeah, that seems like a reasonable use case |
| 21:05 | <jgraham__> | (I read the logs earlier) |
| 21:05 | <gsnedders> | the exact exception depends on the DOM impl, as I said |
| 21:06 | <jgraham__> | Yeah, the alternative (if Dom == xml.dom.minidom) seems just as bad |
| 21:10 | <gsnedders> | jgraham__: and should I add pxdom to the parser tests even though one test fails, due to a bug in pxdom? |
| 21:11 | <jgraham__> | gsnedders: Yeah, for sure. But email html5lib-discuss⊙gc explaining why the test fails |
| 21:11 | <gsnedders> | k |
| 21:11 | <gsnedders> | (I've already emailed the author of pxdom about the bug, fwiw) |
| 21:15 | <jgraham__> | gsnedders: Have you looked at making multiple dom imps work with treewalkers |
| 21:16 | <gsnedders> | jgraham__: I haven't yet tried, but a quick look at the code made me think it would work |
| 21:16 | <jgraham__> | Yeah, I don't know how much woulkd need to be changed. Maybe just adding pyxdom to the tests |
| 21:17 | <gsnedders> | jgraham__: what file would they need to be added in for that? |
| 21:17 | <gsnedders> | test_treewalkers.py? |
| 21:18 | <jgraham__> | tests/testtreewalkers.py |
| 21:18 | <jgraham__> | yeah. |
| 21:19 | <annevk> | thanks weinig |
| 21:22 | <gsnedders> | jgraham__: yeah, it works fine with the DOM treewalker. |
| 21:22 | <gsnedders> | (pending the other bug that comes up again) |
| 21:22 | <jgraham__> | Great |
| 21:29 | <gsnedders> | I think I'll send a general email about what I've done |
| 21:41 | gsnedders | commits and sends email |
| 21:45 | <Hixie> | updated http://www.hixie.ch/specs/dom/messages/0.9 |
| 21:48 | <annevk> | could you add some rational etc? |
| 21:49 | <annevk> | it's not really clear to me what problem it's trying to solve |
| 21:51 | <Hixie> | rationale, you mean? |
| 21:51 | <Hixie> | sure |
| 21:52 | <annevk> | yeah |
| 22:28 | <Hixie> | it would be interesting to have a .reply() API for the postMessage() stuff |
| 22:39 | <aroben> | Hixie: in, e.g., step 2.4 of the postMessage() algorithm, does "these steps" mean the substeps of step 2 or all the steps of the algorithm? |
| 22:39 | <aroben> | Hixie: I assume the latter |
| 22:45 | <Hixie> | all of them |