| 00:04 | <zewt> | (can't tell if joking) |
| 00:06 | <Philip`> | (Depends if he meant IE8 was being a boat anchor, or XHTML was being a boat anchor) |
| 00:06 | <Philip`> | (I suggest throwing them both off a boat and seeing which sinks fastest) |
| 00:29 | <zewt> | (can't tell if joking about lack of XHTML actually being a problem that needed to be solved) |
| 01:35 | <Yuhong> | IE8 being a boat anchor. It for example also do not support much of DOM level 2, which is why jQuery 2.0 won't support it. |
| 06:30 | <roc> | on the same day WaSP declares "our work here is done", we have a Chrome ad from Disney saying "a Web experience built for Chrome" |
| 06:33 | <tantek> | roc: Wasp has been fairly inactive for a while |
| 06:33 | <tantek> | Declaring a boom does not deny the fact that you went out with a whimper. |
| 10:38 | <hsivonen> | annevk: is there value other than encoding table and test case savings in dropping single-byte encodings whose lower half is ASCII and upper half has no overlap with ASCII? |
| 10:39 | <annevk> | hsivonen: very limited value |
| 10:40 | <hsivonen> | hmm. Warner now allows HD movies in iTunes on Mac. |
| 10:41 | <annevk> | hsivonen: we can add ibm850 back I suppose |
| 10:42 | <hsivonen> | annevk: what other single-byte encodings did we drop? random Mac stuff? |
| 10:42 | <hsivonen> | http://www.voddler.com/en/movie/info/2798385737197326461/skyfall/ |
| 10:42 | <annevk> | hsivonen: I haven't kept track |
| 10:42 | <hsivonen> | Voddler advertises Skyfall available for HTML5 streaming |
| 10:42 | <annevk> | hsivonen: or was not cc'd, either way |
| 10:42 | <hsivonen> | I wonder what HTML5 streaming means |
| 10:43 | <hsivonen> | can't be EME at this point in time |
| 10:43 | <odinho> | I called what I did HTML5 streaming, that was Ogg Theora + Vorbis. :-) |
| 10:43 | <hsivonen> | their payment service is down, so I couldn't pay 3.70 euros to check |
| 10:44 | <hsivonen> | annevk: does IE support IBM850? (I'm guessing yes, but didn't launch a VM to check) |
| 10:45 | <gsnedders> | That's like 3/4rds the cost of it in Norway. :( |
| 10:46 | <annevk> | hsivonen: http://wiki.whatwg.org/wiki/Web_Encodings suggests it does |
| 10:51 | <annevk> | hsivonen: I'm not really sure what the right approach here is. Should we add an encoding per report we get? |
| 10:52 | <annevk> | hsivonen: given one report it's prolly likely other pages are affected and definitely other users. |
| 10:52 | <annevk> | hsivonen: then the next question is what set of labels we add. The same as IE or what we had before? |
| 10:52 | annevk | does not like encodings |
| 10:54 | <gsnedders> | You chose to work on it! |
| 10:54 | <annevk> | gsnedders: yes, to make it a solved problem |
| 10:57 | <mounir> | annevk: you don't like encodings but you have two huge books on that subject on your desk... ;) |
| 11:01 | <annevk> | Yeah, they'll be moving to the public bookshelf soon. I haven't opened them in a while now... |
| 11:01 | <annevk> | Although I guess I should ask MikeSmith about the CJKV one as technically it's from Keio... |
| 11:07 | <hsivonen> | annevk: the stuff we only supported with uninteroperable labels might not be worth putting back |
| 11:07 | <hsivonen> | annevk: single-byte encodings that IE supports with sane labels *might* be worth putting back |
| 11:09 | <hsivonen> | I'm really quite surprised that someone uses the old DOS Western European encoding on the Web |
| 11:09 | <annevk> | hsivonen: on a site with login, no less |
| 11:09 | <annevk> | hsivonen: with a copyright statement amended for 2012 |
| 11:09 | <darobin> | I'm not |
| 11:09 | <annevk> | good for you |
| 11:10 | <darobin> | plenty of people have really old legacy systems, and those tend to spill over |
| 11:10 | <darobin> | "we have this really old machine that handles our inventory, we've managed to put an FTP server in front of its daily exports, can you take that and put it on the web" is a relatively common request |
| 11:11 | <darobin> | what happens with the encodings there then really depends on the developer... which means you see horrors |
| 11:12 | darobin | still remembers "it does strange things when our Chinese customers add new entries imported into our system" bug reports |
| 11:14 | <MikeSmith> | annevk: that CJKV book didn't belong to Keio, I don't think. It think it belonged personally to Felix Sasaki, and he gave it to me when he left W3C and moved back to Germany. So feel free to do whatever you want with it. |
| 11:15 | <annevk> | MikeSmith: my idea was to put it in Mozilla's community area |
| 11:15 | <jgraham> | Not to set fire to it? |
| 11:15 | <annevk> | MikeSmith: we have a public bookshelf there, but since there's no security someone might take it (but then hopefully they'll read it) |
| 11:15 | <jgraham> | Using the medieval adage "a problem enflamed is a problem solved"? |
| 11:16 | <hsivonen> | darobin: apparently wind energy is so old that it's old enough to have a DOS-era legacy system |
| 11:16 | <annevk> | jgraham: there's electronic copies :-( |
| 11:20 | <MikeSmith> | annevk: yeah if you're not needing it yourself any more, seems like it'd be good to put it out there for others to if. If somebody's so keen on it to take it home, that wouldn't be a tragedy |
| 11:20 | <hsivonen> | MikeSmith: another person entangled in legacy encodings not a tragedy? |
| 11:21 | <MikeSmith> | heh |
| 11:22 | <MikeSmith> | I just had to throw away at least 50 books at Keio becausethe office is going to be remodeled and we don't have room for them. I wish somebody had cared enough about any of them to already have walked off with them. |
| 11:22 | <MikeSmith> | some of them were pretty old, though. Like, a guide to the Korn shell. |
| 11:23 | <annevk> | next time mail them to this office, seems we have some space left |
| 11:59 | <annevk> | what's the negation of the first two bullet points under 1. in http://www.w3.org/TR/2013/CR-cors-20130129/#cross-origin-request-with-preflight-0 |
| 11:59 | <annevk> | boolean logic :( |
| 12:01 | <annevk> | NOT(true OR true) == false AND false |
| 12:02 | <jgraham> | annevk: Can't really tell where the brackets are in those sentences anyway |
| 12:02 | <annevk> | but this is NOT(true OR true AND true) so false AND false OR false |
| 12:03 | <jgraham> | annevk: More brackets, please |
| 12:03 | <annevk> | jgraham: why not? |
| 12:03 | <jgraham> | Is it X OR (Y AND Z) or (X OR Y) AND Z |
| 12:03 | <annevk> | AND has precedence no? |
| 12:04 | <Ms2ger> | Not if you want to be clear :) |
| 12:04 | <annevk> | I'm open to rewriting this even more though |
| 12:04 | annevk | wonders how |
| 12:04 | <jgraham> | In English? It's unclear. In other cases there might be rules |
| 12:04 | <annevk> | If ... |
| 12:05 | <annevk> | * there's no method cache match |
| 12:05 | <annevk> | * it's no simple method or the force preflight flag is set |
| 12:05 | <jgraham> | !(X OR (Y AND Z)) = !X & !(Y AND Z) = !X & (!Y OR !Z) |
| 12:06 | <jgraham> | Which is what you said |
| 12:06 | <annevk> | * for every header in request headers there is no cache match and the field name is not a simple header |
| 12:06 | <annevk> | Then ... preflight time |
| 12:06 | <annevk> | jgraham: does what I just wrote work? |
| 12:07 | <annevk> | (but it's wrong :-(, it only has to fail for one header) |
| 12:07 | <jgraham> | I'll go with no then :) |
| 12:07 | <annevk> | There's at least one header in request headers for which there is no cache match and which is not a simple header |
| 12:07 | <jgraham> | But the style is better |
| 12:07 | <annevk> | jgraham: try again |
| 12:07 | <jgraham> | (lunch) |
| 12:08 | <annevk> | so lame |
| 12:08 | <annevk> | and late for Sweden |
| 12:08 | <gsnedders> | It's jgraham. |
| 12:09 | <gsnedders> | It's early for him. |
| 12:15 | <annevk> | Great success: http://www.iwanttouse.com/#apng,download |
| 12:55 | <jgraham> | Using no specific features |
| 12:55 | <jgraham> | reaches 95.43% of web users |
| 12:56 | jgraham | wonders what the other 4.57% are doing |
| 12:56 | <Ms2ger> | Amaya |
| 12:57 | <jgraham> | darobin is almost 5% of web traffic? |
| 13:12 | <hsivonen> | jgraham: did you figure out what that meant? |
| 13:12 | <hsivonen> | some "other" browser unspecific matter? |
| 13:13 | <jgraham> | hsivonen: I suspect it means that 4.57% of users are using browsers that aren't covered by caniuse.com data |
| 13:13 | <jgraham> | Although that seems *very* high |
| 13:30 | <darobin> | maybe their UA data includes bots |
| 13:30 | <darobin> | (by mistake) |
| 13:30 | <jgraham> | Seems to be from statcounter |
| 13:30 | <jgraham> | Can't really tell how one would get anything useful out of that |
| 13:36 | <annevk> | jgraham: oh it says that now? I had it at 0 |
| 13:37 | <gsnedders> | Is that not ~% of "other" on statcounter? |
| 13:37 | <jgraham> | http://caniuse.com/usage_table.php |
| 13:38 | <jgraham> | Still doesn't add up to 100% |
| 13:50 | <SimonSapin> | jgraham: did you count "Browsers not included on site" ? |
| 13:51 | <jgraham> | Yes |
| 13:52 | <SimonSapin> | I get 99.925, could be rounding errors |
| 13:52 | <jgraham> | 0.865 + 3.38 + 95.68 = 99.925 |
| 13:53 | <jgraham> | Could be if the top number is only accurate to +- 0.005, I suppose |
| 13:54 | <SimonSapin> | or if each of these three values is a sum of rounded values, errors accumulate |
| 13:54 | <gsnedders> | Yay floats! |
| 13:57 | <jgraham> | Not floats at all |
| 13:57 | <jgraham> | Just propogation of errors |
| 13:57 | <jgraham> | There are 65 values that are +/- 0.0005 and 12 values that are apparently +/- 0.05 |
| 13:58 | <jgraham> | er 0.005 |
| 14:00 | <jgraham> | (and iirc you can just add in quadrature) |
| 14:09 | <annevk> | Which task source does WebSocket use? The protocol that is? |
| 14:12 | <jgraham> | "The task source for all tasks queued in this section is the WebSocket task source." |
| 14:15 | <annevk> | ta |
| 14:16 | <annevk> | So is the networking task source the exclusive domain of "fetch"? |
| 14:16 | <annevk> | Sounds like we should have named it the fetch task source... |
| 14:17 | <zewt> | does it even do anything, except to say "you don't have to guarantee task ordering with anything else"? |
| 14:18 | <annevk> | I think that's the main purpose. Which may mean XMLHttpRequest has a bug as it does not use the networking task source but should probably piggyback on that somehow... |
| 14:24 | <annevk> | My main problem at the moment is that I don't really have a good interface for return this asynchronously... HTML has this text about queuing tasks, but that does not work for a number of cases... |
| 14:24 | <hsivonen> | I wonder if Google has done browser stats internally across all sites that use Google Analytics |
| 14:25 | <annevk> | Namely: upload progress events, preflight request done. Maybe something else? |
| 14:25 | <annevk> | Did we decide on when upload progress events are done? Is it when you get an ACK from the server? |
| 14:26 | <annevk> | Is that even how TCP/IP works? |
| 14:26 | <zewt> | annevk: are you basically looking for a way to write callbacks in a spec? |
| 14:26 | <gsnedders> | annevk: It's a violation of layering, but yes, it's the only way to do it. |
| 14:26 | <annevk> | zewt: kind of |
| 14:26 | <zewt> | gsnedders: no, there are different approaches |
| 14:27 | <zewt> | well |
| 14:27 | <annevk> | zewt: except that if some flag is set there are no callbacks and it becomes a return value |
| 14:27 | <zewt> | i guess that's basically what it amounts to either way i'm thinking of |
| 14:27 | <zewt> | typically i look at the available buffer space on the socket, and figure out when it's emptied past what I want (but that's basically going to follow ACKs too) |
| 14:27 | <annevk> | gsnedders: we can also wait for a full HTTP response which may be what Gecko is doing |
| 14:28 | <annevk> | gsnedders: and depending on the status code dispatch either load or error or some such |
| 14:28 | <zewt> | annevk: that sounds like it breaks the point of upload progress events entirely |
| 14:28 | <zewt> | i mean, if you wait for the response, you're not firing upload progress *during the upload* at all, and that's the whole point ... right? |
| 14:28 | <gsnedders> | annevk: I think we shouldn't define it. Not really that nice to depend on things the TCP layer in the OS does… |
| 14:29 | <annevk> | zewt: mainly worrying about the final set of events |
| 14:29 | <jgraham> | hsivonen: It would be astonishing if they didn't |
| 14:29 | <gsnedders> | annevk: Like, I think when you dispatch them during upload cannot be practically defined in such a way it can be implemented on all OSes. |
| 14:29 | <annevk> | gsnedders: we tried that, didn't work |
| 14:29 | <zewt> | i don't think it makes sense to wait any longer than the 200 OK, and maybe not even that long |
| 14:30 | <annevk> | zewt: in practice there's not going to be much difference between that and the full set of headers as I understand it, but sure |
| 14:30 | <zewt> | (if the server has a long delay while it figures out the answer to your upload, seems like upload should still be considered finished right away) |
| 14:30 | <annevk> | None of this is really helping me unfortunately :-( |
| 14:30 | <gsnedders> | Right, I think we have to have a minimum set of number to send (like at completion), but can send more? |
| 14:30 | <gsnedders> | Or annevk, that not work? |
| 14:31 | <zewt> | but "wait for a full HTTP response" sounds very wrong (then you're waiting for the response body, too) |
| 14:31 | <annevk> | zewt: oh sorry, not for the body, just long enough to see if you're gonna redirect |
| 14:31 | <zewt> | annevk: lacking more specific questions I can only throw darts :P |
| 14:32 | <annevk> | Maybe I should put my sketch up somewhere |
| 14:32 | <annevk> | http://html5.org/temp/fetch.html |
| 14:33 | <zewt> | also it might help to know what the "becomes a return value" case is about (sounds like sync/async, but my first impression would be to do both with callbacks) |
| 14:33 | <annevk> | It hasn't run through Anolis yet so it's quite ugly |
| 14:33 | <annevk> | Basically "fetch" is the entry point, which might invoke some other algorithms asynchronously (or synchronously if the synchronous flag is set) |
| 14:34 | <zewt> | i mean, if you want a synchronous caller to fetch to be able to get the same info about what's happening (callbacks) as an async one |
| 14:35 | <annevk> | I guess I can keep the model where the other algorithms simply return the response to "fetch" which returns it in the end. And they also all queue tasks on the networking task source... |
| 14:35 | <annevk> | The latter model would be used by asynchronous invokers, the other model by synchronous... |
| 14:37 | <zewt> | so, "notify caller that preflight succeeded..." is a callbacky case |
| 14:37 | <annevk> | It still leaves some questions. E.g. how to queue tasks if we don't know yet it'll be a redirect. |
| 14:39 | <zewt> | could that be simply "invoke *preflight succeeded callback*, if set", make that an optional parameter to set, then let the caller sort out what to do with it (eg. queueing a task if it's async) |
| 14:39 | <zewt> | er, optional parameter to fetch (propagated down to this algorithm) |
| 14:41 | <annevk> | Actually, if we do this right we don't need that callback I think. |
| 14:41 | <zewt> | then since it's the caller queueing any tasks, fetch doesn't have to care (eg. if websocket or XHR use a different task source) |
| 14:42 | <zewt> | are you thinking of having progress events be fired by fetch? |
| 14:42 | <annevk> | XHR checks for "preflight complete" but "fetch" can handle that logic perfectly as it knows what is a preflight and what is not |
| 14:42 | <zewt> | (iirc they're not very uniform across apis...) |
| 14:43 | <annevk> | zewt: not the actual firing, but queueing tasks that make them possible |
| 14:43 | <zewt> | that's what this callback is, right? |
| 14:43 | <zewt> | (i don't care particularly about this callback, it's just the first callback i saw) |
| 14:44 | <annevk> | This callback is kinda pointless. It just indicates that the upload events start when the body is being transmitted, which will always be after the preflight anyway... |
| 14:44 | <annevk> | So I think I could remove that from XHR entirely and it would in effect say the same thing... |
| 14:45 | <zewt> | afk a bit |
| 14:45 | <annevk> | HTML has these callbacks for fetch today: tasks queued while receiving the entity body for incremental display of images. The final task at the end of fetch. |
| 14:48 | <annevk> | For XHR I need upload. I also want to clarify somehow that networking tasks should start when we know it's not a redirect. So basically when the entity body is being transferred... |
| 14:48 | <annevk> | But maybe we need more granularity for certain APIs... |
| 14:50 | <annevk> | I need Hixie |
| 15:21 | <annevk> | marcosc: you're missing "HTTP" in hosted app |
| 15:21 | <marcosc> | annevk: true |
| 15:22 | <marcosc> | Added, thanks! |
| 15:22 | <annevk> | marcosc: though calilng a packaged app "web" seems like a stretch |
| 15:22 | <marcosc> | heh |
| 15:22 | <marcosc> | also true |
| 15:22 | <marcosc> | changed it to packaged app |
| 15:22 | <marcosc> | hosted web app is ok |
| 15:22 | <marcosc> | it still runs off http |
| 15:40 | <darobin> | Hixie: do you mind sharing the preprocessor for the stuff that's showing up under http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#parsing-the-sort-key step 5.2? |
| 15:42 | <Ms2ger> | Heh, neat |
| 15:42 | <darobin> | yeah, it's pretty neat |
| 15:42 | <Ms2ger> | And if it breaks you, all the better ;) |
| 15:43 | <darobin> | my sweet, sweet and belovèd Ms2ger. :-* |
| 15:44 | <zewt> | gaaah |
| 15:45 | <zewt> | i click the order search box on amazon, start typing, and I end up with my search text randomly inserted in the middle of "Title, Department, Recipient" |
| 15:45 | <zewt> | dear amazon: use @placeholder, you idiots |
| 15:47 | <darobin> | I get the impression that adding more powerful form stuff has only encouraged developers to be more stupid in how they handle forms |
| 15:48 | <zewt> | seems like a few people use @placeholder, and everyone else goes "good idea!! i can do that in javascript!" |
| 15:52 | <darobin> | yeah |
| 15:53 | <darobin> | the Twitter search form helpfully voids itself on load |
| 15:53 | <darobin> | it's always great when you type faster than it loads |
| 15:53 | <darobin> | which is, well, rather easy |
| 15:55 | <zewt> | symptoms of people testing on local networks |
| 16:32 | <annevk> | ooh, I was already wondering what that was when reading the diff |
| 16:32 | <annevk> | so that's post-processed |
| 16:35 | <MikeSmith> | yeah |
| 16:37 | <MikeSmith> | seems like something that could be re-purposed in other specs |
| 16:37 | <MikeSmith> | fetch? |
| 16:37 | <MikeSmith> | the tool I mean |
| 16:39 | <annevk> | I was talking about Hixie's case-switch thingie |
| 16:39 | <annevk> | for once, although I'd love to talk about Fetch more :p |
| 16:40 | <MikeSmith> | I meant since you've just started writing up Fetch, if you have state-machine algorithms in there, you could write them using this case-switch shorthand, then have the tool make it into words for you |
| 16:41 | <annevk> | oh sorry, not that much case-switch going on right now |
| 16:42 | <dglazkov> | good morning, Whatwg! |
| 16:42 | MikeSmith | pipes a Mark Watson message from his mutt into lynx -stdin so that you can tell which parts are his words and which parts are stuff he's quoting |
| 16:42 | MikeSmith | wishes Mark would write all his messages from his iPhone instead because those are a lot easier to read |
| 16:53 | <annevk> | So XHR dispatches loadstart, then readystatechange readystatechange and then progress events start? |
| 16:54 | <annevk> | that's prolly roughly what should be happening |
| 16:56 | <annevk> | zewt: gsnedders: it seems for upload progress events we resolved to fire loadend when the outgoing buffer is empty |
| 16:56 | <annevk> | zewt: gsnedders: and not wait for ACK or some kind of HTTP response |
| 16:56 | <annevk> | zewt: gsnedders: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0749.html |
| 18:20 | <annevk> | Hixie: reply to http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0024.html would be great, ta |
| 18:25 | <TabAtkins> | jgraham: Actually, I've pushed back on single-line comments in CSS until someone can demonstrate a low chance of breakage, particularly in minified stylesheets. |
| 18:26 | <annevk> | only allow them when a line starts with whitespace followed by // ? |
| 18:26 | <annevk> | but maybe that's not good enough for people |
| 18:28 | <TabAtkins> | Nah, people want them at the end of a line, after a property. |
| 18:38 | <GPHemsley> | I want the ability to comment properties out without having to go to the beginning and end of a file. |
| 18:38 | <GPHemsley> | s/file/line/ |
| 18:38 | <TabAtkins> | That's easy - just put any invalid property-name char at the beginning of the line. |
| 18:38 | <TabAtkins> | If you want, use // |
| 18:39 | <GPHemsley> | Yeah, I was thinking that might work |
| 18:39 | <TabAtkins> | That "comments it out" by invalidating the declaration, which causes the parser to swallow and ignore the entire declaration but no more. |
| 18:40 | <GPHemsley> | hmm... that could even work for inline styles, huh? |
| 18:40 | <TabAtkins> | Yup. |
| 18:40 | <GPHemsley> | interesting |
| 18:40 | <GPHemsley> | I wonder if that should be documented/reminded somewhere? |
| 18:40 | <TabAtkins> | The annoying part is that if you want to put a comment *after* a declaration, using // will eat the *next* declaration instead. |
| 18:41 | <GPHemsley> | right |
| 18:41 | <GPHemsley> | what if you end your comment in a semicolon? |
| 18:41 | <TabAtkins> | That'll work. |
| 18:42 | <GPHemsley> | hmm |
| 18:42 | <TabAtkins> | That doesn't help with comments between blocks, though. There you'd need to end the comment with a {}, I think. |
| 18:42 | <TabAtkins> | Though... maybe not. Let me test. |
| 18:43 | <TabAtkins> | No, you definitely need a {}, because the parser thinks it's in the selector for a style rule. |
| 18:44 | <TabAtkins> | So, as long as you're commenting inside of a block, you can do "// <comment here>;" and it'll work. |
| 18:44 | <TabAtkins> | Outside of a block, just use block comments. |
| 18:45 | <GPHemsley> | that sounds fair |
| 18:45 | <TabAtkins> | That might actually be useful to document. |
| 18:45 | <TabAtkins> | There's a thread waiting on some conclusions about this - I'll bring it up there. |
| 18:45 | <GPHemsley> | Blocks require block comments. That's easy to rememeber. |
| 18:46 | <GPHemsley> | Perhaps even explicitly reserve the '//' property for comments? |
| 18:46 | <GPHemsley> | (IDK how that works.) |
| 18:46 | <TabAtkins> | Properties already can't be named // anyway - they're restricted to idents. |
| 18:47 | <GPHemsley> | Hmm... by that logic, then, you could also use #, right? |
| 18:47 | <TabAtkins> | Yup. |
| 18:47 | <TabAtkins> | Anything and everything that's not a valid property name. |
| 18:47 | <GPHemsley> | right |
| 20:09 | <Hixie> | any blog admins around? |
| 20:14 | <JonathanNeal> | i have a blog |
| 20:14 | <Hixie> | i meant the whatwg blog |
| 20:14 | <Hixie> | sorry :-) |
| 20:22 | <jgraham> | I have an admin (but not for the WHATWG blog) |
| 20:22 | <jgraham> | (I think) |
| 20:37 | <GPHemsley> | a wiki could be used as a blog... does that count? ;) |
| 21:02 | <zewt> | line comments that don't actually work anywhere sound unpleasant |
| 22:01 | <jgraham> | MikeSmith: Hej, at some point when you have a moment it would be awesome if you could look and see if there are any serverside errors that look like they correspond to what Ken's seeing? |
| 22:01 | <jgraham> | Hmm, that wasn't actually a question |
| 22:01 | <jgraham> | s/\?/./ perhaps |
| 22:03 | <jgraham> | It is pretty non-obvious to me why it would work for me and for you (most of the time) but never for him, unless it is something on his local network |
| 22:03 | <jgraham> | But still |
| 22:24 | <annevk> | Hixie: you around? |
| 22:25 | <annevk> | Hixie: my first question was about <img> does fetch, then another <img> does a fetch, both queue network tasks, how do you know which task is for which image? |
| 22:25 | <Hixie> | why would you not know? |
| 22:25 | <Hixie> | that's like saying you put a ball on the ground, i put a ball on the ground, how do you know which ball was put down by whom |
| 22:32 | <annevk> | Hixie: there's nothing in the task queue design that tells you these things |
| 22:33 | <zewt> | annevk: "the buffer is empty" implies the ACK is received, by definition |
| 22:34 | <annevk> | Hixie: as for tasks for uploading, don't you need to signify from the network layer that something is happening and then have the API layer expose that? |
| 22:41 | <annevk> | zewt: k |
| 22:52 | <Yuhong> | Ah, the WaSP. |
| 22:53 | <Yuhong> | That is the one that petitioned Netscape to cancel Mariner, leaving Netscape nothing to compete in time for IE5. |
| 22:53 | <Yuhong> | Which ended up increasing the use of document.all. |
| 22:54 | <Yuhong> | To the point other browsers had to implement it! |
| 22:55 | <Yuhong> | And yea, Mariner was going to implement getElementById too. |
| 22:55 | <tantek> | but not CSS |
| 22:56 | <tantek> | which was just a wee bit more important than getElementById |
| 22:56 | <Yuhong> | Netscape 4 implemented CSS but poorly, Netscape 5 was going to implement CSS better. |
| 22:56 | <tantek> | "poorly" is being generous |
| 22:57 | <tantek> | "better" than "poorly" was nowhere near good enough |
| 22:57 | <tantek> | (in comparison to what everybody else was coding support for) |
| 22:59 | <Yuhong> | If I was going to fix CSS support in NS4, I'd consider instead of depending on the JS parser, to have the CSS parser directly call the JSSS functions. |
| 22:59 | <tantek> | lol |
| 22:59 | <tantek> | except for that whole CSS suddenly disappearing when JS was turned off problem ;) |
| 23:00 | <annevk> | Hixie: I think those are basically my questions |
| 23:00 | <annevk> | Hixie: and maybe how to queue tasks on the networking task force specifically for cases such as "transmitting entity body", "headers are processed", "receiving entity body", ... and then how the API hooks into those |
| 23:01 | <annevk> | Hixie: it all feels a bit handwavy at the moment and in fact XHR has somewhat differing requirements as to when to dispatch progress events :-( |
| 23:01 | <annevk> | Hixie: if the fetching model was perfectly clear, none of that would be problematic |
| 23:04 | <Yuhong> | To be honest, the CSS spec wasn't all that good either. |
| 23:04 | <tantek> | a few of us managed to make it work ;) |
| 23:04 | <Yuhong> | hsivonen mentioned in retrospect the CSS spec should have been changed to match browsers instead of quirks and standards mode. |
| 23:05 | <Hixie> | annevk: re upload, nothing i've done does anything on upload as far as i know, so i haven't done anything with that |
| 23:06 | <tantek> | browsers didn't agree - so there was no such thing as "changed to match browsers" |
| 23:06 | <Hixie> | annevk: but sure, if you want to do something that depends on network buffers emptying or something, then sure, tasks for that makes sense |
| 23:06 | <annevk> | tantek: the table quirk is pretty much agreed upon now |
| 23:06 | <Hixie> | annevk: i don't really understand the other question though. do you have a concrete example of what's ambiguous? |
| 23:06 | <tantek> | yes, now. |
| 23:06 | <Yuhong> | Yes, but they did agree on one thing that deviated from the CSS standards (box model). |
| 23:07 | <tantek> | but not in 1999/2000 |
| 23:07 | <tantek> | yuhong - nah - depended on which element |
| 23:07 | <tantek> | browsers themselves (especially NS) were inconsistent |
| 23:07 | <annevk> | Hixie: e.g. how many tasks does XHR use to change from OPENED to HEADERS_RECEIVED to LOADING to DONE assuming there's no response entity body? |
| 23:09 | <annevk> | Hixie: I think the browser networking model uses three tasks for that, but there's nothing really currently that requires that in fetch |
| 23:09 | <annevk> | Hixie: you could have a single task for the entire response |
| 23:09 | <jamesr> | is there a web observable behavior difference? |
| 23:09 | <zewt> | annevk: does it matter? ^ |
| 23:10 | <jamesr> | could you ever tell if a browser was using 1 task or using 3 separate tasks and just choosing to service the tasks from the networking task source back to back? |
| 23:10 | <zewt> | i suppose if they're in separate tasks, then it's not guaranteed that nothing can happen between them, where if (in that case) they always use one task, it is |
| 23:11 | <jamesr> | it could, but since it's a separate task source it's up to the browser whether anything else happens in between or not |
| 23:11 | <jamesr> | since the browser can pick which task source to service at any point in time |
| 23:11 | <Yuhong> | Now I realize that even versioning as a buzzword don't make sense. |
| 23:11 | <annevk> | jamesr: I'm not sure if there's an observable difference |
| 23:11 | <jamesr> | annevk, then why do you care? |
| 23:11 | <zewt> | jamesr: right, but if they're in a single task, then they're *required* to ensure nothing else happens in between; in separate tasks, they can choose to do so or not to |
| 23:11 | <Hixie> | annevk: well yeah. you could be receiving one byte per TCP packet, or you could get the whole GB all at once with the OS only telling you once it's buffered the whole thing, there's no way to say which is going to happen |
| 23:12 | <jamesr> | zewt, very true. so the difference is if you want to require them be back-to-back or not |
| 23:12 | <jamesr> | i can't imagine why you would want to |
| 23:12 | <Hixie> | annevk: so the number of tasks is entirely arbitrary |
| 23:13 | <Yuhong> | MozillaZine's article on this: http://www.mozillazine.org/talkback.html?article=1708 |
| 23:13 | <zewt> | jamesr: well, if in common cases you can never sit blocked in some of those states on network activity (which I think is the case), then you might be able to get more deterministic behavior |
| 23:14 | <zewt> | eg. annevk: weren't you noting that it's impossible to actually sit in HEADERS_RECEIVED, since you always go right to LOADING (or something along those lines)? |
| 23:14 | <annevk> | jamesr: I care because a) I don't know and b) XHR is currently somewhat unclear as to whether you could skip certain states because of this |
| 23:14 | <annevk> | zewt: I was, but I might have been incorrect if the fetching layer actually does distinguish that case and queues a separate task for it (as XHR expects) |
| 23:15 | <zewt> | right, but if in reality browsers do run those states atomically, then it might make sense to require it be in a single task |
| 23:16 | <zewt> | (no clue if they do or not) |
| 23:16 | <zewt> | probably a tough thing to test, too... |
| 23:16 | <zewt> | could depend on buffer sizes, etc |
| 23:16 | <jamesr> | so you suspect there are cases where the spec could be more exact, but you aren't sure if that matches implementation's behavior? |
| 23:17 | <annevk> | jamesr: no, I think the spec might be incorrect in certain cases because it expects an order that's not necessarily given |
| 23:18 | <jamesr> | have an example? |
| 23:18 | <zewt> | sorry, lost you a bit--what ordering isn't given? |
| 23:18 | <annevk> | jamesr: http://xhr.spec.whatwg.org/#same-origin-request-event-rules will be used exactly once if there was only ever one networking task |
| 23:18 | <annevk> | jamesr: which basically falls flat |
| 23:19 | <zewt> | actually i don't really know what this section means |
| 23:20 | <zewt> | what does "While making the request also follow the same-origin request event rules."? when are these "rules" triggered? |
| 23:20 | <zewt> | maybe this is tied to language in fetch that I'm just not familiar with |
| 23:21 | <Yuhong> | From http://blogs.msdn.com/b/ieinternals/archive/2011/03/23/understanding-local-machine-zone-lockdown-restricted-this-webpage-from-running-scripts-or-activex-controls.aspx |
| 23:21 | <annevk> | no it's vague and I want to fix it |
| 23:21 | <annevk> | in part by getting the answer as to whether fetch should give explicit callbacks for these situations or not |
| 23:22 | <zewt> | while i'm not the one you want an answer from, i expect the answer is yes :) |
| 23:22 | <Yuhong> | About the IE team citra early 2004 when no real work was done on the rendering engine itself: "But it's understandable, at the time, I believe the IE team was under a dozen brave souls, and boy were they busy.]" |
| 23:23 | <annevk> | Hixie: would it work to queue tasks on the networking task source with certain hints associated with them? |
| 23:23 | <annevk> | Hixie: e.g. "upload task", "headers in the bag task", "receiving some entity task", ... |
| 23:24 | <Yuhong> | As I mentioned before, even later on it took until XHTML and DOM Level 2 was more than *10* years old for IE to finally implement them. |
| 23:24 | <zewt> | annevk: personally I wouldn't queue tasks, just take algorithm-callbacks by name and invoke them |
| 23:25 | <zewt> | if the user (eg. xhr) wants them to happen in some task, then queue a task from there |
| 23:25 | <Yuhong> | And by then, XP was in extended support, and thus MS did not release IE9 for them, making IE8 the new Netscape 4. |
| 23:25 | <annevk> | Hixie doesn't want to change the model and HTML uses tasks for this all over |
| 23:25 | <zewt> | (for XHR, it might want them in the XHR's personal task source, rather than networking) |
| 23:26 | <annevk> | We can make the task source configurable, sure |
| 23:26 | <zewt> | annevk: don't need to change the model from HTTP's point of view; just wrap the algorithm if needed and you'll get the same result |
| 23:26 | <Yuhong> | Why does jQuery 2.0 not support IE8? |
| 23:27 | <annevk> | zewt: that sounds hacky |
| 23:27 | <Yuhong> | In fact, what changed in IE7 and IE8 is pretty small compared to what changed in IE9. |
| 23:27 | <zewt> | not sure |
| 23:28 | <annevk> | anyway, bedtime |
| 23:28 | <zewt> | don't think it's hacky (it's just like any compatibility shim in an API), but dunno if it's right, either |
| 23:32 | <Yuhong> | And BTW mutation events reminds me of win32k user mode callbacks. |
| 23:33 | <Yuhong> | http://www.mista.nu/research/mandt-win32k-paper.pdf |
| 23:35 | <Yuhong> | With IE10 not implementing mutation observers, I wonder if browsers will ever be able to remove it. |
| 23:35 | <Yuhong> | *mutation events. |
| 23:39 | <Yuhong> | BTW, the quirks vs standards mode is mentioned in http://www.w3.org/wiki/Evolution/Versions |
| 23:40 | <Yuhong> | I am thinking of using CSS box model as an example. |
| 23:40 | <Yuhong> | When I finally begin to edit the wiki. |
| 23:47 | <Hixie> | anne: don't understand what this is for |