| 00:05 | <Hixie> | wow, onbeforeunload and multipart/x-mixed-replace don't mix well |
| 00:07 | <Hixie> | onunload fires in firefox |
| 00:07 | <Hixie> | safari fails to parse it right as far as i can tell |
| 00:08 | <Hixie> | and opera doesn't fire it |
| 00:08 | <Hixie> | well then |
| 00:09 | <Hixie> | firefox doesn't fire onbeforeunload |
| 00:12 | <gsnedders> | Opera practically never fires unload, though |
| 00:15 | <Hixie> | why does firefox ignore the call on http://damowmow.com/playground/demos/multipart/003.html? |
| 00:15 | <Hixie> | (go to http://damowmow.com/playground/demos/multipart/ then click the 003 link to test) |
| 00:15 | <Hixie> | (you should end up back at http://damowmow.com/playground/demos/multipart/ ) |
| 00:19 | <Hixie> | ok i guess the answer is that we just repeat step 20 of the navigate algorithm for each component |
| 01:21 | <Hixie> | i wonder how i get a multipart/x-... to abort |
| 01:30 | <Hixie> | oh actually that will just work if i fix the bug that back() doesn't abort a document |
| 01:30 | <Hixie> | ok so here's a question |
| 01:31 | <Hixie> | if half-way through a multipart/x-mixed-replace you hit a back() call |
| 01:31 | <Hixie> | should the browser be allowed to keep buffering that document such that if you go forward again it continues from where you left off? |
| 01:31 | <mkanat> | Ah, I would say no. |
| 01:31 | <Hixie> | not required, mind |
| 01:31 | <Hixie> | a browser can always discard anything in the session history |
| 01:32 | <mkanat> | I don't think it would make sense. |
| 01:32 | <Hixie> | yeah it'd probably hurt servers, too |
| 01:32 | <Hixie> | ok |
| 01:32 | <mkanat> | Think of the Bugzilla use case, for example. |
| 01:32 | <mkanat> | (We're one of the only people to actually implement x-mixed-replace in a non-COMET fashion.) |
| 01:33 | <Hixie> | wouldn't that use case argue for it to be supported? |
| 01:33 | <Hixie> | it would mean you could go forward again without waiting for the query to load |
| 01:43 | <mkanat> | Hixie: Ah, as a Bugzilla server maintainer, I wouldn't want the server load to continue. |
| 01:43 | <Hixie> | yeah, that's what i figured |
| 01:43 | <mkanat> | Hixie: Also, usually if somebody goes back from the search page, it's to change their search and do a new one. |
| 01:43 | <Hixie> | true |
| 02:41 | <aho> | oh boy oh boy oh boy! text-overflow:ellipsis finally landed in FF7 (stable) |
| 02:42 | <roc> | you mean it finally shipped |
| 02:42 | <aho> | eh |
| 02:42 | <aho> | yea |
| 02:42 | <aho> | :) |
| 02:43 | <roc> | that reminds me, I need to blog about how our implementation is better than everyone else's |
| 02:43 | <aho> | vertical margin collapse for tables next? :>~ |
| 02:43 | <roc> | that is actually just about to land |
| 02:44 | <aho> | :O |
| 02:44 | <aho> | i was actually kinda joking |
| 02:44 | <aho> | it's the duke nukem of firefox bugs |
| 02:44 | <aho> | :> |
| 02:44 | <aho> | https://bugzilla.mozilla.org/show_bug.cgi?id=87277 - reported: 2001-06-22 |
| 10:00 | <smaug____> | Someone should review quirksmode's tests |
| 10:00 | <smaug____> | and result |
| 10:00 | <smaug____> | way too many bugs there :/ |
| 10:01 | <smaug____> | in the tests |
| 14:10 | <annevk> | http://my.opera.com/daniel/blog/2011/09/28/reparse-xml-as-html hmm |
| 14:10 | <annevk> | didn't know that |
| 14:10 | <Rik`> | does it gives an alert in the console for developers? |
| 14:10 | <miketaylr> | it should show it in the error console |
| 14:11 | <annevk> | but what it says about other browsers there? |
| 14:11 | <annevk> | is that actually true? |
| 14:11 | <miketaylr> | yep, http://miketaylr.com/post/d15ad477.png |
| 14:12 | <miketaylr> | that i don't know |
| 14:12 | <annevk> | and we only do this for browsing context loads I hope |
| 14:12 | <annevk> | not e.g. DOMParser or XHR |
| 14:12 | <annevk> | but that's pretty self-evident I guess |
| 14:13 | <annevk> | back later |
| 15:23 | <twisted`> | hi, in Chrome when I use an input type image I the value gets hidden, but in Firefox it stays |
| 15:24 | <twisted`> | IE also hides it |
| 15:40 | <woef> | Is there a plan to improve feature detection? ie let the browser itself respond whether it has already implemented certain features (correctly)? |
| 15:41 | <Philip`> | No, because the browser's response will be wrong often enough to make the feature detection useless |
| 15:42 | <Philip`> | e.g. it implements the feature but forgot to update the detection status, or it claims to implement a feature when it's unusably buggy or when it only implements half of it |
| 15:43 | <aho> | http://dev.w3.org/csswg/css3-conditional/ |
| 15:43 | <jcranmer> | or when it correctly implemented a feature but the feature has since changed under them |
| 15:43 | <aho> | @supports ( display: flexbox ) {...} |
| 15:43 | <Philip`> | Or it simply lies about the feature in order to avoid "sorry, your browser is not supported" messages on major sites |
| 15:47 | <woef> | aho: cool |
| 15:49 | <woef> | Philip`: maybe a "we now it's fucked" marker only? |
| 15:49 | <woef> | So if it returns nothing, you're still on your own. I guess browser vendors won't risk having those around for no good reason. |
| 15:49 | <Philip`> | If they know they've implemented a feature that badly, they should disable the feature entirely |
| 15:49 | <woef> | Having problems with the placeholder positioning in webkit right now and it's damn sad. |
| 15:50 | <Philip`> | Also they often won't realise there's problems until after releasing |
| 15:50 | <woef> | I guess things won't we that bad once we have the conditional css. Though I figured feature detection was all about not having to do that anymore :) |
| 15:55 | <smaug____> | twisted`: what you mean with "value gets hidden"? |
| 15:57 | <smaug____> | or, what you mean "it stays" |
| 15:58 | <aho> | woef, this *is* feature dection... just w/o the js, the added classes to the root element, and the change in selector specificity |
| 15:59 | <aho> | well, ok. the features are queried, not tested for |
| 16:00 | <aho> | (usually the used tests are just queries though) :> |
| 16:00 | aho | splits the hair once more |
| 16:11 | <twisted`> | smaug____: oh, well I fixed it differently (got rid of the whole form) but what I meant is: in Firefox when you create a form with a input type="image" and set a value="bla |
| 16:11 | <twisted`> | " |
| 16:12 | <twisted`> | and then with CSS set a background image, it shows [bla] with the bg image |
| 16:12 | <twisted`> | in Chrome and IE the button is [ ] (empty value shown) with a background |
| 16:52 | <dglazkov> | good morning, Whatwg! |
| 16:53 | <divya> | hi dglazkov! |
| 16:53 | <divya> | (finally an echoback) |
| 16:54 | <dglazkov> | divya: exactly! |
| 16:54 | <dglazkov> | :) |
| 16:54 | <divya> | :)) |
| 16:55 | <jcranmer> | don't you mean good afternoon? |
| 16:55 | <divya> | dglazkov: i tl;dr; the component model spec and my tl;dr; question was are browsers allowed to create their own custom templates e.g. <x-myownbrowsersilo-component> |
| 16:55 | <dglazkov> | divya: no. That's only something authors can do. |
| 16:56 | <dglazkov> | jcranmer: it's morning outside, thus no. |
| 16:56 | <divya> | k thnx dglazkov |
| 17:53 | <Hixie> | hm, no anne |
| 17:53 | <Hixie> | anyone know anything about XHR2 plans? |
| 17:55 | <nlogax> | using html5 d&d, how would you for example outline areas as droppable for certain kinds of data? i had to resort to overriding the standard behavior (embedding chromium) |
| 17:55 | <nlogax> | since you can't read what's being dragged above you |
| 17:56 | <nlogax> | can of course do it in hacky ways but.. |
| 17:57 | <smaug____> | Hixie: what about XHR2 ? |
| 18:20 | <Hixie> | nlogax: dropzone="" attribute or reading the type information from the event (you can read the type, just not the data) |
| 18:23 | <nlogax> | Hixie: but the type seems to be hardcoded to only accept a handful of things |
| 18:23 | <nlogax> | in chromium at least |
| 18:23 | <nlogax> | maybe that's a bug then? |
| 18:25 | <nlogax> | hmm yeah, seems like it. http://jsfiddle.net/9YK5s/4/ |
| 18:25 | <nlogax> | works fine in safari |
| 18:26 | <nlogax> | and firefox.. doh. picked the wrong horse. |
| 19:47 | <AryehGregor> | rniwa, do you have an opinion on this? http://www.w3.org/Bugs/Public/show_bug.cgi?id=14253 |
| 19:47 | rniwa | looks |
| 19:48 | <rniwa> | AryehGregor: this is about allowing execCommand to take cm, mm, pt, etc...? |
| 19:48 | <AryehGregor> | rniwa, I'm suggesting a new command, maybe fontSizePt. fontSize takes legacy sizes 1-7, which isn't what users expect from WYSIWYG editors. |
| 19:49 | <rniwa> | oh I see |
| 19:49 | <rniwa> | mn... adding new command for each new unit seems inelegant |
| 19:49 | <AryehGregor> | I suggest a command that accepts pt, since that's what editors normally use. |
| 19:49 | <AryehGregor> | All the other absolute units are defined as a multiple of pt. |
| 19:49 | <rniwa> | mn... |
| 19:49 | <AryehGregor> | So I think it would be okay to just have one for pt. |
| 19:49 | <AryehGregor> | We could allow input in other absolute units, like px or mm. |
| 19:49 | <rniwa> | oh I see |
| 19:50 | <rniwa> | what you're saying that allowing it to be more precise in pt? |
| 19:50 | <AryehGregor> | So execCommand('fontSizePt', false, '12') might be the same as execCommand('fontSizePt', false, '12pt'), but you could also do execCommand('fontSizePt', false, '16px'). |
| 19:50 | <AryehGregor> | Yes. |
| 19:50 | <rniwa> | right |
| 19:50 | <rniwa> | okay |
| 19:50 | <rniwa> | I think that makes sense |
| 19:50 | <AryehGregor> | However, queryCommandValue() would always have to return pt. |
| 19:50 | <rniwa> | right |
| 19:50 | <AryehGregor> | Since it has to return some specific unit, and pt makes the most sense for WYSIWYG. |
| 19:50 | <rniwa> | although it'll be nice if it were configurable |
| 19:50 | <AryehGregor> | Although getComputedStyle returns px. |
| 19:50 | <rniwa> | but then... people can always get px value out of getComputedStyle |
| 19:50 | <AryehGregor> | How could it be configurable? |
| 19:50 | <rniwa> | add some command like |
| 19:51 | <rniwa> | FontSizeWithPx |
| 19:51 | <rniwa> | just like styleWithCSS |
| 19:51 | <rniwa> | but kind of ugly to introduce those states too though |
| 19:51 | <rniwa> | anyway lunch time for now. |
| 19:51 | <AryehGregor> | I don't like commands like that, because they're global. It will make other code do something unexpected. |
| 19:51 | <rniwa> | will be back ~hour |
| 19:51 | <AryehGregor> | Okay. |
| 19:51 | <rniwa> | AryehGregor: yeah, not too nice |
| 20:16 | <annevk> | maybe it should expose the CSSValue API somehow |
| 20:16 | <annevk> | but I'm not really sure how |
| 20:16 | <annevk> | might be better to wait somewhat longer with introducing features such as FontSizePt until everything else is better adopted |
| 20:17 | <AryehGregor> | annevk, the current fontSize command doesn't allow you to even *set* font size to anything other than 1-7. |
| 20:17 | <AryehGregor> | And it gives you the font size back in that unit too. |
| 20:17 | <AryehGregor> | It's crippled. |
| 20:18 | <AryehGregor> | fontSizePt would work just fine for normal authoring use-cases, which fontSize does not. |
| 20:19 | <annevk> | if it's not supported now it's prolly not that high priority |
| 20:19 | <annevk> | we're still not quite sure over the CSSOM |
| 20:19 | <annevk> | not really sure this needs to move faster than that |
| 20:19 | <AryehGregor> | queryCommandValue() just returns a string. |
| 20:19 | <AryehGregor> | It can return the size in points. |
| 20:19 | <AryehGregor> | We could add a separate API later to retrieve the size in other units or whatnot. |
| 20:19 | <AryehGregor> | If anyone wants it. |
| 20:19 | <AryehGregor> | But it's not really necessary. |
| 20:20 | <annevk> | we could also wait in general |
| 20:20 | <AryehGregor> | Generally I'm trying to fix existing stuff before adding more, but this is a simple and useful addition. |
| 20:33 | <AryehGregor> | I want to test something. Someone say my name. |
| 20:35 | <Philip`> | AryehGregor: Like this? |
| 20:35 | <AryehGregor> | Philip`, yeah, thanks. |
| 20:36 | <AryehGregor> | Was testing whether Unity tells you which window wants your attention like gnome-panel's task switcher does. It doesn't. |
| 20:37 | <astearns> | AryehGregor: why define fontSizePt over fontSizePx? |
| 20:37 | <AryehGregor> | astearns, because all WYSIWYG editors use pt, not px. |
| 20:38 | <astearns> | but specifying on-screen browser text in points is not WYSIWYG |
| 20:39 | <AryehGregor> | astearns, sure it is. In CSS, a 1px = 0.75pt. |
| 20:39 | <AryehGregor> | s/a //. |
| 20:41 | <Hixie> | annevk: do you know anything about streaming upload in xhr? (i.e. where a web page is generating data to send and starts sending it before it has finished generating it) |
| 20:44 | <astearns> | AryehGregor: since points are defined by the reference pixel, I think it's less misleading to use pixels (since that's what it actually comes down to) |
| 20:46 | <AryehGregor> | astearns, the actual definitions don't really matter. Almost no one who uses a WYSIWYG editor could tell you that a pt is 1/72 of an inch. It's an arbitrary unit that people are used to, that's all. |
| 20:47 | <astearns> | I'd rather the web platform push "16px" as normal text, instead of "12pt" that's not particularly relevant to the screen |
| 20:47 | <AryehGregor> | I'd rather the web platform do whatever users expect. |
| 20:47 | <AryehGregor> | Web pages are printable too, you know. |
| 20:48 | <astearns> | 16px prints out just fine |
| 20:48 | <AryehGregor> | px is meaningless for print, however. |
| 20:48 | <AryehGregor> | Just like pt is meaningless for screen. |
| 20:48 | <AryehGregor> | The difference is, users are used to pt. |
| 20:51 | <TabAtkins> | "meaningless" being relative, since the two are defined to have a strict ratio to each other. |
| 20:52 | <AryehGregor> | We could make the API px and expect authors to translate to pt, but they'll get it wrong. |
| 20:52 | <AryehGregor> | So let's just make it pt to start with. |
| 20:52 | <astearns> | is the fontSizeSomething API being designed for those WYSIWYG users who are scared of pixels? |
| 20:53 | <AryehGregor> | astearns, yes. The entire execCommand() API is for WYSIWYG. |
| 20:53 | <astearns> | there are a lot of people around me who do know what points are, and get it wrong when they assume that CSS points are 1/72 of an inch :) |
| 20:53 | <TabAtkins> | AryehGregor: He meant wysiwyg development, not scripting a wysiwyg editor. |
| 20:54 | <AryehGregor> | astearns, CSS points are 1/72 of a CSS inch, and also 1/72 of an actual inch when printed. |
| 20:54 | <AryehGregor> | TabAtkins, hmm? |
| 20:54 | <annevk> | Hixie, it's not supported |
| 20:54 | <TabAtkins> | AryehGregor: execCommand() is for scripting a WYSIWYG editor. Alan's talking, I think, about a WYSIWYG coding environment. |
| 20:54 | <astearns> | WYSIWYG editors could still display pt in the UI, but use a fontSizePx method |
| 20:55 | <Hixie> | annevk: any plans? |
| 20:55 | <AryehGregor> | astearns, assuming the authors of those editors know that 0.75px = 1pt. Which they probably won't. Why make them? |
| 20:55 | <annevk> | Hixie, so far the only request has been streaming "downloads" |
| 20:55 | <AryehGregor> | Make the API work for the common case, and let authors translate to the uncommon case. |
| 20:55 | <Hixie> | annevk: ah, interesting. |
| 20:56 | <Hixie> | annevk: is it something that could be added if use cases were presented, or is xhr unlikely to change again? |
| 20:56 | <annevk> | Hixie, I guess we might enhance XHR some more |
| 20:57 | <Hixie> | annevk: k, thanks |
| 20:57 | <astearns> | all of the hand-coded CSS advice I've read lately encourages people to use px (if they want to use an absolute size). Adding new APIs in points seems retrograde to me |
| 20:57 | <annevk> | gonna get some sleep now |
| 20:57 | <AryehGregor> | astearns, this is not about hand-coded CSS. It's an API to auto-generate CSS. |
| 20:57 | <AryehGregor> | Typically, the CSS won't ever be viewed by a person. |
| 20:58 | <AryehGregor> | Also, "I read advice lately that encourages using px" is not itself a very compelling argument. |
| 20:58 | AryehGregor | wonders why EC2 Windows instances take 15-30 minutes after startup to generate a password that actually lets you log in |
| 20:59 | AryehGregor | also wonders why he has to enter a private key to get the password |
| 20:59 | <AryehGregor> | I mean, a) I don't see what attack scenario that averts, and b) isn't the whole point of public-key cryptography that you never have to give out your key to anyone? |
| 21:00 | <TabAtkins> | That seems completely broken. |
| 21:00 | <AryehGregor> | It's a private key from a keypair they generated, so it doesn't bother me much. |
| 21:00 | <AryehGregor> | But it seems pretty dumb. |
| 21:01 | <AryehGregor> | I assume that a Linux instance would just allow login directly with the private key. |
| 21:01 | <AryehGregor> | (without disclosing it, obviously) |
| 21:04 | <gsnedders> | Yay, and so Hotmail makes it practically impossible for us to drop another non-standard feature (currentStyle), as the codepath we end up on is one they don't officially support, so if we break anything on it due to dropping a non-standard feature, we simply break the site. They won't fix it. :\ |
| 21:04 | <Hixie> | noooo where did anne go |
| 21:05 | <TabAtkins> | Probably dead. |
| 21:06 | <wilhelm> | Last seen drinking beer in a restaurant near the office. Yeah, probably dead. |
| 21:46 | <AryehGregor> | So there's no way to get the latest IE10 preview except installing a Windows 8 VM? |
| 21:46 | <AryehGregor> | Which probably will not work on an AWS VM? |
| 21:46 | <Hixie> | this appears to be the case |
| 21:47 | <AryehGregor> | PP2 is no longer available? |
| 21:47 | AryehGregor | grumbles |
| 21:48 | <Hixie> | so you can get a beta of firefox, 30MB or so and runs on the spot, or you can download IE10, 1.5GB or so, needs its own partition and several reboots, and won't run side-by-side with any of your other browsers. |
| 21:49 | <Hixie> | as you might guess, I'm not spending as much time testing IE these days |
| 21:49 | <AryehGregor> | IE9 works fine in a VM. |
| 21:49 | <Hixie> | yeah that's how i test it |
| 21:49 | <Hixie> | (remote VM, but same idea) |
| 21:49 | <AryehGregor> | Also, is there some MS Office free crippled version that I can use for testing on my VM? Otherwise maybe I'll have to not test it. |
| 21:50 | <AryehGregor> | (I'm using a remote VM too, EC2) |
| 21:50 | <AryehGregor> | (costs me $3/month for the storage plus $0.03/hour for using it) |
| 21:51 | <AryehGregor> | I wish I could use less storage. 20G of that 30G is unused. |
| 21:52 | <AryehGregor> | But savings of $1.50/month is not worth trying to see if I can shrink the Windows root partition while the system is running. |
| 21:52 | <AryehGregor> | I've done that on Linux, mind you! It was fun. And this was without LVM or md or anything fancy, or with any extra devices. It was basically something like everything on /dev/sda1, which took up all of /dev/sda, with no other disks. |
| 21:53 | <AryehGregor> | (the solution involved copying essential files to a tmpfs, pivot_root, and then killing or restarting any processes using the old root partition so I could unmount it) |
| 21:54 | <AryehGregor> | But somehow I doubt Windows is capable of such things. |
| 21:54 | <AryehGregor> | <3 Linux |
| 22:17 | <zcorpan> | Hixie: "+ <p>Here, a a column" |
| 22:31 | <zcorpan> | http://smus.com/game-asset-loader - feedback on appcache |
| 23:21 | <Hixie> | ok i think i have multipart/x-mixed-replace specced for regular browsing contexts |
| 23:21 | <Hixie> | now for images |
| 23:23 | <Hixie> | holy cow, bfcache works better for the html spec in firefox than chrome, that's for sure |
| 23:27 | <abarth> | Hixie: chrome doesn't have a bfcache |
| 23:27 | <Hixie> | ah well that explains it |
| 23:34 | <mkanat> | Yeah, it makes me sad. |
| 23:34 | <mkanat> | There's one in WebKit but it hasn't been hooked into Chrome yet. |
| 23:34 | <abarth> | i've wanted to implement it for a while, but I haven't gotten around to it |
| 23:35 | <abarth> | its non-trivial to get right |
| 23:35 | <mkanat> | Yeah, I can totally imagine. |
| 23:37 | <Hixie> | especially in a multiprocess architecture, i imagine |
| 23:37 | <mkanat> | Oh yeah, I suppose you have to have a bfcache for each process. |
| 23:37 | <abarth> | mkanat: and do process-process back navigations |
| 23:38 | <abarth> | sorry |
| 23:38 | <abarth> | cross-process |
| 23:38 | <mkanat> | abarth: There are times when back/forward crosses process boundaries? |
| 23:38 | <abarth> | yes, often |
| 23:38 | <abarth> | we refresh the process whenever we can |
| 23:38 | <gavin> | can you not at least do fastback for same-process navigation? |
| 23:39 | <mkanat> | gavin: I'd imagine that would be an inconsistent and confusing user experience. |
| 23:39 | <mkanat> | gavin: Particularly if developers came to rely on it. |
| 23:39 | <gavin> | huh? |
| 23:40 | <mkanat> | gavin: There have been times when I've greatly wanted to rely on the bfcache in Firefox for fixing back/forward bugs. |
| 23:40 | <gavin> | "going back is sometimes fast" shouldn't really be confusing to users, it's not like there's much consistency there |
| 23:40 | <mkanat> | gavin: That's true, since bfcache is already like that. |
| 23:41 | <Hixie> | the spec allows bfcache to blow away the stored documents whenever |
| 23:41 | <Hixie> | pages that depend on them not going away are going to break left right and center |
| 23:41 | <mkanat> | Yeah. |
| 23:41 | <mkanat> | I actually wish that didn't happen; about 75% of JS bug effort on the developer side nowadays seem to be around dealing with the Back button. |
| 23:42 | <gavin> | "JS bug effort on the developer side" ? |
| 23:42 | <mkanat> | gavin: In terms of work that you have to do if you want to render an app that does go to different URLs, but while it's on the page, alters the DOM with JS in some way. |
| 23:42 | <gavin> | just in general? |
| 23:42 | <mkanat> | gavin: Yeah, in general. |
| 23:42 | <gavin> | ok... |
| 23:42 | <Hixie> | jsut store the state with pushState or replaceState |
| 23:42 | <Hixie> | it's not _that_ hard |
| 23:43 | <mkanat> | Hixie: Provided that your page can rebuild itself from a URL string, yes. |
| 23:43 | <Hixie> | or a state object |
| 23:43 | <mkanat> | Hixie: Although that means that any DOM manipulation you do, you must then also implement a system for rebuilding it from the URL. |
| 23:43 | <Hixie> | well you should do that anyway |
| 23:43 | <mkanat> | Hixie: Only if that state object can be serialized into the URL, no? Or you mean like in localStorage. |
| 23:43 | <Hixie> | for bookmarking purposes |
| 23:44 | <Hixie> | the state object can be anything that can be structured-cloned |
| 23:44 | <mkanat> | Hixie: Yeah, thankfully the last time I hit this, replaceState did fix it (for the browsers that implement replaceState). |
| 23:44 | <Hixie> | (think of it as "anything like JSON) |
| 23:44 | <Hixie> | ^" |
| 23:44 | <Hixie> | anyone know of a multipart/x-mixed-replace image anywhere? |
| 23:45 | <mkanat> | No, although I'd imagine it would be fairly easy to set up. |
| 23:45 | <Hixie> | i'm lazy :-P |
| 23:45 | Hixie | uses his multipart/x-mixed-replace kitchen to make one |
| 23:46 | <Hixie> | (http://www.hixie.ch/tests/evil/page-loading/multipart/001.cgi) |
| 23:47 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1159 doesn't work in firefox :-( |
