| 04:07 | <MikeSmith> | botie, inform zcorpan made some changes on the as-attribute branch in response to Domenic’s review comments, so make sure to pull before you do more work there locally |
| 04:07 | <botie> | will do |
| 04:31 | <botie> | zcorpan, at 2016-06-29 04:07 UTC, MikeSmith said: made some changes on the as-attribute branch in response to Domenic’s review comments, so make sure to pull before you do more work there locally |
| 05:59 | <MikeSmith> | annevk: there are bunch of different places in the HTML spec that say, “Let request be a new request whose… destination is "subresource"” but "subresource" is not (any longer) a valid destination |
| 06:00 | <MikeSmith> | annevk: so am I misunderstanding something, or do those places need to be updated/fixed? |
| 06:05 | <MikeSmith> | annevk: and if so I’m happy to write up a PR with the fix, but first I need to understand what it should be changed to… |
| 06:06 | <annevk> | MikeSmith: need to be changed to the new values we introduced |
| 06:06 | <annevk> | MikeSmith: there is an open issue |
| 06:06 | <MikeSmith> | ah ok |
| 06:06 | MikeSmith | looks for the issue |
| 06:08 | <annevk> | MikeSmith: should be pretty easy mapping; Fetch also has a table near def of destination |
| 06:09 | <MikeSmith> | yeah |
| 06:10 | <MikeSmith> | OK I can try writing up a patch |
| 06:10 | <MikeSmith> | I don’t see an open issue other than https://github.com/whatwg/html/issues/1142 |
| 06:16 | <Manishearth> | annevk: thanks for the link. forwarded to ajeffrey, who is working with navigation in servo |
| 06:16 | <Manishearth> | (I'm not really looking at navigation right now; I came across that bug when going through how javascript: works) |
| 06:16 | <Manishearth> | > This algorithm has so much drama. |
| 06:16 | <Manishearth> | so true |
| 06:17 | <Manishearth> | you should replace the algorithm with "just load the effin page" |
| 06:19 | <annevk> | MikeSmith: hmm not sure |
| 06:24 | <MikeSmith> | annevk: no worries I don’t think I need it |
| 06:27 | <MikeSmith> | annevk: so just for one example, in the algorithm for handling ping=, at https://html.spec.whatwg.org/multipage/semantics.html#hyperlink-auditing, it should set destination just to "", right? |
| 06:29 | <annevk> | MikeSmith: per https://fetch.spec.whatwg.org/#concept-request-destination, yes |
| 06:29 | <MikeSmith> | yeah |
| 06:29 | <MikeSmith> | OK, thanks, will make a PR |
| 07:03 | <MikeSmith> | annevk: raised https://github.com/whatwg/html/pull/1470 for the “destination is subresource” fixes |
| 15:29 | <wanderview> | JakeA: in chrome, does a <link rel="prefetch"> or <link rel="preload"> trigger a FetchEvent? |
| 15:29 | <JakeA> | Good question. Let's find out! *writes test* |
| 15:29 | <JakeA> | They *should* |
| 15:31 | <wanderview> | JakeA: should they? because if the intent is to populate the http cache, then the SW gets in the way... although its a nice way to spin up the SW early before the user clicks a link |
| 15:32 | <wanderview> | same thing with preconnect |
| 15:32 | <wanderview> | prerender seems like it must go through service worker |
| 15:33 | <annevk> | I think they all should |
| 15:33 | <wanderview> | JakeA: it still feels to me like the PlzNavigate "preflight" is basically a preload or prefetch |
| 15:34 | <wanderview> | in terms of spec concept |
| 15:34 | <annevk> | Service worker needs to be in control |
| 15:34 | <wanderview> | annevk: the problem is that it basically destroys the benefit of prefetch/preload if you have to start a cold service worker... by the time the user clicks the link you may not have started the network fetch yet |
| 15:35 | <annevk> | I don't think that comparison makes sense, re preflight |
| 15:35 | <wanderview> | assuming the SW is going to go the network |
| 15:35 | <wanderview> | annevk: I'm not talking about CORS preflight... I'm talking about the issue slightlyoff wrote |
| 15:35 | <annevk> | Well the document just came from the SW, so… |
| 15:35 | <annevk> | wanderview: neither am I? |
| 15:36 | <wanderview> | annevk: where the browser initiates a network request based on the user typing in the URL bar... and starts loading the page for the most likely entry |
| 15:36 | <wanderview> | to me thats pretty much exactly prefetch or preload, no? |
| 15:37 | <annevk> | Not coupled with the proposal of bypassing SW for network activity |
| 15:37 | <wanderview> | annevk: I thought preload or preflight could be cross-origin navigation links... like from search results page, etc |
| 15:37 | <JakeA> | wanderview: looks like preload isn't just to warm up the HTTP cache http://w3c.github.io/preload/#dfn-preload-resource-has-been-obtained |
| 15:38 | <JakeA> | looks like there's intent to have a page-level cache somewhat like <img> |
| 15:38 | <JakeA> | In which case a service worker's response here could be useful |
| 15:38 | <wanderview> | I wonder if anyone implements it that way |
| 15:39 | <JakeA> | It's not properly defined, so I guess not |
| 15:41 | <wanderview> | JakeA: I just feel there is something missing from the route proposal that doesn't meet the original use case... I think they wanted to return something different for the "PlzNavigate preflight" case, but only if there is a service worker, and without blocking the "PlzNavigate preflight" request on starting up the service worker |
| 15:41 | <wanderview> | but I guess we have to ask thme |
| 15:43 | <JakeA> | wanderview: yeah, I was wondering what the setPreflightHeader bit was for. If it's important, we could add it as an option to FetchSource |
| 15:44 | <wanderview> | JakeA: I think my gut feeling is still to wait on the routing solution... lets see what frameworks become popular/dominant to see what use cases people really care about |
| 15:44 | <wanderview> | JakeA: but if there was a way to help the preload/prefetch/preflight case do something today that can't be polyfilled, maybe it would be worth doing if it can be kept small and simple |
| 15:45 | <JakeA> | wanderview: yeah, it feels early to me too. I'd only want to push forward on it if this SW startup time proves to be mega disastrous |
| 15:46 | <wanderview> | JakeA: do you know where most of the SW startup time comes from in chrome? is it v8 specific? |
| 15:46 | <JakeA> | wanderview: I'm worried that we're scenario-solving by doing that. Also worried that we don't have a great picture of the problem |
| 15:47 | <JakeA> | wanderview: Not sure. If it's v8 then parsed code caching should solve it, but I get the impression it's something more |
| 15:47 | <wanderview> | JakeA: I do agree... but feels there is just a small piece missing... "bypass service worker for pre-* network request"... then the SW can just use existing fetch(url, {cache: only-if-cached}) to get the result of the pre-* |
| 15:48 | <wanderview> | that could be a very small API that does a well defined thing... and would be useful for continuing to prefetch http cache resources |
| 15:48 | <wanderview> | for sites that want that behavior |
| 15:48 | <JakeA> | wanderview: pages are generally not cachable though |
| 15:49 | <JakeA> | wanderview: also, I don't like that there's no opt-in/out for this extra network request. What if I'm navigating to a movie I've cached? |
| 15:50 | <JakeA> | wanderview: what bothers me is the numbers I've seen come from sites that have added an empty SW just to get a feel for what the startup time is. It's not surprising that SW isn't free, but it seems broken not to compare that to the gains of actually using SW |
| 15:50 | <wanderview> | JakeA: the service worker doesn't have to use the result of the preflight... it could decide to use Cache.match |
| 15:51 | <wanderview> | JakeA: the numbers that were mentioned to me were 200ms... thats a lot of ground to make up |
| 15:51 | <JakeA> | wanderview: right, so now I've got a 3gb video downloading in the background? |
| 15:51 | <JakeA> | that I didn't need to download |
| 15:51 | <JakeA> | Or is the stream cancelled? |
| 15:53 | <wanderview> | JakeA: well, the SW proposal was an opt-in thing... so I assume you would not opt-in if you expect your navigations to be 3GB videos |
| 15:53 | <wanderview> | JakeA: for PlzNavigate itself... thats a browser-specific optimization... hopefully they take that issue into account before downloading tons of network |
| 15:54 | <wanderview> | as I understand it, anyway |
| 15:55 | <wanderview> | JakeA: anyway, I'm happy to just say "not yet" and focus on getting SW startup times down... that benefits everyone... not just huge sites that can afford to micro-optimize this kind of stuff |
| 15:55 | <wanderview> | but I also kind of see where they are coming from |
| 15:55 | <JakeA> | wanderview: I don't see the opt-in in Alex's proposal :( |
| 15:56 | <JakeA> | Also, if it blocks the fetch event on this preflight returning headers, it's breaking the offline-first usecase |
| 15:56 | <wanderview> | JakeA: ah... as its was described to me by the partner... they suggested an opt-in... if I call a method in install handler, do the preflight with a particular RequestInit value |
| 15:57 | <wanderview> | JakeA: yea... that part I agree is not well defined for what they are trying to do... it sounds like they want to race, but then Alex's proposal said it had the response in the fetch event |
| 15:58 | <JakeA> | wanderview: Would be great to get partners involved in that issue. Feels like the use-cases are a bit vague, to me anyway |
| 15:59 | <JakeA> | wanderview: If you're going to have the race, surely you'd want to use the network response if it wins? Waiting for the fetch event still at that point seems like it's missing a trick |
| 16:00 | <wanderview> | JakeA: in the use case that was described to me they wanted to return a json object and have the SW do extra processing |
| 16:00 | <wanderview> | ¯\_(ツ)_/¯ |
| 16:01 | <JakeA> | wanderview: did that processing affect the response, or was it additional non-response work like caching |
| 16:01 | <JakeA> | wanderview: also, giv |
| 16:01 | <JakeA> | bah |
| 16:01 | <JakeA> | wanderview: also, if this is json, it doesn't sound like a navigation |
| 16:01 | <wanderview> | JakeA: sounded to me like client side rendering using a stream... most of the shell is cached and they use the json to construct the html just in time |
| 16:02 | <JakeA> | wanderview: wouldn't the SW be awake from the shell fetch in that case? |
| 16:03 | <wanderview> | JakeA: I think this is the case where the user hasn't had the site open for a while, but they expect it was previously installed... so SW is likely timed out and cold |
| 16:03 | <JakeA> | wanderview: as in page is open, SW has terminated, user clicks something that triggers the JSON download? |
| 16:04 | <wanderview> | JakeA: as in page is closed, user types the name of the site in the url bar, hits enter, triggers JSON download, previously installed service worker renders html |
| 16:04 | <wanderview> | JakeA: this is why they wanted a custom header so they know its safe to serve the json instead of html |
| 16:04 | <wanderview> | I think |
| 16:06 | <JakeA> | wanderview: so without a service worker the site just displays JSON? |
| 16:06 | <JakeA> | I feel like my brain has fallen off the rails a bit |
| 16:06 | <wanderview> | JakeA: without a service worker the "please preflight with this header" API is never called... the server does not see the special header... the server sends html |
| 16:07 | <wanderview> | and the browser displays html |
| 16:07 | <wanderview> | JakeA: very complicated! and for how big a win? |
| 16:09 | <JakeA> | Ahh I see, so in the SW case the shell would be loaded, which then makes a request for the page but with Accept: application/json or whatever |
| 16:09 | <wanderview> | right |
| 16:10 | <wanderview> | but they want to be able to get that fetched without the SW startup cost |
| 16:11 | <JakeA> | Even if we give them this preflight + header thing their first render is still blocked on SW startup |
| 16:11 | <wanderview> | JakeA: yea, they just want to make it parallel with the fetch event they know they want to attempt in this case |
| 16:12 | <JakeA> | And doing this preflight for *all* URLs, even though they only want it for a subset, feels like a dodgy solution |
| 16:12 | <wanderview> | JakeA: well, in this case I think they had the impression PlzNavigate would only do it for URLs that show up as likely results in the URL bar |
| 16:13 | <JakeA> | wanderview: The routes thing I'm handwaving about would let them get on screen with their shell and fetch their JSON without the SW starting up at all |
| 16:13 | <wanderview> | JakeA: well, they still need to process the JSON into html somehow |
| 16:14 | <JakeA> | wanderview: are they not doing that from the page anyway? |
| 16:14 | <wanderview> | JakeA: I agree the routes thing is a better defined mechanism that probably meets their use case... |
| 16:14 | <wanderview> | JakeA: my impression the JSON was going to be rendered into the index.html in the SW... but I could be mistaken |
| 16:15 | <wanderview> | JakeA: think of it like delta-encoding... they just want to send a diff down for their index.html |
| 16:15 | <JakeA> | wanderview: I guess you could do it as a stream, which would make doing it in the SW a benefit. |
| 16:15 | <JakeA> | That puts them in the same use-case as my blog, so racing the network for the full response becomes a better solution |
| 16:16 | <wanderview> | yea, I think they want something like that |
| 16:17 | <JakeA> | wanderview: that's the final example in https://github.com/slightlyoff/ServiceWorker/issues/920#issuecomment-229390344 |
| 16:18 | <JakeA> | But yeah, I'm reaching out to teams/partners to try and get more details on this. Feel in the dark about the use cases a bit |
| 16:18 | <wanderview> | JakeA: yea... I just go back to the concern about adding a relatively large general purpose framework in the browser when its still pretty early in SW adoption |
| 16:19 | <wanderview> | JakeA: I do like the route framework, but I'm hesitant after something as simple as cache.add() was not quite right |
| 16:19 | <JakeA> | absolutely agree |
| 16:20 | <wanderview> | for added fun, this was just written: https://github.com/slightlyoff/ServiceWorker/issues/921 |
| 16:20 | <wanderview> | which could play into how all this works |
| 16:31 | <wanderview> | annevk: fwiw, this suggests rel=prefetch is intended to speed up the next navigation https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/ |
| 16:31 | <annevk> | wanderview: sure, but it doesn't skip the SW |
| 16:33 | <Domenic> | It makes sense to me that preconnect skips service worker but prefetch does not |
| 16:34 | <Domenic> | prefetch hints to perform a fetch, which if performed, goes through service worker. preconnect is below the fetch level |
| 16:34 | <JakeA> | Agreed |
| 16:41 | <annevk> | preconnect just establishes a network connection (defined in terms of something defined in Fetch) |
| 16:41 | <annevk> | so yeah |
| 16:47 | <wanderview> | sounds reasonable |
| 16:47 | <wanderview> | strangely, I can't find a site that actually uses <link rel="prefetch"> |
| 16:49 | <JakeA> | Depending on how http://w3c.github.io/preload/#dfn-preload-resource-has-been-obtained works, it might be useless for cross-navigation resources. Unless they end up in the SW/HTTP cache as a result |
| 17:24 | <slightlyoff> | JakeA: they're always going to be "blocked" on SW startup, but the network request for fresh data isn't. We're talking about the difference here between being able to serve your site's header and stream content in almost as soon as that's in place, vs waiting for the SW startup before you ever get the request for the content out to the network |
| 17:24 | <slightlyoff> | and routing doesn't help here |
| 17:25 | <slightlyoff> | it isn't about getting UI from the server; it's about pivoting the request from being all your UI to just being your data (which could be an HTML "partial" or similar) |
| 17:27 | <JakeA> | slightlyoff: I've shown in the issue that routing can help here, even in the particular case you're talking about. And doesn't result in a lot of wasted requests. |
| 17:27 | <slightlyoff> | I'll respond in the issue, but none of the proposed problems that JakeA outlined are the problems that big sites are facing w/ SW latency |
| 17:28 | <JakeA> | slightlyoff: please provide actual details for what sites are trying to do |
| 17:28 | <slightlyoff> | Will do |
| 19:34 | smaug____ | wishes html spec would in the attribute definitions have some link to the algorithms using that particular attribute |
| 20:14 | <wanderview> | Domenic: in ReadableByteStreamControllerPullInto, what is "the typed array constructors table"? the link seems busted |
| 20:14 | <Domenic> | smaug____: the dfn popup should do that for you, shouldn't it? |
| 20:15 | <wanderview> | Domenic: ah... the links are just missing ecma262 path |
| 20:15 | <Domenic> | wanderview: haha wow that is a busted link. thank you. |
| 20:15 | <wanderview> | I thought maybe it was a proposal or something |
| 20:16 | <Domenic> | fixed |
| 20:16 | <Domenic> | it's much more boring than that |
| 20:16 | <wanderview> | thanks! |
| 20:17 | <Domenic> | I love that the hash is #table-49 but the table is now table 50 |
| 20:21 | <wanderview> | Domenic: is there a reason we don't use .BYTES_PER_ELEMENT? |
| 20:21 | <Domenic> | wanderview: mutable by authors |
| 20:21 | <smaug____> | Domenic: "dfn popup" ? |
| 20:21 | <Domenic> | smaug____: click a <dfn>, you get a nice popup showing all its uses? |
| 20:21 | <smaug____> | I don't know what is dfn |
| 20:21 | <Domenic> | smaug____: bold things |
| 20:22 | <Domenic> | that when you hover over them have a hand cursor |
| 20:22 | <wanderview> | Domenic: TypedArray.prototype.BYTES_PER_ELEMENT is [[Writable]]:false... doesn't that prevent script from messing with it? |
| 20:22 | <smaug____> | Domenic: so, I start from https://html.spec.whatwg.org/#htmlanchorelement, click 'download' |
| 20:22 | <Domenic> | wanderview: nah, just assigning. You can still do `Object.defineProperty(Uint8Array.prototype, "BYTES_PER_ELEMENT", { get() { throw new Error("boo"); } }) |
| 20:22 | <smaug____> | and download just gives link back to htmlanchorelement |
| 20:23 | <Domenic> | smaug____: yes. Then click the bolded "download" |
| 20:23 | <Domenic> | that you ended up at |
| 20:24 | <smaug____> | Domenic: and then what? |
| 20:25 | <Domenic> | See the nice popup in this screenshot? https://usercontent.irccloud-cdn.com/file/dUYdvuFC/2016-06-29.png |
| 20:25 | <smaug____> | no |
| 20:25 | <Domenic> | it's below the "HTML" bookmark |
| 20:25 | <Domenic> | right next to the bold word "download" |
| 20:25 | <Domenic> | in the upper left |
| 20:26 | <smaug____> | Domenic: clicking in the HTMLAnchorElement download leads to https://html.spec.whatwg.org/#dom-a-download |
| 20:26 | <Domenic> | I see, you're clicking on the IDL attribute |
| 20:26 | <smaug____> | yes, what else would I click? |
| 20:26 | <Domenic> | No algorithms use the IDL attribute |
| 20:26 | <Domenic> | The content attribute |
| 20:26 | <Domenic> | which leads to https://html.spec.whatwg.org/#attr-hyperlink-download |
| 20:27 | <smaug____> | and the idl attribute definition doesn't link to the content attribute |
| 20:27 | <Domenic> | yes, it's assumed it's clear what "the same name" means |
| 20:27 | <TabAtkins> | Yeah, those two are very far apart. I had to click around a bit before I finally found the content attribute. |
| 20:28 | <TabAtkins> | Domenic: It's clear, yes. It's not easily jumpable, tho. |
| 20:28 | <TabAtkins> | If you wind up looking at the IDL rather than the elementdef table, there's no obvious way to reach the content attribute. |
| 21:16 | <wanderview> | Domenic: is it intentional that ReadableByteStreamControllerRespond shadow the bytesWritten argument? |
| 21:16 | <wanderview> | using "let" instead of "set" |
| 21:17 | wanderview | nit picks |
| 21:21 | <Domenic> | Hmm, not really |
| 21:21 | <Domenic> | Unsure whether we should pick a non-colliding name or just use Set |
| 21:21 | <Domenic> | probably "ste" |
| 21:30 | <TabAtkins> | Ah, non-colliding operating name. Bold move. |
| 21:30 | <TabAtkins> | *operation |
