| 00:01 | <sicking> | Hixie, so there's one problem |
| 00:01 | <Hixie> | what happens if the underlying file goes away? |
| 00:01 | <sicking> | there's that too |
| 00:01 | <sicking> | but |
| 00:02 | <sicking> | Hixie, storing files means doing IO on the main thread |
| 00:02 | <sicking> | Hixie, something that we're trying not to do |
| 00:02 | <sicking> | Hixie, hmm.. actually |
| 00:02 | <Hixie> | Storage is async to disk |
| 00:02 | <Hixie> | it's only sync to RAM |
| 00:03 | <sicking> | not sure that sqlite is able to do it that way |
| 00:03 | <sicking> | didn't sound like it |
| 00:03 | <Hixie> | oh, you use sqlite as the backend? interesting |
| 00:04 | <sicking> | but actually the File object is just a reference, we wouldn't need to read the actual data, so I think it's fine |
| 00:04 | <sicking> | ImageData is another cup of tea though, since it has sync accessors |
| 00:05 | <sicking> | But File should be fine |
| 00:09 | <sicking> | so sounds like we're fine with everything but ImageData |
| 00:10 | <Hixie> | how do you handle ImageData with postMessage()? |
| 00:10 | <sicking> | maybe we can create a way to convert File to/from ImageData to allow people to store ImageData |
| 00:10 | <sicking> | we don't |
| 00:10 | <sicking> | for postMessage we only do JSON right now |
| 00:10 | <sicking> | and only to workers |
| 00:11 | <Hixie> | let me rephrase... how do you intend to handle ImageData with postMessage()? :-) |
| 00:11 | <sicking> | not sure if anyone was aware of it until a few days ago when i looked at the structured clone spec |
| 00:11 | <Hixie> | ah |
| 00:11 | <sicking> | also all the postMessage we have today are wholly in-memory |
| 00:12 | <sicking> | so no IO problems |
| 00:12 | <Hixie> | there's a strong desire from people to be able to do heavy-duty image manipulation on background workers |
| 00:12 | <sicking> | agreed |
| 00:12 | <Hixie> | and i figure once you work out a way to do ImageData cloning efficiently with postMessage(), you can just use the same technique for Storage |
| 00:13 | <sicking> | it's not the cloning part that's the problem. It's the storing it to disk |
| 00:13 | <sicking> | which you don't need for postMessage |
| 00:13 | <sicking> | but do need for pushState/localStorage |
| 00:13 | <Hixie> | can't you just keep the ImageData in RAM, give it a unique ID, store a unique ID to the database, and then in the background store the image data to a separate table with that ID? |
| 00:14 | <sicking> | not when reading |
| 00:14 | <Hixie> | i mean it's not trivial, but it doesn't seem that hard |
| 00:14 | <Hixie> | oh, reading is interesting, yes |
| 00:14 | <Hixie> | hmm |
| 00:14 | <sicking> | btw, i expect apple to feel the same way on this |
| 00:14 | <Hixie> | yeah reading ImageData from disk is a problem |
| 00:14 | <Hixie> | no disgreement there |
| 00:14 | <Hixie> | hmm |
| 00:15 | <sicking> | a possibility is to have two types of structured-clone |
| 00:15 | <sicking> | one for postMessage and one for other things |
| 00:15 | <sicking> | sort of sucks though |
| 00:15 | <Hixie> | so pushState() isn't a problem here, because the popstate event is async |
| 00:16 | <sicking> | sort of yeah, though i'd be a little worried about poor UI if the popstate event is delayed by a long time |
| 00:16 | <Hixie> | i'll make Storage fail if it contains an ImageData object, for now, until we can figure out some solution |
| 00:17 | <sicking> | sounds good |
| 00:17 | <sicking> | i'm not sure how much of structured clone we'll do for next release |
| 00:17 | <sicking> | we might just stick to JSON |
| 00:17 | <Hixie> | yeah well all of this is rather pie in the sky, i'll be the first to admit |
| 00:17 | <sicking> | as we're basically branching any day for FF3.6 |
| 00:17 | <sicking> | hah |
| 00:17 | <Hixie> | i don't expect this stuff in browsers any time soon |
| 00:18 | <Hixie> | should it throw or convert to null when you pass it an ImageData? (DOM nodes and raw CanvasPixelArrays convert to null) |
| 00:18 | <Hixie> | (Error objects and loops throw) |
| 00:19 | <sicking> | hmm.. what's the reason not to throw for DOM nodes and other host objects? |
| 00:19 | <Hixie> | i think that was so that we could support it later |
| 00:19 | <Hixie> | which would argue for this to convert to null |
| 00:20 | <sicking> | ah, hm |
| 00:20 | sicking | ponders |
| 00:20 | <Hixie> | the idea being that one day people would postMessage something like { 'text version of the data', DOMNodeOfTheData } |
| 00:20 | <Hixie> | and the worker would look at the DOM node and say "oh that's null, must be an old browser, i'll use the text" |
| 00:20 | <Hixie> | instead of the script having to test and resend just text |
| 00:20 | <sicking> | not sure which is best actually |
| 00:21 | <Hixie> | not really sure. i really need a minion to note down the reasoning behind every checkin :-) |
| 00:21 | <sicking> | given that it might be slow to get the text version |
| 00:21 | <sicking> | maybe i'm thinking too much about perf though |
| 00:21 | <Hixie> | this is onl ever used in situations where perf sucks anyway |
| 00:21 | <Hixie> | cross-thread, I/O, etc |
| 00:21 | <sicking> | i guess there's some truth to that |
| 00:22 | <sicking> | not sure if we'll ever do DOM nodes though |
| 00:22 | <Hixie> | yeah |
| 00:22 | <sicking> | given how much of them can't be serialized |
| 00:22 | <Hixie> | me either |
| 00:22 | <Hixie> | i guess i'll throw for ImageData for now. |
| 00:22 | <Hixie> | it's easier to spec. :-) |
| 00:22 | <Hixie> | we can work out whether to change the nulls to throwing later |
| 00:22 | <sicking> | heh |
| 00:23 | <sicking> | people can just convert ImageData to a JS object instead :) |
| 00:23 | <sicking> | { "0,0 |
| 00:23 | <Hixie> | that'll be even more painful performance-wise :-/ |
| 00:23 | <sicking> | ": [0, 255, 0], ... } |
| 00:24 | <sicking> | i know, just kidding. though i'm sure someone will do it |
| 00:24 | <sicking> | but as long as slow operations look slow then IMHO we're good |
| 00:24 | <Hixie> | yeah |
| 00:24 | <Hixie> | or at least if not good, not so bad |
| 00:24 | <sicking> | right |
| 00:25 | <sicking> | btw, did you test that IE executes DOM inserted scripts out-of-order? |
| 00:25 | <Hixie> | off-hand i have no idea |
| 00:25 | <sicking> | ok, testing now |
| 00:26 | <Hixie> | IE's script execution model is wacked |
| 00:26 | <Hixie> | (who would have thought innerHTML could affect it, e.g.) |
| 00:26 | <sicking> | i had a recollection that they executed scripts syncronously when you set .src |
| 00:26 | <Hixie> | i'm considering just making defer="" on <script> just be ignored, btw, and removing the crap around innerHTML |
| 00:26 | <sicking> | i think we should just use the Firefox model |
| 00:26 | <Hixie> | sicking: i'm sure whatever they do cannot be summarised in one sentence. |
| 00:27 | <sicking> | henris suggestion is basically what we do internally |
| 00:27 | <Hixie> | henri's suggestion scares me |
| 00:27 | <Hixie> | it makes the parsing even more complex in ways that are very subtle and hard to get right |
| 00:27 | <sicking> | it's not a huge deal implementation-wise |
| 00:27 | <sicking> | at least it wasn't for us |
| 00:27 | <Hixie> | you didn't have to follow a spec |
| 00:27 | <sicking> | just check if there are pending scripts when you reach the end of the stream |
| 00:27 | <Hixie> | what if i end up speccing something that is subtly different? |
| 00:28 | <sicking> | you already are :) |
| 00:28 | <Hixie> | i just hate the idea of being able to hit EOF multiple times |
| 00:28 | <sicking> | everywhere :) |
| 00:28 | <sicking> | no, just one EOF |
| 00:28 | <sicking> | but we'd remove the implication that end-of-stream => EOF |
| 00:28 | <sicking> | (network stream that is) |
| 00:31 | <Hixie> | that's just weird and confusing |
| 00:31 | <Hixie> | i'd have to have two different kinds of EOF tokens in the tokeniser? |
| 00:32 | <Hixie> | one for scripts and one for document.write()? |
| 00:32 | <Hixie> | er, document.close) |
| 00:32 | <Hixie> | ( |
| 00:35 | sicking | ponders |
| 00:37 | <sicking> | technically no |
| 00:37 | <sicking> | Any of these would work: |
| 00:37 | <sicking> | 1. Two types of EOF |
| 00:37 | <sicking> | 2. Allowing EOF to go through the tokenizer twice |
| 00:38 | <sicking> | 3. Start a new tokenizer after the first EOF |
| 00:38 | <Hixie> | you've just listed three of my worst nightmares |
| 00:38 | <sicking> | 4. Reset/Restart the same tokenizer after the first EOF |
| 00:38 | <Hixie> | four of my worst nightmares... |
| 00:38 | <sicking> | really? you have poor imagination ;) |
| 00:38 | <sicking> | the localStorage situation is much worse IMHO |
| 00:39 | <Hixie> | the storage mutex? |
| 00:39 | <sicking> | yeah |
| 00:39 | <sicking> | it's teh suxxorz |
| 00:39 | <Hixie> | yeah that's pretty horrific too |
| 00:39 | <Hixie> | but i don't see a way around it |
| 00:39 | <sicking> | and the general way that invalid markup is handled |
| 00:39 | <Hixie> | with the <script> thing, just not supporting <script defer> (no src) seems like a solution that solves the problems that were found |
| 00:40 | <sicking> | you sure there are no external scripts with defer that does .write? |
| 00:40 | <sicking> | i would certainly expect there to be |
| 00:40 | <Hixie> | if there are, they're highly unreliable in IE |
| 00:40 | <sicking> | how so? a .innerHTML flushes them |
| 00:41 | <Hixie> | .innerHTML throws them out altogether if they're not loaded yet |
| 00:41 | <sicking> | not in my testing |
| 00:41 | <Hixie> | you didn't test well enough |
| 00:41 | <Hixie> | :-) |
| 00:41 | <sicking> | well, i can give a testcase where it doesn't throw them out. So seems your testing isn't good enough :) |
| 00:41 | <sicking> | though maybe it only works locally? |
| 00:42 | <sicking> | i can test |
| 00:42 | <sicking> | once i've tested this out-of-order thing |
| 00:42 | <Hixie> | make sure it's not cached |
| 00:43 | <Hixie> | file:// is sync in IE, i think |
| 00:43 | <Hixie> | i'm trying to find my tests |
| 00:43 | <sicking> | it's not sync, but it might change things i agree |
| 00:46 | <Hixie> | http://www.hixie.ch/tests/adhoc/html/parsing/script-defer-write/ |
| 00:47 | <Hixie> | http://www.hixie.ch/tests/adhoc/html/parsing/script-defer-write/001.html in particular |
| 00:47 | <sicking> | why does http://www.hixie.ch/tests/adhoc/html/parsing/script-defer-write/fail.js give me an "internal error" page? |
| 00:47 | <Hixie> | cos i suck |
| 00:48 | <sicking> | as does reset.js |
| 00:48 | <Hixie> | try now |
| 00:48 | <sicking> | is there a delay on those? |
| 00:48 | <Hixie> | in IE, yes |
| 00:48 | <Hixie> | er |
| 00:48 | <Hixie> | yes |
| 00:49 | <Hixie> | every .js file in that directory takes 2 seconds to generate |
| 00:49 | <Hixie> | hm |
| 00:50 | <Hixie> | maybe my testing sucked |
| 00:50 | <Hixie> | no, it seems it was right |
| 00:51 | <sicking> | i mean, i'd love to not have to do this double-EOF thing |
| 00:51 | <Hixie> | compare http://www.hixie.ch/tests/adhoc/html/parsing/script-defer-write/001.html to http://www.hixie.ch/tests/adhoc/html/parsing/script-defer-write/008.html |
| 00:51 | <Hixie> | IE throws away the script on 001 |
| 00:51 | <Hixie> | and on 008 it wipes the document |
| 00:52 | <sicking> | yup |
| 00:52 | <sicking> | hum hum |
| 00:52 | <sicking> | well, lets put it in the spec |
| 00:53 | <sicking> | we'll find out when we try to implement it |
| 00:53 | <Hixie> | just removing defer="" with no src="", you mean? |
| 00:53 | <sicking> | so the plan is to ignore the 'defer' attribute on inline scripts, right? |
| 00:53 | <Hixie> | yeah |
| 00:53 | <sicking> | sounds good |
| 00:53 | <Hixie> | ok |
| 00:54 | <sicking> | i'll just have to fight you on the DOM-inserted scripts execution order... for now |
| 00:54 | <sicking> | and no magic at all on innerHTML, right? |
| 00:54 | <sicking> | no nuking of pending defered scripts a'la IE |
| 00:54 | <Hixie> | right |
| 00:55 | sicking | ponders |
| 00:56 | <sicking> | lets just hope that people don't come to depend on the FF3.5 behavior |
| 00:56 | <sicking> | of .write working in deferred async scripts |
| 01:01 | <Hixie> | ok, afk for a while. bbiab. |
| 02:46 | <Dashiva> | The thread about <script /> reminds me of when Opera was implementing canvas support |
| 02:46 | <Dashiva> | Lots of the early canvas content was of course using <canvas /> |
| 06:33 | <Hixie> | ok |
| 06:33 | <Hixie> | i've sent in the registrations for the two WebSocket ports, the two WebSocket schemes, and the WebSocket HTTP Upgrade keyword. |
| 06:33 | <Hixie> | what's next. |
| 06:34 | <Hixie> | MIME types: text/html; application/xhtml+xml; text/cache-manifest; text/event-stream; application/microdata+json |
| 06:34 | <Hixie> | i wonder how we register those |
| 06:39 | <othermaciej> | hey Hixie |
| 06:39 | <Hixie> | looks like http://www.w3.org/2002/06/registering-mediatype.html is how i do it |
| 06:39 | <Hixie> | hey othermaciej |
| 06:39 | <othermaciej> | do you think anyone in that HyBi group (or whatever it's called) is going to try to interfere with the WebSocket protocol? |
| 06:40 | <othermaciej> | (asking since it's under active implementation for both Chrome and Safari) |
| 06:40 | <Hixie> | i can almost guarantee that someone will try, yes |
| 06:40 | <sicking> | Hixie, do application/file too while you're at it. No idea if that'll fly though |
| 06:40 | <Hixie> | it's also under active implementation for gecko |
| 06:40 | <Hixie> | sicking: noted |
| 06:40 | <othermaciej> | I'm wondering how solid the commitment to "rough consensus and running code" will be |
| 06:40 | <sicking> | Hixie, might be worth posting to the HTMLWG about that one. Seems to be more people there with opinion on mimetypes |
| 06:41 | <othermaciej> | maybe should make sure interested implementors are on the committe |
| 06:41 | <sicking> | Hixie, not sure if dataTransfer.types really qualify as mimetypes though |
| 06:42 | <sicking> | othermaciej, btw, our plan is to land it preffed off for now I think |
| 06:42 | <Hixie> | othermaciej: did you see the recent stuff about BWTP? |
| 06:42 | <othermaciej> | Hixie: I saw a big flood of email, but I could not tell what it was or if I needed to care about it |
| 06:42 | <sicking> | othermaciej, in order to gather feedback but still be prepared to change implementation in case spec changes |
| 06:43 | <Hixie> | othermaciej: there was a recent e-mail (today i think) asking for review of BWTP |
| 06:43 | <Hixie> | othermaciej: my opinion is that BWTP is orders of magnitude more complex than we're looking for |
| 06:43 | <Hixie> | othermaciej: but obviously if the browser vendors prefer it to the websocket approach, i'd be happy to just drop websockets in favour of BWTP |
| 06:44 | <sicking> | does it do multiplexit? It's the main feature i'm lacking from websocket |
| 06:44 | <Hixie> | yes |
| 06:44 | <Hixie> | http://bwtp.wikidot.com/main:rational |
| 06:44 | <Hixie> | http://bwtp.wikidot.com/main:proposal |
| 06:44 | <othermaciej> | sicking: we'll probably turn it on for testing on WebKit trunk, but I will suggest that maybe we should avoid anyone shipping it in production until the standards story is settled |
| 06:45 | <Hixie> | (i have no idea how it is proposed that BWTP work at the API level) |
| 06:45 | <othermaciej> | (though I think Safari and Chrome can still get away with shipping stuff without locking it in beyond changing, this API has little value til there is vendor consensus) |
| 06:45 | <othermaciej> | Hixie: I did just see the review request on whatwg@ |
| 06:46 | <othermaciej> | Hixie: I guess now would be a really good time to review it since the WebKit implementation is at a fairly early stage, but we've prototyped enough to have a picture of how the WebSocket protocol would work and what the likely issues are |
| 06:46 | <othermaciej> | I also really need to give File API a close reading now that Arun has posted the new draft he suggested I should wait for |
| 06:46 | <sicking> | actually, my main-main concern is getting through proxies |
| 06:46 | <othermaciej> | sicking: WebSocket's proxy story is fine, afaict |
| 06:47 | <othermaciej> | sicking: you just use CONNECT, and that works even on port 80 |
| 06:47 | <sicking> | othermaciej, apparently many proxies block CONNECT to non-443 ports |
| 06:47 | <sicking> | othermaciej, squid being one of them |
| 06:47 | <othermaciej> | sicking: Darin Fisher claimed otherwise to me |
| 06:47 | <roc> | I was told that by default Apache proxies block connect to ports other than 443 |
| 06:47 | <othermaciej> | or rather, that he deployed a product depending on this (Google Web Accelerator) and it was not an issue in practice |
| 06:47 | <othermaciej> | but I have not done anything to verify for myself |
| 06:48 | <roc> | Darin Fisher deployed Google Web Accelerator? |
| 06:48 | <othermaciej> | well, he works for Google |
| 06:48 | <othermaciej> | and that's what he worked on before Chrome |
| 06:48 | <othermaciej> | is what I mean |
| 06:48 | <roc> | urm |
| 06:48 | <Hixie> | there's not much you can do other than fall back to encrypted WebSocket over TLS if there's a proxy futzing with the connection or blocking anything but port 443 |
| 06:48 | <othermaciej> | and I don't even know if it was him personally |
| 06:49 | <sicking> | Hixie, technically you can probably do non-SSL to 443 as well |
| 06:49 | <Hixie> | sicking: yeah, indeed |
| 06:49 | <othermaciej> | anyway - I'm not sure if there is a good answer for non-443 if CONNECT won't fly |
| 06:49 | <sicking> | Hixie, but we might want to consider defaulting to 443 if this really is a problem |
| 06:49 | <Hixie> | in what sense? |
| 06:50 | <sicking> | othermaciej, indeed. Only thing i can think of is to default to port 443 |
| 06:50 | <Hixie> | surely you just use whatever port the author says to use |
| 06:50 | <sicking> | sure, but use 443 if no port was specified |
| 06:50 | <othermaciej> | non-SSL over 443 seems like a plausible way to avoid the problem for the non-SSL case I guess |
| 06:50 | <Hixie> | instead of 815? |
| 06:50 | <sicking> | right |
| 06:50 | <othermaciej> | I bet the IETF would have a cow over that |
| 06:50 | <Hixie> | the ietf would -- yeah exactly |
| 06:50 | <sicking> | yup :) |
| 06:50 | <sicking> | we can do it on an API level maybe :) |
| 06:51 | <Hixie> | i don't think it's a problem to have authors just throw :443 in there initially |
| 06:51 | <Hixie> | on the long run proxies will adapt |
| 06:51 | <roc> | personally I think it's ok to depend on TLS |
| 06:51 | <Hixie> | (very long run) |
| 06:51 | <roc> | I dunno, it looks like we'll *never* get HTTP pipelining to work |
| 06:51 | sicking | would love to put more pressure on crappy proxies. To solve pipelineing as well |
| 06:51 | <othermaciej> | roc, sicking: I guess I should ask Darin F to give more details as to why he thought CONNECT over port 80 is fine, and how he reconciles that with the squid and apache default config |
| 06:52 | <sicking> | roc, fennec ships with pipelineing turned on by default |
| 06:52 | roc | whistles |
| 06:52 | <othermaciej> | it's easier to get away with pipelining on mobile |
| 06:52 | <roc> | I guess that's a positive move, not because it proves pipelining works, but because it puts pressure on the proxy world |
| 06:53 | <sicking> | othermaciej, it'd be great to hear what darin has to say. cc me and jduell⊙mc, and roc if he wants to |
| 06:53 | <othermaciej> | because carrier proxies are more reliably (and testably!) sane than random intranet proxies |
| 06:53 | <Hixie> | cc me, too, if you send mail about websocket |
| 06:53 | <sicking> | othermaciej, and wfernandom2004⊙gc since he's the one writing our impl |
| 06:54 | <othermaciej> | I'll Cc if I end up asking by email, or email results if I end up asking more directly |
| 06:54 | <sicking> | sounds great |
| 06:54 | <sicking> | roc, exactly |
| 06:54 | <sicking> | roc, apparently Operas approach is to simply try it, and when it fails re-do the GET |
| 06:54 | <roc> | I thought the problem was that we couldn't detect failure reliably |
| 06:55 | <sicking> | roc, which sounds to me like it's not *that* common that it fails given how bad re-doing GET could be |
| 06:55 | <roc> | gotta run |
| 07:16 | <hsivonen> | othermaciej: relying on namespace-unaware APIs pretty much means it's less likely that browser engine developers would bother supporting RDFa natively, since it would need RDFa-specific hacks on thee c`++ side |
| 07:17 | <hsivonen> | seems like a bad idea to desin language features that are known to be unfriendly to browser-internal interfaces |
| 07:17 | <othermaciej> | hsivonen: I'm sure as heck not going to try to implement native RDFa using namespace-unaware DOM APIs in C++... |
| 07:17 | <othermaciej> | otoh there is not much demand right now for browser-native RDFa implementation in general |
| 07:22 | <othermaciej> | Hixie: it looks a fair bit more complicated than WebSocket - hard to tell which of the extra fluff is genuinely beneficial |
| 07:25 | <othermaciej> | seems like nearly all of it could be done at the application level with WS, it is not clear how many of the features give serious benefit from native support in the protocol |
| 07:31 | <hsivonen> | Hixie, sicking: just one HTML5 EOF needed. but the emptying of the parser's internal buffer doesn't automatically mean EOF |
| 07:33 | <hsivonen> | Hixie: I think making script execution block on network sucks horribly compared to what I suggested about deferring EOF emission based on pending scripts |
| 07:33 | <sicking> | hsivonen, if we go with the gecko solution, you still need to send something through the tokenizer in order to get it to end the current token though, right? |
| 07:33 | <sicking> | hsivonen, i think a better solution is to remove support for defer on inline scripts though |
| 07:34 | <sicking> | hsivonen, if we do that then document.write might not be a problem any more |
| 07:34 | <sicking> | hsivonen, given how weirdly document.write in deferred external scripts work in IE |
| 07:37 | <hsivonen> | sicking: if there's a partial tag token, it gets killed anyway, but getting deferred EOF right when the off-the-main-thread tokenizer has a partial comment pending would suck |
| 07:37 | <hsivonen> | yeah, removing defer on inline scripts makes sense |
| 07:37 | <sicking> | i might be able to get that landed tomorrow |
| 07:38 | <sicking> | if so we'd be able to get feedback on this in the 3.6 cycle |
| 07:38 | <hsivonen> | great |
| 07:43 | <hsivonen> | Hixie: I certainly don't want the tokenizer to process EOF more than once. I want to have the decision to push the EOF to the tokenizer in the IO driver |
| 07:43 | <hsivonen> | Hixie: that doesn't exist in the spec but that is highly useful |
| 08:19 | <hsivonen> | http://lists.w3.org/Archives/Member/w3c-html-wg/1997JulSep/0387.html |
| 08:47 | <Lachy> | hsivonen, 1997-09-12 seems to be the date that summary first appeared in an HTML4 editor's draft. http://www.w3.org/MarkUp/Group/9709/WD-html40-970912/struct/tables.html#h-12.1.1 |
| 08:47 | <Lachy> | http://lists.w3.org/Archives/Member/w3c-html-wg/1997JulSep/0675.html |
| 08:49 | <Lachy> | but there appears to have been absolutely no public discussion of it |
| 09:01 | <Hixie> | sicking: application/file is wrong, but i think we can probably just make the type be "files" or something like that (without a slash) |
| 09:07 | <hsivonen> | Lachy: I was able to find no discussion at all. |
| 09:08 | <Lachy> | I couldn't either |
| 09:08 | <hsivonen> | which leaves 3 options: unminuted voice discussion, discussion on a WAI list that I didn't search or an editor putting it in without discussion |
| 09:09 | <hsivonen> | anyway, considering how little it was discussed on the record, the current attachment to it is rather disproportionate |
| 09:10 | <hsivonen> | of course, it's possible that the greatest hits get created by accident :-) |
| 09:13 | <Lachy> | I'm sure it isn't the first time a feature was added to HTML4 without any discussion |
| 09:19 | <hsivonen> | Hixie: seen https://bugzilla.mozilla.org/show_bug.cgi?id=508075 ? |
| 09:20 | <Hixie> | i have now |
| 09:21 | <hsivonen> | Hixie: any opinion? |
| 09:21 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/199 |
| 09:21 | <Hixie> | we're not doing reparsing. |
| 09:23 | <hsivonen> | Hixie: hmm. indeed, that case suggests that WebKit reparses |
| 09:24 | <Hixie> | wtf does "interoperability considerations" mean in a mime type registration |
| 09:24 | <Hixie> | should i put "implementors are encouraged to implement the damn spec exactly as written"? |
| 09:24 | <hsivonen> | hehe |
| 09:25 | <hsivonen> | surely there's an RFC defining the procedure? |
| 09:25 | <Hixie> | that would be http://www.ietf.org/rfc/rfc4288.txt |
| 09:25 | <Hixie> | please point to the section of that RFC that defines wtf "interoperability considerations" are |
| 09:26 | <Lachy> | Hixie, why was the Storage interface changed to accept structured data instead of just DOMStrings? |
| 09:26 | <Hixie> | Lachy: to allow File objects to be stored |
| 09:26 | <gsnedders|work> | Hixie: See in 4.5 |
| 09:26 | <Hixie> | gsnedders|work: what does that section mean? |
| 09:27 | <gsnedders|work> | Hixie: I guess problems with interoperability with the specification of current implementations? |
| 09:27 | <Hixie> | i have to list all the bugs? |
| 09:27 | <hsivonen> | Hixie: 4.5 implies the considerations are a list of known bugs |
| 09:27 | <Hixie> | if so, i think i can push out last call another year or two |
| 09:27 | <Hixie> | i could just link to the bugzillas |
| 09:27 | <Lachy> | Hixie, do you mean these objects? http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html |
| 09:28 | <hsivonen> | Hixie: Just link to bugzilla |
| 09:28 | <Hixie> | Lachy: yes |
| 09:28 | <hsivonen> | s |
| 09:29 | <Hixie> | t? |
| 09:29 | <gsnedders|work> | Hixie: http://www.rfc-editor.org/rfc/rfc5577.txt is one of teh latest RFCs to be published with a media type registration |
| 09:30 | <gsnedders|work> | Hixie: Which does nothing like what was said above |
| 09:30 | <Hixie> | good times |
| 09:32 | <Hixie> | i'd like to point out that the MIME type registration procedures still haven't caught up with apple's UTI work |
| 09:35 | <gsnedders|work> | UTI? |
| 09:35 | <hsivonen> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=504941 is alarming and sad |
| 09:35 | <Hixie> | hsivonen: yup |
| 09:35 | <Hixie> | hsivonen: unsurprising, though |
| 09:36 | <hsivonen> | I wonder whose idea it was to add support for that case to IE or Netscape in the first place... |
| 09:36 | <hsivonen> | not that it matters anymore |
| 09:37 | <gsnedders|work> | I guess it's more likely Netscape or Mosaic |
| 09:38 | <hsivonen> | maybe I should go read the Netscape 5 HTML parser some time |
| 09:38 | <hsivonen> | I expect it to be rather ad hoc |
| 09:40 | <hsivonen> | does Acid3 exist as individual test cases? |
| 09:43 | <hsivonen> | what was the trick for seeing the Acid3 error console? |
| 09:45 | <Hixie> | click the A |
| 09:45 | <Hixie> | or shift click or something |
| 09:46 | Hixie | blinks at the idea of writing a "security considerations" section for text/html |
| 09:47 | <hsivonen> | whoa. acid3 test #71 fails for an interesting reason: Test 71 failed: doc.open is not a function |
| 09:50 | <hsivonen> | Hixie: thanks. Is there a .zip for easily testing and editing Acid3 locally? |
| 09:50 | <Hixie> | try acid3.acidtests.org/acid3-2009-06-19.tar.gz |
| 09:51 | <hsivonen> | Hixie: thanks |
| 09:52 | <hsivonen> | wow. AFP doesn't pass Acid3 |
| 09:52 | <hsivonen> | tar: support-a.png.404: Cannot hard link to `support-c.png': Operation not supported |
| 09:52 | <Hixie> | AFP? |
| 09:52 | <hsivonen> | Hixie: Apple Filing Protocol |
| 09:53 | <Hixie> | hah |
| 09:54 | <gsnedders|work> | Hixie: Why are some of your old adhoc tests so evil? :P |
| 09:54 | <MadAtWork> | I'd say: "It's a dirty job but someone has to do it" |
| 10:14 | <gsnedders|work> | hsivonen: What version of OS X/AFP? Hard links are supported with Leopard as client and server, AFAIK |
| 10:16 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#iana-considerations |
| 10:26 | <hsivonen> | gsnedders|work: Leopard client. ReadyNAS server. |
| 10:27 | <gsnedders|work> | hsivonen: I guess no server support, and I guess it uses something based on Netatalk, which doesn't support it |
| 10:27 | <gsnedders|work> | (Hardlinks are the reason TM requires a Leopard server for AFP) |
| 10:28 | <Philip`> | Why does it show the status annotation box for "#the-marquee-element-0" in the margin when I'm looking at #iana-considerations? |
| 10:28 | <hsivonen> | I wanted to use NFS, but the NFS mounts on Leopard die often and randomly |
| 10:30 | <Philip`> | Hixie: "Cache manifests begin with the US-ASCII string ..." - no they don't, they begin with a UTF-8 string |
| 10:31 | <hsivonen> | what does Change Controller mean? |
| 10:32 | <hsivonen> | Hixie: looks good |
| 10:32 | <hsivonen> | when a W3C document supercedes an RFC for registration, how does this appear on tools.ietf.org? |
| 10:33 | <hsivonen> | Do you also need to submit a short RFC that points to the W3C doc? |
| 10:34 | hsivonen | isn't aware of the details of the IETF—W3C collaboration arrangement |
| 10:35 | <Hixie> | Philip`: "CACHE MANIFEST" is a US-ASCII string |
| 10:35 | <Hixie> | hsivonen: no idea about the answers to your questions |
| 10:41 | <Hixie> | ok, i've filled in the remaining MIME type registration sections |
| 10:42 | <MadAtWork> | Hixie: will the october deadline be met |
| 10:42 | <MadAtWork> | ? |
| 10:43 | <Hixie> | by whom? |
| 10:43 | <Philip`> | Hixie: It seems unnecessarily confusing to talk about substrings in one character encoding in a document with a different character encoding |
| 10:43 | <MadAtWork> | You I guess. |
| 10:43 | <Hixie> | i am on track to get the spec ready for last call by october, yes. |
| 10:44 | <MadAtWork> | Sweet. |
| 10:44 | <Hixie> | Philip`: fixed |
| 10:51 | <Hixie> | anyone (annevk2?) want to volunteer to register all the IANA encoding synonyms we've learnt about? |
| 10:51 | <Hixie> | i'm worried that i'll burn out if i have to push through any more of these registrations |
| 10:51 | <Hixie> | i'm already up to 9 |
| 11:00 | <Hixie> | nn |
| 11:00 | <Hixie> | (someone volunteer while i'm sleeping!) |
| 14:41 | <mwic> | hey guys, i'm playing w/HTML 5 and my video tag works great on localhost, but on my (A2Hosting) public host it prompts download... where do I start? |
| 14:44 | <hsivonen> | mwic: check your server's mime type config for .ogg, .ogv and .oga |
| 14:44 | <hsivonen> | should be application/ogg, video/ogg and audio/ogg |
| 14:46 | <mwic> | well, this is a budget host; is that something i could likely edit in .htaccess? Or should i use a different (dedicated) machine for this? |
| 14:47 | <hsivonen> | mwic: .htaccess should be enough |
| 14:47 | <rubys> | look here for examples of AddType: http://search.cpan.org/~lds/Apache-MP3-4.00/MP3.pm |
| 14:48 | <rubys> | (use the mime types hsivonen suggested instead though) |
| 14:48 | <hsivonen> | AddType application/ogg ogg |
| 14:48 | <hsivonen> | AddType video/ogg ogv |
| 14:48 | <hsivonen> | AddType audio/ogg oga |
| 14:49 | <rubys> | http://www.0xdeadbeef.com/weblog/?p=1159 |
| 14:50 | hsivonen | isn't a fan of ogv, oga and ogx |
| 14:50 | <hsivonen> | esp. when XiphQT still output .ogg instead of .ogv |
| 14:50 | rubys | notes that Apple isn't a fan of ogg <ducks/> |
| 14:52 | <annevk2> | rubys, they're looking into it it seems |
| 14:52 | <annevk2> | Hixie, maybe when I feel better :/ |
| 14:52 | <hsivonen> | what container and audio does Flash accept for VP6 video? |
| 14:52 | <rubys> | you have new news on this? That would be most excellent! |
| 14:53 | <annevk2> | rubys, did you see the emails from Maciej to the theora list? |
| 14:53 | <annevk2> | that's what I meant |
| 14:53 | <rubys> | no |
| 14:53 | <rubys> | url? |
| 14:53 | <annevk2> | hmm |
| 14:54 | <rubys> | http://lists.xiph.org/pipermail/theora/2009-July/002415.html ? |
| 14:54 | <annevk2> | yeah |
| 14:55 | <rubys> | I'm also intrigued by http://www.betanews.com/article/Future-of-open-Web-video-may-change-with-Google-acquisition-of-On2/1249481107 |
| 14:55 | <hsivonen> | flv and MP3? |
| 14:56 | <annevk2> | rubys, I think everyone is, too bad there will be no details until Q4 |
| 14:56 | annevk2 | goes back to doing nothing |
| 14:57 | hsivonen | can think of 3 reasons for Google acquiring On2 |
| 14:57 | gsnedders|work | was asked whether annevk2 was around at the moment |
| 14:57 | <gsnedders|work> | earlier |
| 14:57 | gsnedders|work | guesses the answer is yes, then :P |
| 14:57 | <mwic> | :( hsivonen i added those lines and no improvement |
| 14:58 | <rubys> | is the url on your host public? |
| 14:58 | <gsnedders|work> | "if the first letter is in fact a digit" — surely that never applies, as it isn't the first letter if it's a digit! |
| 14:59 | rubys | points at the topic |
| 14:59 | <mwic> | rubys, if you mean me yes, and as it turns out the public one works |
| 15:00 | <mwic> | http://thislandok.twoclick.org/ |
| 15:00 | <gsnedders|work> | rubys: CSS doesn't claim to be illogical though |
| 15:01 | <mwic> | i was using a /etc/hosts entry to access the same site, and it still fails there.. wonder why |
| 15:01 | <hsivonen> | mwic: works for me in Minefield |
| 15:01 | <hsivonen> | mwic: maybe you fixed the problem but have the old versions cached |
| 15:02 | <hsivonen> | mwic: updating the mime types doesn't properly update cache controls in apache |
| 15:02 | <hsivonen> | that is, if the resources are cacheable and you change the server config, apache behaves as if the resources didn't change |
| 15:02 | <mwic> | hm |
| 15:02 | <hsivonen> | s/resources/resource representations/ |
| 15:04 | <mwic> | yep, looks like cached junk.. accessing on a different machine worked great |
| 15:04 | <mwic> | thxmuch |
| 17:07 | <Lachy> | http://arstechnica.com/open-source/news/2009/08/webgl-standard-to-bring-3d-web-without-browser-plugins.ars |
| 17:08 | <Philip`> | Old news :-p |
| 17:09 | <Lachy> | it's only a day old, and I didn't notice it yesterday |
| 17:11 | <Philip`> | http://www.khronos.org/news/press/releases/khronos-webgl-initiative-hardware-accelerated-3d-graphics-internet/ - three days |
| 17:29 | <Lachy> | did you really know about it 3 days ago though? |
| 17:30 | <Philip`> | Yes |
| 17:30 | <MadAtWork> | Prove it. |
| 17:30 | <MadAtWork> | (Sorry, couldn't resist a pathos dense situation) |
| 17:31 | <Lachy> | MadAtWork, what is a pathos dense situation? |
| 17:31 | <Philip`> | Actually four - http://krijnhoetmer.nl/irc-logs/whatwg/20090803#l-872 |
| 17:50 | <MadAtWork> | One with a large amount of pathos in a small space? |
| 17:50 | <Philip`> | It could equally well be a small amount of pathos in a tiny space |
| 17:51 | <MadAtWork> | Yes. Or a gargantuan amount of pathos in a very large space. |
| 18:03 | <Dashiva> | This one made me smile: "The big difference is that for the web you only have 2 strings while TCP/IP has an infinite number of 16 bit integers." |
| 19:47 | <ezyang> | I think something's fishy with the infinite loop fix. |
| 19:48 | <ezyang> | Namely, "in select" insertion mode, "If the stack of open elements does not have an element in table scope with the same tag name as the token, ignore the token." |
| 19:48 | <ezyang> | Shouldn't that be checking for a "select" in table context? |
| 19:49 | <ezyang> | Actually, I'm not sure what to think |
| 19:49 | <ezyang> | At the very least, <input> is an input element, so it should never be "in scope" |
| 19:51 | <ezyang> | s/input element/empty element/ |
| 19:53 | <ezyang> | Also, I generally see the "If the stack of open elements does not have an element in table scope with the same tag name as the token" talisman when a close tag is encountered... |
| 20:15 | <Hixie> | ezyang: yeah gsnedders|work already sent a mail saying it was buggy |
| 20:15 | <ezyang> | savvy |
| 20:15 | <ezyang> | I think the fix might be just to replace "current token" with "select" |
| 20:16 | <Hixie> | i'll look at it when i get to his e-mail |
| 20:16 | <Hixie> | probably a week or so |
| 20:16 | <ezyang> | :-) |
| 20:19 | <virtuelv> | Hixie: yt? |
| 20:19 | <Hixie> | yes |
| 20:19 | <virtuelv> | I've got a question re http://www.hixie.ch/tests/evil/mixed/lineheight3.html |
| 20:20 | <virtuelv> | the first test pattern actually has grey lines between glyphs in all browsers I've tested in |
| 20:20 | <virtuelv> | is the correct rendering dependent on having anti-aliasing disabled, or are these genuine bugs? |
| 20:21 | <Hixie> | it's a very minor bug with the antialiasing code |
| 20:22 | <virtuelv> | how? |
| 20:22 | <virtuelv> | (Enforcing anti-aliasing to happenn in some specific way, on a subpixel level is dangerous, patent-wise, fwiw) |
| 20:22 | <Hixie> | how what? |
| 20:23 | <virtuelv> | I'm wondering how one can consider different anti-aliasing in different implementations to be a bug |
| 20:23 | <Hixie> | that's not what i'm considering a bug |
| 20:24 | <Hixie> | the bug is that if you have two exactly square glyphs exactly aligned horizontally and vertically with no space between them, you shouldn't see a seam |
| 20:24 | <Hixie> | that you don't see a seam horizontally but do see a seam vertically is a bug |
| 20:24 | <Hixie> | a very minor one |
| 20:24 | <Hixie> | but a bug nonetheless |
| 20:25 | <virtuelv> | ah |
| 20:25 | <virtuelv> | either way, when viewing the actual tests, browsers have far worse problems, I see |
| 20:26 | <Hixie> | yeah |
| 20:26 | <Hixie> | dunno how accurate that test is anymore |
| 20:26 | <Hixie> | i wasn't expecting to see errors |
| 20:31 | <virtuelv> | Yeah. I was just loading some random page to check if Ahem had been correctly installed |
| 20:58 | <Hixie> | o_O at larry's e-mail |
| 21:01 | <Philip`> | Clearly you're discriminating against people who don't have an email address |
| 21:01 | <Hixie> | actually those are discriminated against because of my policy of only being willing to pay for working group members |
| 21:01 | <Lachy> | what the hell? Would anyone seriously Hixie to be so unapproachable that sending him a private mail is simply out of the question? |
| 21:02 | <Hixie> | (since you have to have an e-mail address to join) |
| 21:02 | <Lachy> | s/seriously/seriously consider/ |
| 21:02 | <Lachy> | Philip`, Google has a postal address, I'm sure they'd accept snail mail :-) |
| 21:03 | <Hixie> | tis true |
| 21:03 | <Hixie> | c/o Ian Hickson; Google, Inc.; 1600 Amphitheatre Parkway; Mountain View 94043 CA; USA |
| 21:03 | Lachy | wonders if anyone has sent or will ever send HTML5 feedback by snail mail? |
| 21:04 | <Philip`> | Print a copy of the spec, highlight all the errors in red pen, then mail it to Hixie |
| 21:04 | <Hixie> | that's probably what microsoft'll do |
| 21:04 | <Hixie> | they like to print specs out |
| 21:04 | <Dashiva> | Don't forget to take a picture on a wooden table and scan it and stuff |
| 21:07 | <Hixie> | aw, sicking, i'm touched |
| 21:07 | <Hixie> | thanks for the support :-) |
| 21:17 | <Dashiva> | public-html is just teeming with good spirits and cooperation |
| 21:17 | <Dashiva> | enough to make even hardened veterans misty-eyed |
| 21:26 | <Hixie> | right, lunch |
| 21:35 | <syp_> | Hixie: hi, does the spec mentions if classList should work on non-HTML nodes? |
| 22:23 | <Xanthir> | Say I wanted to hack full support for, say, <input type=date> into a page via js. A non-supporting browser treats that to <input type=text>. Is there any way for me to stop this, or at least recognize that it was originally type=date? |
| 22:23 | <Lachy> | Hixie, looks like Microsoft did choose to send e-mail instead of snail mail after all. :-) |
| 22:28 | <Philip`> | Xanthir: Use getAttribute('type') to access the original DOM attribute value, perhaps? |
| 22:28 | <Xanthir> | Hmm, lemme try that. (Sorry, I pretty much avoided JS before jQuery, and so am mostly clueless when it comes to actually using the DOM APIs as written.) |
| 22:29 | <gsnedders> | DOM-- |
| 22:31 | <Xanthir> | Ooh, yes, that works well. |
| 22:32 | <Xanthir> | Now, next question. I know getters and setters are part of some level of ecma. Are they usable in any browser? |
| 22:33 | <Xanthir> | Nm - Resig answers this for me. |
| 22:33 | <Xanthir> | Answer: all latest browsers except IE. |
| 22:34 | <gsnedders> | IE8 supports them |
| 22:35 | <Xanthir> | Excellent. That blog post was a bit old. |
| 22:35 | <Xanthir> | That means I can write in proper support for the new inputs. |
| 22:36 | <Hixie> | syp_: it's only defined on HTML nodes; what happens on non-HTML nodes isn't in HTML's purview |
| 22:36 | <Philip`> | Xanthir: A script that implements HTML5 feature support in old non-supporting browsers would probably be much more useful if it supported IEs older than IE8 |
| 22:37 | <Xanthir> | Oh, indeed, but I can write a lesser form of support for those. Without setters I simply can't implement the html5 spec properly. |
| 22:37 | <Xanthir> | Also: this is for fun. There's already a webforms2 library around, though I have no idea how good it is. |
| 22:39 | <Philip`> | (I suppose there's also the issue that even if everyone used IE8, a large majority of pages will be processed with the IE7 engine instead) |
| 22:40 | <Xanthir> | True, but if you're using html5 features, you're probably going to make sure your page is read as ie8 as well as you can. |
| 22:41 | <Philip`> | I guess most people will be completely unaware of it, and will try using <input type=date> and a workaround script and it will fail and they'll have no idea why |
| 22:42 | <Philip`> | until someone tells them to change their doctype, and maybe unpress the compatibility button, and maybe remove themselves from the blacklist, and maybe fix their HTTP headers and meta elements |
| 22:42 | <Xanthir> | Well, it'll fail in that they can't play with the value properly. It'll still produce a datepicker and submit properly. |
| 22:59 | Xanthir | finds yet another thing that our SEO corp's outsourced programmers have done wrong, potentially screwing up our Google rankings. |
| 23:13 | <othermaciej> | Dashiva: well, other than Larry... |
| 23:18 | <annevk42> | that guy is a troll |
| 23:18 | <annevk42> | wtf was up with that email? |
| 23:19 | <othermaciej> | I'm trying to resist the urge to feed the troll |
| 23:20 | <annevk42> | another data point for http://krijnhoetmer.nl/irc-logs/whatwg/20090731#l-170 :) |
| 23:34 | <Hixie> | heycam: yt? |
| 23:36 | <Hixie> | heycam: web idl -- can you make 4.5.6. Host object [[Call]] method support overloaded "caller"s? |
| 23:36 | <Hixie> | heycam: specifically, for HTMLCollection i'd like to just put "caller" on both item() and namedItem() and just have the overloading functionality pick the right one based on whether the argument is a number or a string |