| 00:40 | <AryehGregor> | Hixie, redirects from fragments like <http://www.whatwg.org/C#the-video-element>; seem to be broken. |
| 00:41 | <Hixie> | Philip`: ^ the js file you're sending me has some sort of syntax error |
| 00:42 | <Hixie> | oh it's incomplete |
| 00:42 | <AryehGregor> | I love open-source software: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0453.html |
| 00:42 | <Hixie> | i guess i'll try regenning it |
| 00:43 | <annevk> | AryehGregor, I thought that was pretty funny |
| 00:44 | <Hixie> | i don't understand that e-mail |
| 00:44 | <Hixie> | did you link to the right line? |
| 00:44 | <TabAtkins_> | Hixie: Yes, it was pointing out the recursion check. |
| 00:44 | <TabAtkins_> | (Which was written by Jonas, who was claiming they don't have one.) |
| 00:44 | <Hixie> | the NS_ENSURE_TRUE line? |
| 00:44 | <Hixie> | that doesn't get compiled in release builds |
| 00:45 | <annevk> | it certainly throws a INVALID_STATE_ERR |
| 00:45 | <annevk> | an* |
| 00:45 | <Hixie> | oh i guess just the warning doesn't get compiled |
| 00:46 | <Hixie> | the actual check is compiled |
| 00:46 | <Hixie> | nevermind me |
| 00:48 | <Hixie> | my god i hate sites that log me out automatically |
| 00:50 | <zewt> | like google? heh |
| 00:50 | <Hixie> | when does google do that? |
| 00:50 | <zewt> | gmail/greader randomly logging me out drives me nuts |
| 00:50 | <Hixie> | sounds like a bug |
| 00:50 | <zewt> | seems periodic, like once a week or something |
| 00:50 | <Hixie> | you may have checked a checkbox asking for it |
| 00:50 | <TabAtkins_> | zewt: Your cookie expires eventually, but it should be longer than a week. |
| 00:50 | <zewt> | greader does it the most |
| 00:51 | <TabAtkins_> | (Like, with 2factor auth, you can make it remember for 30 days) |
| 00:51 | <zewt> | heh, for some reason now, after the google apps transition, youtube feels the need to tell me every single time i log in "this account is managed by zewt.org" |
| 00:52 | <zewt> | (yeah, i know, i set it up, thanks again youtube) |
| 00:52 | <annevk> | WebKit is going to share the HTML and XML tokenizer: https://bugs.webkit.org/show_bug.cgi?id=65000 |
| 00:52 | <annevk> | That is kind of interesting... |
| 00:57 | <Hixie> | o_O |
| 00:57 | <Hixie> | that sounds like a world of pain... |
| 00:58 | <Hixie> | wait, it's not going to share the tokeniser |
| 00:58 | <Hixie> | it's just using the same interfaces |
| 01:03 | <annevk> | oh |
| 16:19 | <jgraham> | So… afaict Web DOM Core is wrong about hwo createElement works |
| 16:20 | <jgraham> | In particular if I createElement an element from a script in frame A in the context of a different frame B, the element seems to get the namespace of A or null |
| 16:20 | <jgraham> | Even if the ownerDocument is the document in B |
| 16:21 | <annevk> | createElement always uses the HTML namespace |
| 16:22 | <jgraham> | Either that isn't true or I am going crazy |
| 16:23 | <jgraham> | In particular I have a script running in a SVG document that tries to createElement some elements in the parent HTML document |
| 16:23 | <jgraham> | and they don't seem to end up in the right namespace |
| 16:25 | <jgraham> | and doing s/createElement/createElementNS(xhtml_ns, / fixed the problem |
| 16:25 | <jgraham> | Although I had to look up the xhtml ns |
| 16:26 | <annevk> | well it's not implemented everywhere yet |
| 16:27 | <jgraham> | s/everywhere/anywhere/? |
| 16:43 | <jgraham> | hsivonen: BTW did you see http://krijnhoetmer.nl/irc-logs/whatwg/20110723#l-397 ? |
| 16:44 | Philip` | learns that PHP 5.3 added "goto" statements |
| 16:44 | <Philip`> | (which incidentally happens to break old code that has a function named "goto") |
| 17:01 | <annevk> | jgraham, could be |
| 17:02 | <annevk> | this is what we decided upon years ago |
| 17:03 | <TabAtkins_> | Yo, I'd like to apologize for last night. I was not fair to you or your arguments, which had a lot more merit than I allowed at the time. I'm sorry that we had to part somewhat angry at each other. |
| 17:03 | <TabAtkins_> | ... |
| 17:03 | <TabAtkins_> | goddammit |
| 17:04 | <annevk> | someone had a fight last night |
| 17:04 | <annevk> | teehee |
| 17:05 | <TabAtkins_> | I'd like to apologize to the room for two minutes ago. I was not fair to your eyes, which were a lot cuter than I allowed at the time. I'm sorry that we couldn't have met somewhere more private, whatwg room. |
| 17:05 | TabAtkins_ | hugs whatwg. |
| 17:06 | jgraham | assumes "Yo" is short for "Yo! Sushi" |
| 17:08 | jgraham | realises that might have been a somewhat UK-centric reference |
| 17:08 | <TabAtkins_> | Yes, yes it was. |
| 17:10 | <Philip`> | When I first saw a YO! Sushi, it looked startlingly Japanese |
| 17:10 | <Philip`> | particularly with all the walls seemingly covered in giant anime characters |
| 17:11 | Philip` | guesses that was the intended effect |
| 17:23 | <jgraham> | Were the eyes more or less cute than those of the WHATWG room? |
| 17:23 | <jgraham> | +of the anime characters |
| 17:25 | <jgraham> | Argh |
| 17:25 | <jgraham> | Silly cache |
| 17:28 | <TabAtkins_> | Nobody has eyes cuter than you guys. Especially you, jgraham. |
| 17:29 | <jgraham> | And nobody needs glasses more than you, TabAtkins_ :) |
| 17:29 | <zewt> | (´▽｀) |
| 17:41 | hober | feels the love in #whatwg this morning |
| 18:13 | <sicking> | annevk: ping |
| 18:14 | <annevk> | hey sicking |
| 18:14 | <annevk> | i'm in your timezone |
| 18:14 | <annevk> | o_O |
| 18:16 | <sicking> | annevk: and you're up this early !?! |
| 18:17 | <sicking> | annevk: is there a reason we're forbidding doctypes from getting adopted. It's a very odd exception |
| 18:18 | <annevk> | I think it was because doctypes don't have an associated document |
| 18:18 | <annevk> | but I am happy to change that |
| 18:18 | <annevk> | I wish Acid3 had not tested DOCTYPEs so we could have dropped them on the floor |
| 18:18 | <sicking> | annevk: worst, reason, ever |
| 18:19 | <annevk> | Acid3 even has |
| 18:19 | <annevk> | assertEquals(doctype.ownerDocument, null, "doctype's ownerDocument was wrong after creation"); |
| 18:19 | <annevk> | omg |
| 18:19 | <annevk> | I hate Acid3 |
| 18:19 | <sicking> | get hixie to fix it |
| 18:19 | <sicking> | if it's holding back the web platform, it is counter to its purpose |
| 18:20 | <annevk> | so what do we want? keep doctypes but let them have an ownerdocument? |
| 18:21 | <annevk> | and let them be adopted |
| 18:21 | <sicking> | i was just wanting to let them be adopted for now |
| 18:21 | <sicking> | they do have an owner document generally |
| 18:22 | <sicking> | it's just that when they're created they don't have one |
| 18:22 | <sicking> | i'm not sure how we'd deprecated doctype nodes |
| 18:22 | <sicking> | aren't browsers inserting them in the DOM now? during normal parsing |
| 18:22 | <annevk> | yeah they are |
| 18:22 | <annevk> | so I guess that's not really feasible anymore |
| 18:23 | <sicking> | i think it'd be hard yeah |
| 18:23 | <sicking> | my concern is that removing them would break sites that do document.childNodes[1] to get the document element |
| 18:24 | <annevk> | so adoptNode for doctype would nullify its ownerDocument right? |
| 18:24 | <sicking> | no, it would do the same as for other nodes |
| 18:24 | <annevk> | okay |
| 18:24 | <sicking> | set ownerDocument to the new document |
| 18:25 | <annevk> | so then I just need to remove doctype from the adoptNode line |
| 18:25 | <annevk> | let me do that right now |
| 18:25 | <sicking> | doctypes have a owner document as soon as they are inserted in a doc |
| 18:27 | <annevk> | oh and http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-ensure-samedoc is affected as well |
| 18:27 | <annevk> | the implicit adoption |
| 18:29 | <sicking> | right |
| 18:29 | <sicking> | we've supported implicit adoption forever for doctypes, just not explicit adoption |
| 18:30 | <sicking> | annevk: oh, and i'd be thrilled to say that doctypes always have an owner document, just like all other nodes |
| 18:30 | <AryehGregor> | Yes, please. Also allow cloning them. |
| 18:30 | <AryehGregor> | Down with magic! |
| 18:30 | <sicking> | annevk: i'll just be a bit tricky to define what that that ownerdoc is |
| 18:30 | <annevk> | getting Acid3 changed is a real pain though, Hixie? |
| 18:31 | <AryehGregor> | Has it made SVG fonts optional yet? |
| 18:31 | <annevk> | sicking, why is it harder than for an element? |
| 18:32 | <sicking> | annevk: because you don't create them from a document, but rather from a implementation |
| 18:32 | <sicking> | AryehGregor: nope |
| 18:33 | <sicking> | Acid3 is the IE6 of conformance test suites :) |
| 18:33 | <annevk> | sicking, not funny :) |
| 18:34 | <annevk> | sicking, fixed for adoptNode() |
| 18:35 | <sicking> | yay |
| 18:35 | <annevk> | still throws for documents |
| 18:35 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-document-adoptnode |
| 18:38 | <sicking> | annevk: awesome, thanks! |
| 18:42 | <annevk> | AryehGregor, so yes |
| 18:42 | <annevk> | cloning of doctypes and documents should be allowed? |
| 18:50 | <annevk> | per email debate I just reread that already works |
| 18:51 | <annevk> | but importNode should block documents |
| 18:51 | <annevk> | oh because a document cannot own another one |
| 19:16 | <annevk> | notes: |
| 19:16 | <annevk> | * make deep argument optional |
| 19:16 | <annevk> | * make clone dfn concept-node-clone |
| 19:16 | <zewt> | for feature parity with the rest of the internet |
| 19:17 | <AryehGregor> | What are some examples of where people have reported bugs against a WD that are fixed in ED, or implementers have implemented something based on an obsolete WD? |
| 19:18 | <TabAtkins_> | annevk has several examples, I believe. |
| 19:18 | <annevk> | it happens often, but usually in internal bug reports |
| 19:21 | <Hixie> | wow, if ever there was an argument for amalgamting specs rather than splitting them, it has to be the graph on http://greenbytes.de/tech/tc2231/ |
| 19:22 | <annevk> | so importNode and cloneNode are pretty much identical |
| 19:22 | <annevk> | but one throws for document in implementations and the other doesn't |
| 19:22 | <annevk> | weird |
| 19:29 | <TabAtkins_> | Hixie: I suspect it would be slightly less horrible if they had real names, not RFC numbers. |
| 19:29 | <Hixie> | the whole http layer should just be one spec |
| 19:29 | <Hixie> | having all this stuff split all over the place is ludicrous |
| 19:30 | <annevk> | HTTP itself is becoming 8 or so specs |
| 19:30 | <zewt> | rfcs having no xrefs at all doesn't help |
| 19:30 | <hsivonen> | jgraham: no, I did not see that. (I was away in the countryside as a wedding guest over the weekend and missed just about everything that went on online) |
| 19:30 | <annevk> | I don't really want to fork HTTP though |
| 19:30 | <annevk> | too much effort |
| 19:31 | <TabAtkins_> | zewt: Indeed. RFCs in general are nearly the worst possible format to have split specs among. |
| 19:31 | <zewt> | seems like just publishing rfcs in a format other than fixed-width 80-column with hard page breaks as if people still print on 66-line printers is a hard enough battle |
| 19:31 | <AryehGregor> | They have HTML versions, which are significantly less horrible. |
| 19:31 | <zewt> | (and as if anyone actually prints specs) |
| 19:32 | Philip` | wonders if anyone has printed HTML5 recently |
| 19:32 | <zewt> | one copy, one rainforest |
| 19:36 | <hsivonen> | Philip`: based on tweets, it looked like Jirka printed it recently |
| 19:36 | <hsivonen> | I probably should have started a "why RDFa sucks" wiki page 3 years ago so that I wouldn't need to write the same stuff over and over again |
| 19:47 | <annevk> | never too late |
| 19:53 | <annevk> | applied notes to draft |
| 20:08 | <kangax> | Does anyone remember offhand if form's submit event should fire when form fails validation? I see Opera 11.50 fires it; FF, Chrome don't. |
| 20:09 | <annevk> | looks like a bug in Opera per the specification |
| 20:10 | <annevk> | are you submitting it manually? |
| 20:10 | <annevk> | because if you submit it through submit() Opera is correct |
| 20:10 | <sicking> | annevk: do you know if opera is doing the HTML5 undomanager? |
| 20:11 | <annevk> | i know we don't |
| 20:11 | <jgraham> | sicking: So far we looked at the spec and got confused I think |
| 20:11 | <sicking> | jgraham: cool, i have an alternative proposal that i'm pitching |
| 20:12 | <sicking> | but i don't want to start implementing if other browsers have already set down the HTML5 path |
| 20:12 | <smaug____> | annevk: why you made /deep/ optional? |
| 20:12 | <jgraham> | sicking: Sounds good |
| 20:12 | <Hixie> | sicking: there's been several alternative proposals, i hope we can find something to replace it |
| 20:12 | <sicking> | Hixie: do you know if anyone's implemented what's in the spec? |
| 20:13 | <sicking> | Hixie: if people already have, then it'll be a lot harder to do something else |
| 20:13 | <jgraham> | Hixie: Can you pull it from the spec if it is unimplemented and should not be implemented? |
| 20:13 | <Hixie> | sicking: to my knowledge no. I removed it from the w3c copy to try to prevent it from getting implemented. |
| 20:13 | <kangax> | annevk: no, submitting by pressing submit button |
| 20:13 | <Hixie> | jgraham: well it's not that it shouldn't be implemented, it should get implementation feedback. which it is getting. :-) |
| 20:14 | <sicking> | Hixie: is "we don't like it and don't think it should be implemented" enough feedback :) |
| 20:14 | <Hixie> | sicking: no :-) |
| 20:14 | <Hixie> | sicking: we need _something_ |
| 20:14 | <sicking> | Hixie: second proposal in https://bugzilla.mozilla.org/show_bug.cgi?id=617532#c12 |
| 20:14 | <Hixie> | sicking: (though it's not urgent, certainly) |
| 20:14 | <kangax> | annevk: oh well. i guess will work around for now with `checkValidity` in submit handler. |
| 20:15 | <annevk> | sicking, there's also http://rniwa.com/editing/undomanager.html and http://rniwa.com/editing/undomanager-usecases.html |
| 20:15 | <Hixie> | sicking: what anne said |
| 20:15 | <Hixie> | sicking: please coordinate with other browser vendors on what proposal to implement :-) (feel free to use the whatwg list for this purpose) |
| 20:16 | <annevk> | smaug____, it's optional in some implementations already |
| 20:16 | <annevk> | smaug____, and it makes sense in the same way as making the last argument of addEventListener optional makes sense, I think |
| 20:16 | <sicking> | smaug____: it seems like an argument that would be useful to make optional |
| 20:16 | <smaug____> | it is just not backwards compatible change |
| 20:17 | <smaug____> | it should be optional, but if sites start to rely on it being optional... |
| 20:18 | <annevk> | if sites rely on <input type=datetime> people need to update their browsers too |
| 20:18 | <annevk> | sort of how things work... |
| 20:19 | <smaug____> | calling importNode without the last parameter will throw in some browsers |
| 20:19 | <annevk> | sure |
| 20:19 | <smaug____> | ok, so we don't care about backwards compatibility |
| 20:19 | <annevk> | not with browsers |
| 20:19 | <annevk> | we care about compatibility with content |
| 20:20 | <smaug____> | that is new |
| 20:20 | <annevk> | not really |
| 20:20 | <smaug____> | "not with browsers" |
| 20:20 | <smaug____> | but I'm all for it |
| 20:20 | <smaug____> | we can simplify for example command handling significantly |
| 20:21 | <annevk> | sounds good to me :) |
| 20:26 | <smaug____> | command and menu handling... no need to care about the strange <select> and <input> handling in menu |
| 21:33 | <AryehGregor> | The proposals to remove various link relations are harmless, right? |
| 21:37 | <AryehGregor> | Another question: if a proposal has security issues, who are some good people to CC, like maybe from Mozilla or Opera? I'm CCing abarth on this, but if I could get input from another implementer or two that would be nice. |
| 21:37 | <abarth> | AryehGregor: there are a bunch of moz folks who might be good to CC |
| 21:37 | <abarth> | maybe starting with bz or sid stamm might be good |
| 21:37 | <AryehGregor> | Okay. |
| 21:45 | <abarth> | AryehGregor: some variation of that idea could work |
| 21:45 | <AryehGregor> | Like what? |
| 21:46 | <abarth> | AryehGregor: if you think of it like a popup window that's constrained to the parent page's extent |
| 21:46 | <AryehGregor> | But whose position and focus you can't control? |
| 21:46 | <AryehGregor> | Does that actually satisfy the use-cases (not that I'm totally clear on what those are)? |
| 21:47 | <AryehGregor> | I guess the use-case is something like "let me embed stuff without the site being able to break out and take away my revenue from the banner ad I'm plastering on top of other people's sites". |
| 21:47 | <AryehGregor> | I mean, okay, it could be more innocuous, like Google Translate. |
| 21:47 | <abarth> | there are a couple interesting use cases |
| 21:47 | <abarth> | one tricky one is something like facebook connect |
| 21:48 | <abarth> | let's assume you're already signed into facebook, so you don't need to type your password |
| 21:48 | <abarth> | but you need to approve the connection between the site and facebook |
| 21:48 | <abarth> | facebook wants that UI to be displayed "on top" so that it can't be clickjacked |
| 21:48 | <abarth> | today, they'd need to use a popup window to get that sort of display |
| 21:48 | <AryehGregor> | What's wrong with that? |
| 21:48 | <abarth> | but they don't because popup windows are ugly, hard to use, and have trouble with popup blockers |
| 21:49 | <abarth> | they want the drawing model of a popup |
| 21:49 | <abarth> | but the interaction model of a lightbox |
| 21:49 | <AryehGregor> | Hmm, okay. |
| 21:49 | <AryehGregor> | Seems reasonable. |
| 21:49 | <abarth> | the harder case is when you need to type your facebook password |
| 21:49 | <abarth> | because you're not authenticated to facebook yet |
| 21:50 | <abarth> | then you need an address bar to tell you which site you're interacting with |
| 21:50 | <abarth> | which isn't possible using this mechanism |
| 21:50 | <karlcow> | In which spec atob has been moved? |
| 21:51 | <annevk> | karlcow, HTML, no? |
| 21:51 | <annevk> | http://www.whatwg.org/C#windowbase64 |
| 21:53 | <karlcow> | hmmm |
| 21:53 | <karlcow> | http://dev.w3.org/html5/spec/ |
| 21:54 | <gsnedders> | karlcow: There was an objection to it being included as it was a new feature after LC |
| 21:55 | <gsnedders> | (Despite it having been implemented for almost two decades…) |
| 21:55 | <AryehGregor> | It was added before LC. |
| 21:55 | <karlcow> | in fact I was looking where the data uris were defined. I wanted to know if there is a requirement for base64 on the specification. |
| 21:56 | <karlcow> | but could not find it |
| 21:56 | <gsnedders> | AryehGregor: Before? Then my memory must be wrong… Why was it removed then? |
| 21:56 | gsnedders | has found the commit now, but it gives no justification |
| 21:56 | <AryehGregor> | Because Sam filed a bug, so Hixie removed it, then I complained, the chairs clarified they didn't technically ask him to remove it, and Hixie re-added it. |
| 21:57 | <hsivonen> | Hixie: sharing the HTML tokenizer with the XML code path is not completely nuts. I've been pondering something similar. |
| 21:57 | <gsnedders> | karlcow: base64 for data URIs appears to be completely undefined. |
| 21:57 | <Hixie> | anyone know anything about RFC 4733? I'm trying to work out if you need a separate audio channel or if it can share the audio channel somehow but i'm not able to work it out |
| 21:57 | <Hixie> | hsivonen: really? seems like a world of pain |
| 21:57 | <karlcow> | gsnedders: ah interesting |
| 21:57 | <karlcow> | I was testing a few things about it |
| 21:58 | <hsivonen> | Hixie: the HTML tokenizer is *very* close to what one would want a non-recursive XML tokenizer to look like |
| 21:58 | <karlcow> | gsnedders: http://www.la-grange.net/2011/07/25/data-uri-base-test |
| 21:58 | <hsivonen> | Hixie: except the XML tokenizer needs to be able to deal with the internal subset to be compliant |
| 21:58 | <hsivonen> | hooray for the internal subset |
| 21:58 | <Hixie> | half the rfc seems to say that there's just one audio channel that's the same as the main one, and the other half seems to suggest you need to negotiate a telephone-events channels separately. *confused* |
| 21:59 | <Hixie> | hsivonen: i'd be worried about edge cases like NULLs and so on, but if you say so |
| 21:59 | <abarth> | hsivonen: you're aware that we're starting down that path in webkit, right? |
| 21:59 | <Hixie> | abarth: that's why we're discussing it |
| 21:59 | <hsivonen> | abarth: I just saw a mention in the IRC log |
| 21:59 | <abarth> | its somewhat experimental work |
| 22:00 | <annevk> | we have our own HTML and XML parser but have not done that |
| 22:00 | <hsivonen> | Hixie: I already added PI tokenization in order to be able to use the HTML tokenizer for syntax highlighting XML for View Source |
| 22:00 | <annevk> | maybe now WebKit implements their own XML parser they can implement XML5! |
| 22:00 | <hsivonen> | Hixie: it mishighlights the internal subset, though |
| 22:00 | <hober> | annevk: :) |
| 22:01 | <othermaciej> | our XML parser isn't yet ready to handle XML1 |
| 22:01 | <hsivonen> | annevk: yeah, if the HTML tokenizer is reused, XML5 is very close |
| 22:01 | <annevk> | XML5 is easier :) |
| 22:02 | <annevk> | no need to check Name productions and such |
| 22:03 | <othermaciej> | our new XML tokenizer is similar to our HTML5 tokenizer and reuses some code, but it's not the same piece of code |
| 22:04 | <abarth> | its mostly the data structures / architecture that's shared |
| 22:04 | <abarth> | its going to have its own state machine, for example |
| 22:05 | <Hixie> | that makes more sense to me |
| 22:05 | <hsivonen> | I've been thinking of forking the tokenizer slightly for XML |
| 22:05 | <AryehGregor> | othermaciej, have you remembered about providing innerText feedback? I've had feedback from Microsoft, Mozilla, and Opera since July 14, and am just waiting for WebKit. |
| 22:05 | <othermaciej> | AryehGregor: can you ping hober about it? |
| 22:05 | <hsivonen> | the main need to fork, AFAICT, is to perform qname splitting on colon in the tokenizer for efficiency |
| 22:05 | <hsivonen> | but on the HTML side, you don't want the tokenizer to do that |
| 22:05 | <othermaciej> | AryehGregor: I think the short version is that we won't remove it but I dunno our relative feelings about the other alternatives |
| 22:06 | <hsivonen> | but the states could be shared |
| 22:06 | <hsivonen> | some states like the script stuff would be unused on the XML side |
| 22:07 | <hsivonen> | while PI and internal subset states are needed on top of the HTML states |
| 22:07 | <AryehGregor> | othermaciej, okay. |
| 22:09 | <hober> | AryehGregor: consider me pinged :) |
| 22:15 | jgraham | occasionally hears complaints that the XML parser in Opera is lighting fast but it never appears in benchmarks |
| 22:15 | <jgraham> | s/it/XML parsing/ |
| 22:15 | <jgraham> | So I guess I ought to be promoting XML on the web :) |
| 22:16 | jgraham | hasn't actually tested this though |
| 22:19 | <shepazu> | AryehGregor: no, but in SVG 2, I expect SVG fonts will be optional |
| 22:21 | <AryehGregor> | jgraham, make an XHR microbenchmark that involves downloading a gigantic XML file and then retrieving one trivial piece of data from it. |
| 22:21 | <AryehGregor> | Where the download is cached. |
| 22:21 | <gsnedders> | From the end of the document. |
| 22:24 | <jgraham> | AryehGregor: And give it a catchy name like "MoonArachnid" and tell people it represents browser performance :) |
| 22:27 | <jamesr> | XML parsing should matter for parsing pages served up as XML/XHTML |
| 22:27 | <jgraham> | All three of them |
| 22:27 | <jamesr> | guess the lesson is "don't optimize codepaths that nobody uses", then :D |
| 22:28 | <gsnedders> | jamesr: Until you have a customer who wants a [insane number here] MB SVG file to load quickly on something like a 200 MHz MIPS device, and will pay you for it. :P |
| 22:29 | <jamesr> | heh, true |
| 23:04 | annevk | summons Ms2ger |
| 23:04 | annevk | thinks step 2 in http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-ensure-samedoc cannot happen |
| 23:27 | <annevk> | hmm |
| 23:27 | <annevk> | WHATWG Weekly |
| 23:43 | <annevk> | suggestions anyone? |
| 23:44 | <annevk> | download="" / from-origin / traversal / window.find() / ??? |
| 23:57 | <othermaciej> | annevk: end of W3C Last Call is coming up |