| 11:26 | smaug____ | files a spec bug |
| 11:36 | <smaug____> | Ms2ger: FYI, I'm pretty sure I won't accept a patch which overloads appendChild() etc |
| 11:40 | <annevk> | we overload everywhere else |
| 11:43 | <smaug____> | annevk: why to overload in this case? |
| 11:43 | smaug____ | tries to find some reasoning in webapps mailing list archive.. |
| 11:44 | <smaug____> | the original idea was .append(), which feels better |
| 11:46 | smaug____ | can't find any reasoning for overloaded appendChild() etc |
| 11:52 | <annevk> | cause it makes sense and is convenient? |
| 11:53 | <annevk> | introducing a whole array of new methods seems rather expensive |
| 11:53 | <smaug____> | how is it convenient ? |
| 11:53 | <annevk> | and not really consinstent |
| 11:53 | <annevk> | consistent* |
| 11:53 | <smaug____> | how are new methods any more expensive than overloading existing ones ? |
| 11:54 | <smaug____> | overloading makes methods slower |
| 11:54 | <annevk> | you get way more methods to remember, objects get bigger, etc. |
| 11:55 | <smaug____> | (and appendChild etc are very "hot" methods in the web) |
| 11:55 | <smaug____> | objects get bigger? |
| 11:55 | <smaug____> | (shared) prototype may contain the new method, but that's it |
| 11:56 | <annevk> | i guess if the speed argument holds up that may be problematic |
| 11:56 | <annevk> | but not everyone was convinced it would |
| 11:59 | <annevk> | and if we introduce a new append() method that does the overloading and stuff you have the same basic problem |
| 11:59 | <annevk> | overloading appendChild further was also discussed in the Element.create threads btw |
| 11:59 | <annevk> | for consistency with how that would work |
| 11:59 | <smaug____> | append() would be the possibly-slower overloaded thingie |
| 11:59 | <smaug____> | I don't understand why to make backwards incompatible changes to appendChild |
| 12:00 | <smaug____> | (not that I'm really worried about backwards compatibility in this case) |
| 15:18 | <Ms2ger> | https://bugzilla.mozilla.org/show_bug.cgi?id=690287, for people with an interest in UA sniffing |
| 15:20 | <Rik`> | ah that reminds me I have to open a bug |
| 16:11 | <smaug____> | could someone educate me; what is the use case for iframe's srcdoc ? |
| 16:12 | <Hixie> | sandboxing comments in a blog post |
| 16:13 | <smaug____> | Hixie: how is srcdoc different from src="data:text/html,... ? |
| 16:13 | <Ms2ger> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-January/024823.html |
| 16:13 | <Hixie> | smaug____: easier to not screw up the escaping |
| 16:13 | <smaug____> | Hixie: but that is the only difference? |
| 16:14 | <Hixie> | smaug____: the only one of consequence, i think |
| 16:14 | <smaug____> | ok |
| 16:15 | <Hixie> | there's also some minor things like you don't need a <title> in a srcdoc document |
| 16:15 | <Hixie> | and i may have said that it's always in standards mode, i forget |
| 16:16 | <smaug____> | I think I didn't find the place which describes the structure of srcdoc document |
| 16:16 | <smaug____> | I thought it would be parsed like data:text/html, |
| 16:16 | <smaug____> | well, like anything else |
| 16:17 | smaug____ | can't remember if parser creates <title> automatically |
| 16:17 | <Ms2ger> | No |
| 16:24 | <Hixie> | oh another difference is that relative URLs in srcdoc documents resolve relative to the parent doc |
| 16:24 | <Hixie> | with data: URLs you can't use relative URLs |
| 16:25 | <Hixie> | similarly, Referer: headers get set correctly for srcdoc docs but not data: docs |
| 16:27 | <Hixie> | anyway the net result is that a srcdoc works better than data: would and you don't have to be as verbose and you're less likely to screw up the escaping, which makes it more secure in practice |
| 17:13 | <smaug____> | Hixie: ah |
| 17:14 | <smaug____> | where is it spec'ed that relative URLs work like that |
| 17:15 | smaug____ | found |
| 17:16 | smaug____ | wishes the place where srcdoc is defined would mention that relative URLs work differently etc |
| 17:33 | <Hixie> | smaug____: click on the definition of "srcdoc document" and it links you to all the places that mention it |
| 17:34 | <smaug____> | oh |
| 17:34 | <smaug____> | that doesn't look like something one could click |
| 17:34 | <smaug____> | but ok |
| 17:34 | <smaug____> | thanks |
| 17:34 | <Hixie> | all the definitions are clickable (doesn't work so well in the multipage version, unfortunately) |
| 20:10 | <AryehGregor> | compiz is using 2.6G of resident memory. |
| 20:10 | <AryehGregor> | . . . |
| 20:13 | AryehGregor | wonders if it's related to his use of unsupported experimental video drivers |
| 20:20 | AryehGregor | wonders what happens if he kills compiz . . . probably ends his desktop session |
| 20:20 | <AryehGregor> | Let's find out! |
| 20:21 | <AryehGregor> | Absolutely nothing. |
| 20:21 | <AryehGregor> | Probably because of the compiz --replace I had already run. |
| 20:22 | <AryehGregor> | New incantation to reduce obscene memory usage: Alt-F2, exec compiz --replace, then kill -9 the old compiz from a terminal. |
| 20:22 | <AryehGregor> | <3 Linux |
| 20:26 | <bga_> | :) |
| 21:54 | <annevk> | Hixie, would probably still be useful to mention in a non-normative note what the differences are explicitly |