| 01:04 | <karlcow> | annevk: any reasons why doing `response.consumeBodyAsJSON()` instead of just `response.bodyAsJSON()`? |
| 01:05 | <karlcow> | doWhatHow() methods seem candidates for deprecation in the future. :/ |
| 01:06 | <karlcow> | compare to something like do(What, How). Bah… :) not important. |
| 01:06 | karlcow | is going back to webcompat issues |
| 02:04 | <karlcow> | annevk: also |
| 02:04 | <karlcow> | > If you have any great user interface ideas let me know! I thought I would share the above since I could not find a decent summary anywhere else. |
| 02:04 | <karlcow> | feedback request without a place to leave the feedback |
| 02:05 | <karlcow> | in http://annevankesteren.nl/2014/08/registerprotocolhandler |
| 07:30 | <zcorpan_> | karlcow: http://annevankesteren.nl/about |
| 07:30 | <karlcow> | heh |
| 07:31 | <zcorpan_> | though comments on the blog would be a bit more inviteful |
| 07:31 | <karlcow> | I was thinking more of an open bug :) |
| 07:32 | <karlcow> | weird English (as usual) |
| 07:32 | <karlcow> | anyway I was expecting a place where I could put a comment in a bug tracker. |
| 07:35 | <JakeA> | karlcow: because otherwise it isn't clear that it consumes the stream |
| 07:35 | <JakeA> | karlcow: (re consumeBodyAsJSON) |
| 07:36 | <karlcow> | JakeA: can it does something else than 'consuming the stream'? |
| 07:36 | karlcow | likes that btw 'consumes the stream'. There is something poetic about it |
| 07:38 | <JakeA> | karlcow: it could buffer the stream for further reads, then read the buffer as json |
| 07:38 | <JakeA> | karlcow: see http://jakearchibald.com/2014/reading-responses/ |
| 07:38 | <karlcow> | s/can it does/can it do/ (slow brain) |
| 07:38 | karlcow | clicks and reads |
| 07:46 | <karlcow> | hmmmm I see. |
| 07:47 | <annevk> | karlcow: I think the idea behind the explicit naming was because it was non-obvious what it would do |
| 07:48 | <annevk> | karlcow: I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1056860 |
| 07:48 | <karlcow> | oh cool |
| 07:48 | <karlcow> | thx |
| 08:00 | <zcorpan_> | krijnhoetmer_: is the irc log code on github or so? |
| 08:13 | <karlcow> | annevk, JakeA: so if I understood the post the response.consumeBodyAsJSON is a stream. |
| 08:13 | <karlcow> | then why not calling it what it means. response.streamAsJSON |
| 08:17 | <JakeA> | karlcow: nah, response.consumeBodyAsJSON() returns a promise for a JS object |
| 08:23 | <zcorpan_> | http://www.w3.org/mid/8AA87E45-6086-4CAD-8EC6-7BDE739F4DDC⊙gc #popcorn |
| 08:24 | <Ms2ger> | "There is no cost to working on longdesc." |
| 08:58 | <annevk> | "The only question is whether the W3C standard is going to reflect that practice or some imaginary universe concocted by the WHATWG's collective inexperience." |
| 08:58 | <annevk> | Roy is always happy to make friends it seems |
| 08:59 | <jgraham> | JakeA, annevk: So what's the reason that response.body.json() doesn't work? |
| 08:59 | <annevk> | jgraham: we want .body to be an actual stream object |
| 09:00 | <annevk> | jgraham: it could be a subclass, but taking short terms on that seems dangerous |
| 09:00 | <annevk> | jgraham: sorry for not explaining that on list |
| 09:00 | <jgraham> | You can't have response.body.stream? |
| 09:01 | <annevk> | jgraham: why would we have an extra object? |
| 09:01 | <jgraham> | having a mix of response.body and response.bodyAsJSON() seems ugly |
| 09:01 | <jgraham> | Plus the latter is harder to type :p |
| 09:01 | <annevk> | jgraham: having an additional object for each request/response seems wasteful |
| 09:02 | <jgraham> | (also I suspect that wanting to interact with the raw stream will not be the common use case) |
| 09:02 | <Ms2ger> | annevk, sounds like he's friends with the chairs |
| 09:02 | <jgraham> | (well maybe it will for SW, I don't know, but not for XHR-replacement use cases) |
| 09:02 | <annevk> | Ms2ger: they have said the same thing? |
| 09:02 | <Ms2ger> | Seems like the kind of tone they'd approve of |
| 09:03 | <annevk> | Ms2ger: thinking about it, if Roy actually believed what he wrote there, he would veto the whole document |
| 09:03 | <annevk> | Ms2ger: seems like he's trying to end up in gossip magazines |
| 09:03 | <JakeA> | jgraham: interacting with the raw stream won't be common in SW |
| 09:03 | <Ms2ger> | annevk, that's just your inexperience speaking |
| 09:03 | <annevk> | Ms2ger: says who :p |
| 09:03 | <Ms2ger> | annevk, if you weren't an idiot, you'd understand why he supports it ;) |
| 09:03 | <JakeA> | jgraham: you'd only need to do that if you were writing your own video decoder or something |
| 09:04 | <jgraham> | JakeA: than I don't understand why we're making the stream API the most convenient one and making the consumed APIs more inconvenient |
| 09:04 | <annevk> | jgraham: so what about as*() with .body for the low-level API? |
| 09:04 | Ms2ger | denies being Roy |
| 09:04 | <annevk> | jgraham: rather than bodyAs*() |
| 09:05 | <JakeA> | I'm a fan of response.asJSON() |
| 09:05 | <jgraham> | annevk: I don't really understand the value of asFoo() vs foo() |
| 09:05 | <Ms2ger> | asJSON(), asStream()? |
| 09:05 | <JakeA> | Don't need asStream |
| 09:05 | <jgraham> | JakeA: So that seems mildly confusing if you can also get at the headers |
| 09:06 | <JakeA> | var data = await (await fetch('/whatever')).asJSON(); |
| 09:06 | <jgraham> | response.body.text(), response.body.json() response.stream, response.headers.text(), response.headers.map() |
| 09:06 | <annevk> | jgraham: response.json() / response.bodyJSON()? |
| 09:07 | <jgraham> | would be my first choice |
| 09:07 | <JakeA> | jgraham: headers is a http://fetch.spec.whatwg.org/#headers-class |
| 09:08 | <JakeA> | by the time you get the response object the headers part of the stream has already been consumed |
| 09:08 | <jgraham> | So it's not possible to get the raw headers without consuming the stream? |
| 09:08 | <jgraham> | Oh |
| 09:08 | <jgraham> | So can you get the raw headers data? |
| 09:08 | <JakeA> | nope |
| 09:09 | <jgraham> | That seems unfortunate |
| 09:09 | <JakeA> | Sounds like you're looking for a raw socket rather than fetch |
| 09:10 | <JakeA> | Also, I don't think we can give raw headers for security reasons |
| 09:10 | <JakeA> | http only cookies, for instance |
| 09:10 | <jgraham> | Oh, that could be true |
| 09:10 | <jgraham> | In that case .text() and .json() seems fine |
| 09:11 | <jgraham> | Because everything that isn't .headers is implicitly applying to the body |
| 09:11 | <MikeSmith> | annevk: if you or Hixie said the things that Roy says, w3c partisans would be screaming with outrage about it. but Roy says it and instead they smile and say, Good ole Roy |
| 09:11 | <JakeA> | jgraham: there's a little more than that http://fetch.spec.whatwg.org/#response-class |
| 09:12 | <Ms2ger> | MikeSmith, well, Roy is a Good Guy, right? |
| 09:12 | <jgraham> | JakeA: Sure, I just mean for the body-consuming methods |
| 09:12 | <annevk> | MikeSmith: yeah e.g. https://twitter.com/johnfoliot/status/502581657053167616 but would not really have expected otherwise |
| 09:13 | <annevk> | arrayBuffer() / text() / blob() / json() / formData() |
| 09:13 | <annevk> | hmm |
| 09:13 | <annevk> | does not match any existing pattern |
| 09:13 | <annevk> | seems like we should go for it then |
| 09:14 | <JakeA> | hah |
| 09:15 | <JakeA> | var data = await (await fetch('/whatever')).json(); |
| 09:16 | <JakeA> | request.formData() |
| 09:16 | <annevk> | the main problem would be if we had members that might clash with future additions |
| 09:17 | <JakeA> | Yeah, I'm happy with as*, don't really mind. I think some will be unhappy with losing consume/take |
| 09:17 | <annevk> | I think Domenic mainly cared about it when it was proposed for the subclass |
| 09:18 | <annevk> | If we really care about brevity I think jgraham is correct |
| 09:18 | <jgraham> | I think asFoo() is basically OK, but the as isn't adding much apart from the need to hold down shift for the next letter(s) |
| 09:18 | <annevk> | If we don't so much, I'd prefer bodyAsJSON() |
| 09:18 | <annevk> | If we care about being descriptive, I'd prefer takeBodyAsJSON() |
| 09:18 | <annevk> | And I think we mostly care about brevity so jgraham's json() makes the most sense |
| 09:19 | <JakeA> | takeBodyAndParseAsJSONAndThrowIfThatFails() |
| 09:19 | <Ms2ger> | AndRejectIfThatFails? |
| 09:19 | <annevk> | None of the other properties we expose now make sense as a data type, except perhaps for url, but that'd be dataURL() or some such |
| 09:19 | <JakeA> | hah |
| 09:27 | <annevk> | jgraham: argued your position on list |
| 09:29 | <jgraham> | Thanks |
| 09:36 | <JakeA> | annevk: not so sure about hasBody |
| 09:37 | <annevk> | JakeA: it's not entirely accurate, though for the person using the object it kind of is |
| 09:37 | <JakeA> | response.hasBody != Boolean(response.body) |
| 09:37 | <annevk> | JakeA: also, I don't have anything better |
| 09:38 | <JakeA> | I still like "consumed", "taken" is ok too. "bodyTaken" if you want 'body' in there |
| 09:38 | <annevk> | JakeA: I think we'd still disallow access in that case to the stream object in some way |
| 09:39 | <annevk> | JakeA: so while it's not equal to the boolean, it's equal to the .body.canbeused or whatever, which seems roughly similar to hasAttributes() and hasChildNodes() work |
| 09:39 | <annevk> | how /\ |
| 09:40 | <annevk> | JakeA: if response.taken is true, you can still access .headers right? seems odd to not have body in there |
| 09:41 | <JakeA> | fair |
| 09:41 | <JakeA> | bodyRead |
| 09:41 | <annevk> | yeah that seems fine, although also not necessarily true |
| 09:42 | <JakeA> | yeah, same with "consumed" |
| 09:42 | <annevk> | bodyUsed |
| 09:43 | <jgraham> | Can you still access whatever it was you used to consume the stream? |
| 09:43 | <jgraham> | s/stream/body/ |
| 09:43 | <JakeA> | nope |
| 09:43 | <jgraham> | so response.json(); response.json() wouldn't work (imagine whatever async bits are needed) |
| 09:44 | <annevk> | jgraham: text() etc. only work once; if you pass a Request to fetch(), they no longer work |
| 09:44 | <annevk> | jgraham: if you put a response into a cache, they no longer work, etc. |
| 09:44 | <JakeA> | yeah, 2nd .json would reject |
| 09:44 | <annevk> | jgraham: at that point we'd flip the flag directly |
| 09:44 | <smaug____> | Domenic: why you want to use ES style for Streams? |
| 09:44 | <annevk> | jgraham: when it's actually read is up to the browser |
| 09:44 | <annevk> | smaug____: he wants them to end up in Node.js and implemented in the ES engine |
| 09:45 | <jgraham> | Sure, I was wondering if an API like consumedAs = "json" would make sense, but perhaps not |
| 09:45 | <smaug____> | ah, Node.js stuff... |
| 09:45 | <jgraham> | (it would obvioulsy be null if it hadn't been consumed yet) |
| 09:45 | <smaug____> | need to be careful then when reviewing Streams that the API works well enough in browsers too |
| 09:45 | <smaug____> | the environment is rather different |
| 09:45 | <annevk> | yeah, do you have time for review? |
| 09:46 | <annevk> | not sure there's many Gecko people involved |
| 09:46 | <annevk> | and it's certainly not something I'm skilled in |
| 09:46 | <smaug____> | if there was a readable spec... ;) |
| 09:53 | <annevk> | smaug____: seems like a good start of a review :p |
| 12:12 | <JakeA> | Hadn't thought of using localStorage purely to communicate between tabs https://twitter.com/ddprrt/status/502789624843223040 |
| 12:33 | <MikeSmith> | JakeA: neat |
| 12:52 | <smaug____> | localStorage has nothing neat |
| 12:54 | <jgraham> | smaug____: So are there any web technologies that you do like? ;) |
| 12:54 | <smaug____> | hey, localStorage is one of the APIs we want to kill |
| 12:54 | <smaug____> | jgraham: and I like events, and MutationObserver (obviously) |
| 12:55 | <smaug____> | and DOM tree |
| 12:55 | <smaug____> | that is plenty |
| 12:55 | <jgraham> | Pretty sure DOM and events are both unfashionable to like ;) |
| 12:56 | <smaug____> | but localStorage wasn't actually in APIs-to-kill list |
| 12:56 | smaug____ | adds it |
| 12:58 | <jgraham> | It's nice that we are now trying to kill WHATWG-invented APIs rather than just Netscape/Microsoft/Java-Enterprise-Requirement-invented APIs |
| 12:59 | <smaug____> | whatwg is getting old |
| 12:59 | <smaug____> | 10+ already, isn't it |
| 12:59 | smaug____ | thinks the W3C compound documents workshop was 2004 |
| 12:59 | <smaug____> | May |
| 12:59 | <jgraham> | Yeah, it's 10 |
| 13:01 | <jgraham> | But only today I was hearing about how we suffer from collective inexperience. Which sounded worrying until it was clarified that we live in an imaginary universe which seems sufficient to prevent our evident ineptness from having any actual consequence. |
| 13:02 | <smaug____> | he |
| 13:02 | <smaug____> | h |
| 13:08 | <MikeSmith> | jgraham: whereas some other people live in an imaginary universe where having written a disseration describing something that other people invented somehow buys you street cred for life |
| 13:14 | <MikeSmith> | and yeah he's right -- clearly the ones who are inexperienced are the ones who've spent 10+ years day in and day out working on testing how the Web actually works in practice and reverse engineering all kinds of crap and thoroughly/precisely/unambiguously documenting how it all works (or trying to) |
| 13:17 | <Ms2ger> | Nah |
| 13:17 | <Ms2ger> | We've actually been on reddit most of that time |
| 13:29 | <MikeSmith> | othermaciej has been at least |
| 13:29 | <MikeSmith> | (just kidding) |
| 13:45 | <annevk> | hah |
| 14:20 | <Manishearth> | annevk / Ms2ger : Shouldn't step 2 of http://fetch.spec.whatwg.org/#concept-http-fetch say "requests's client IS a Service Worker environment"? |
| 14:21 | <Ms2ger> | Might be |
| 14:29 | <wanderview> | JakeA: there are no limitations on what a cache name can be, correct? free to put /, etc in there |
| 14:31 | <JakeA> | wanderview: correct. Should probably define that. |
| 14:31 | <wanderview> | cool, thanks |
| 14:32 | <JakeA> | wanderview: I think I'm going to suggest "best practice" would be to call the cache "sitename-cachename-version" |
| 14:32 | <JakeA> | or some kind of scheme like that |
| 14:33 | <JakeA> | so in your SW activate event you can iterate over caches and identify those you don't need anymore |
| 14:33 | <wanderview> | wanderview: k... I was asking because it would be nice for implementation to have human readable directory structure, but not a big deal to map names to UUIDs |
| 14:33 | <wanderview> | oops |
| 14:33 | <wanderview> | JakeA: ^^^ |
| 14:33 | <JakeA> | "sitename/cachename/version" is better I think |
| 14:33 | <JakeA> | so yeah |
| 14:34 | <JakeA> | although not all caches need a version, such as caches that build up over time, like "click to read offline" stuff, or dynamic avatar caches |
| 14:35 | <wanderview> | yea, I think embedding version in name is fine unless we want to provide conveniences like "get all caches older than version x" |
| 14:35 | <wanderview> | but that can be a content library |
| 14:37 | <wanderview> | JakeA: we're toying with the idea of using CacheStorage/Cache internally to persist our SW script and importScript scripts... can you think of any reasons that would be a bad idea? |
| 14:41 | <JakeA> | wanderview: I think we may be doing the same. It shouldn't appear when you iterate over the caches though. We may expose it another way in the future though |
| 14:42 | <wanderview> | JakeA: yea... seems like we need a magic internal cacheName... although since its all same origin doesn't seem like a major problem if they are accessible |
| 14:43 | <wanderview> | JakeA: I guess it might be nice to have a defined cacheName prefix for internal UA use that content should not expect to work for them |
| 14:43 | <annevk> | Manishearth: no |
| 14:43 | <annevk> | Manishearth: if it would be a service worker, we don't need to pass it through a service worker |
| 14:45 | <JakeA> | wanderview: it's worth exploring. I'm worried about what happens if those caches are modified or deleted. But I guess advice could just be "don't do that" |
| 14:46 | <wanderview> | JakeA: yea, we can just make those promises reject for content I think... but it would be nice to be explicit about what key is being used internal... Like "Cache names starting with '__internal__' are reserved for use by the browser and will always reject when passed by content." |
| 14:47 | <Manishearth> | annevk: but this means requests get passed through SWs by default? |
| 14:47 | <annevk> | Manishearth: yes |
| 14:49 | <JakeA> | wanderview: could you make a ticket for that? I think it's worth exploring |
| 14:49 | <wanderview> | will do |
| 14:49 | <JakeA> | wanderview: even if we say caches.get('__internal__whatever') always rejects, so we've reserved that naming for later |
| 14:50 | <wanderview> | yea |
| 14:51 | <JakeA> | wanderview: https://github.com/slightlyoff/ServiceWorker/issues/193 |
| 14:52 | <tantek> | since I have no desire to reply to this email thread: http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0035.html I provide this for your consideration. 1) [citation needed] on all of Roy's unfounded claims. 2) "as a Senior Principal Scientist", I expect Roy to "show his work" in a manner replicable by other scientists, rather than depending on "considered opinions of folks". |
| 14:52 | <JakeA> | wanderview: http://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-global-scope-script-cache - heh, I didn't realise we'd added this |
| 14:53 | <annevk> | tantek: public-html-admin is a support forum? |
| 14:54 | <tantek> | annevk - that may be too optimistic of an assessment. |
| 14:57 | <wanderview> | JakeA: ah, yea... so makes pretty good sense to use the same underlying implementation there |
| 14:57 | <wanderview> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/424 |
| 14:59 | <tantek> | but no, seriously, I've lost patience with people call themselves "scientists" and then make arguments based purely on "considered opinions". It's like really? How dare you? |
| 14:59 | <tantek> | cc: hober |
| 14:59 | <JakeA> | wanderview: cheers! |
| 15:02 | <Philip`> | tantek: Maybe it's the typical computer science definition of scientist, i.e. one that doesn't involve anything resembling science |
| 15:03 | Philip` | can't remember ever reading a computer science paper that has a hypothesis in it |
| 15:15 | <JakeA> | wanderview: has ServiceWorker been considered for WebActivities? Feels like a SW could register for the intents it can receive during install, then when it receives an intent it can decide to open a window if it needs to via the clients api |
| 15:42 | <annevk> | JakeA: we are thinking about it, but we don't really want to do activities again |
| 15:42 | <wanderview> | JakeA: thats an interesting idea, but I'm not sure |
| 15:42 | <annevk> | JakeA: we want to tackle specific points of interest and make those extensible, such as sharing, maybe the file picker, etc. |
| 16:47 | <erlehmann> | anyone here knows of a sortable table specification? |
| 16:47 | <erlehmann> | err |
| 16:47 | <erlehmann> | polyfill? |
| 16:51 | <Ms2ger> | No |
| 16:51 | <caitp> | it probably wouldn't be too hard to write a polyfill for that, dunno if one exists |
| 16:51 | <caitp> | well, with the exception of dealing with dynamically inserted nodes |
| 16:53 | <caitp> | looks like there's a polymer component that does some variation on it, not relying on table[sortable] |
| 16:54 | <JonathanNeal> | Polyfill? |
| 16:54 | <caitp> | not a polyfill, but something that accomplishes the same goal |
| 16:54 | <Ms2ger> | Folypill |
| 16:55 | <caitp> | in a much more verbose fashion |
| 16:55 | <JonathanNeal> | Sortable table polyfill? sounds very Doable. |
| 16:55 | <JonathanNeal> | just need a spec |
| 16:55 | <JonathanNeal> | Sortable table polyfill? sounds very Doable. |
| 16:55 | <Ms2ger> | There is a spec |
| 16:55 | <caitp> | 4.9.13 in web-apps |
| 16:58 | <caitp> | that's kind of a neat feature though |
| 17:00 | <JonathanNeal> | If you message me the spec I will look at it later and if I can write the polyfill this evening I will. |
| 17:00 | <Ms2ger> | whatwg.org/html |
| 17:01 | <caitp> | http://www.whatwg.org/specs/web-apps/current-work/multipage/tables.html covers it |
| 17:03 | <annevk> | I think Hixie already wrote a script of sorts for it |
| 17:03 | <JonathanNeal> | Okay. Messaged myself. On the phone. I'll check later. Somebody already done it? |
| 17:03 | <annevk> | at least the sorting |
| 17:03 | <annevk> | don't think there's a full polyfill |
| 17:05 | <erlehmann> | JonathanNeal caitp awesome |
| 17:05 | <erlehmann> | caitp polymer will not accomplish the same goal in my case. i need backwards compat. |
| 17:05 | <erlehmann> | and forward compat. |
| 17:06 | <erlehmann> | JonathanNeal if you have a script, please show and tell! :) |
| 17:07 | <caitp> | might have trouble with polymer on netscape 2 yeah |
| 17:16 | <erlehmann> | caitp in related news, i currently have 275 tabs open. that makes me kinda averse to needlessly complex solutions. |
| 17:16 | <erlehmann> | okcupid for example drives the system load way up. |
| 17:17 | <erlehmann> | i do not wish to burden others with similar stuff |
| 17:18 | <caitp> | heh, people have been doing this stuff with jQuery plugins and similar stuff for years, there's lots of solutions that don't include native unimplemented html5 features |
| 17:19 | <caitp> | and don't need you to wrap your elements with a polyfilled shadow DOM implementation |
| 17:19 | <erlehmann> | i usually avoid the “just use jquery” crowd :D |
| 17:34 | <SamB> | caitp: what, you mean there were releases of netscape before 4? |
| 17:35 | <Hixie> | so, back in 2004 i think the "inexperience" comment would have been misguided but at least an understandable misgiving |
| 17:36 | <Hixie> | at this point though, you have to just be a troll to claim that |
| 17:36 | <Hixie> | given that i alone have more experience writing the HTML spec than any member of the HTMLWG including TimBL had back when HTML4 was written |
| 17:36 | <Hixie> | i mean, there's many more legit ways you could insult us |
| 17:36 | <Hixie> | but that seems like a woefully dumb way to do it |
| 17:38 | <caitp> | who is insulting who? |
| 17:38 | <caitp> | did I miss something |
| 17:42 | <jgraham> | caitp: The inventor of the hypertext trolling protocol has been showing off his skills |
| 17:42 | <caitp> | I'm going to be disappointed if the hypertext trolling protocol isn't an RFC |
| 17:45 | <Hixie> | jgraham: he didn't invent http, tim did. |
| 17:46 | <jgraham> | Hixie: No Time invented the Transport variant :p |
| 17:47 | <jgraham> | *Tim |
| 17:48 | <TabAtkins> | caitp: http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0035.html |
| 17:52 | <Hixie> | oh, hober, hober, hober |
| 17:55 | <caitp> | well he does sound a bit cranky towards the end of that |
| 18:18 | <smaug____> | hayato: have you gone through all the cases where HTML spec uses getElementById internally and figure out how shadow dom should behave in those cases? |
| 18:19 | <smaug____> | hayato: hmm, I guess it is basically just https://www.w3.org/Bugs/Public/show_bug.cgi?id=26643 |
| 18:21 | <Hixie> | caitp: hober? or roy? |
| 18:32 | <Hixie> | do we fetch style sheets that don't match media queries? |
| 18:32 | <Hixie> | we do, right? we just don't apply them? |
| 18:33 | <Hixie> | i wonder if we should make style sheets that don't match media queries but have dependencies not load their dependencies until the media queries match, or something |
| 18:50 | <Domenic> | Hixie: that question feels like it would star in http://jakearchibald.github.io/request-quest/ |
| 18:51 | <Domenic> | JakeA ^ |
| 18:51 | <JakeA> | I think it is in there |
| 18:52 | <JakeA> | It's certainly in the live version I do at conferences |
| 18:52 | <JakeA> | Hixie: currently we download low priority |
| 18:53 | <JakeA> | Doesn't block rendering |
| 18:54 | <JakeA> | Hixie: by dependencies do you mean @import? |
| 18:54 | <Hixie> | i mean needs="" or whatever we introduce to declare dependencies |
| 18:54 | <Hixie> | (or indeed @import) |
| 18:58 | <JakeA> | Could resolve dependencies but low priority |
| 19:00 | <JakeA> | Can't think of dependencies CSS would have |
| 19:00 | <TabAtkins> | JakeA: @import, @font-face, etc. |
| 19:01 | <TabAtkins> | Hixie: We tried doing lazy loading of image before. I don't think it worked? |
| 19:01 | <Hixie> | interesting |
| 19:02 | <Hixie> | i have a use case here which is "don't download this widget if the screen is too small" |
| 19:02 | <Hixie> | it's trivial to do via script, obviously |
| 19:02 | <Hixie> | but it's not clear how i'd do it automatically |
| 19:02 | <Hixie> | short of <script media> |
| 19:02 | <JakeA> | TabAtkins: @import is already a dependency. Fonts aren't always. They sound like use cases for resource hints though |
| 19:05 | <smaug____> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#has-been-shipped " in the order in which they were added to their respective task source" |
| 19:05 | <smaug____> | what does the respective task source refer to |
| 19:05 | <smaug____> | if the ports aren't shipped, is the idea that port1.postMessage(foo); port2.postMessage(bar); ensures that foo is delivered first ? |
| 19:11 | <Hixie> | yeah |
| 19:12 | <Hixie> | smaug____: each port has its own task source, but this kinda merges them |
| 19:12 | <baku> | Hixie, the problem I see is that if port1 is sent to a worker, we cannot be sure that 'foo' is delivered before 'bar'. |
| 19:12 | <Hixie> | if port1 is sent to a worker, this no longer applies |
| 19:12 | <baku> | so that is a good solution only for delivering messages to the same event loop. |
| 19:12 | <baku> | ok |
| 19:12 | <Hixie> | this is only for ports that haven't been shipped anywhere yet |
| 19:13 | <Hixie> | if you ship port1 to a worker and back again, even, the guarantee is lost |
| 19:14 | <baku> | Hixie, ok. thanks. |
| 20:00 | <boogyman> | Hixie: wonder if we should make style sheets that don't match media queries but have dependencies not load their dependencies until the media queries match, or something <—— This is really a double-edged sword. As an author, I've had use-cases where the Business prefers to pre-load data "in case" an option occurs, and others whom want to respect the current match. It would be nice if this could be a configuration option for UA |
| 20:03 | <Hixie> | well preloading or not is a different issue |
| 20:12 | <boogyman> | Isn't that what you were talking about? loading all media, regardless if the current state met the mq definitions? |