| 07:52 | <Ms2ger> | Arguments thing? |
| 07:53 | <annevk> | Ms2ger: that bikeshed treats arguments as if they're definitions |
| 07:53 | <Ms2ger> | Ah |
| 09:49 | <Ms2ger> | annevk, were you working on something for sites' database quota? |
| 09:55 | <MikeSmith> | Ms2ger: https://storage.spec.whatwg.org/#quota I think |
| 09:55 | <Ms2ger> | There we are |
| 09:56 | <MikeSmith> | though there's not much there there at this point |
| 09:57 | <Ms2ger> | Yeah |
| 09:57 | Ms2ger | wonders if we're going to move Storage into that spec |
| 10:04 | <annevk> | Ms2ger: what is Storage? |
| 10:05 | <Ms2ger> | local/session |
| 10:05 | <annevk> | We could maybe, would that shrink HTML a lot? |
| 10:05 | <annevk> | The Cache API could move there too maybe |
| 10:07 | <Ms2ger> | I don't know that there's any single piece that would shrink HTML by a lot, compared to its overall size :) |
| 10:09 | <Ms2ger> | Print preview on the w3c fork says 20 pages or so, for whatever that's worth |
| 10:09 | <jgraham> | That's <5% I think |
| 10:11 | <annevk> | Yeah, about 2% I suspect |
| 11:10 | <annevk> | Well, and since it's the fork that likely includes a bunch of boilerplate, so more like 1%... |
| 11:10 | <annevk> | But maybe as with performance every little bit helps? |
| 11:11 | <annevk> | TabAtkins: https://github.com/whatwg/dom/issues/62 |
| 12:06 | <wanderview> | annevk: you around to help me with opaqueredirect? |
| 12:07 | <wanderview> | annevk: I don't see where the fetch algorithm consumes the opaqueredirect to actually do the redirect |
| 12:09 | <wanderview> | annevk: won't the original fetch algorithm that initiated the fetch event end up in the "manual" redirect mode of the 30x handling when an opaqueredirect is returned? thus returning another opaqueredirect? |
| 12:10 | <wanderview> | annevk: ultimately I'm trying to understand if an opaqueredirect can result in the navigation triggering a second fetch event |
| 12:10 | <wanderview> | JakeA: maybe you have thoughts about this too ^^^ |
| 12:21 | <JakeA> | wanderview: an opaque redirect to a navigation should result in another fetch event |
| 12:22 | <JakeA> | depending on the redirect location |
| 12:22 | <wanderview> | JakeA: depending? |
| 12:22 | <JakeA> | it'll go to the SW that controls the new location, if any |
| 12:22 | <wanderview> | JakeA: is this all "to be spec'd in HTML spec" sort of stuff? |
| 12:22 | <wanderview> | I don't see it currently |
| 12:23 | <JakeA> | So, if a navigation to //origin1/foo/bar returns a redirect to //origin2/baz, the SW which controls //origin2/baz will get the 2nd fetch event |
| 12:24 | <wanderview> | I have the feeling this is going to be really hard to implement in gecko |
| 12:24 | <wanderview> | JakeA: thanks |
| 12:25 | <JakeA> | wanderview: so a navigation hits https://fetch.spec.whatwg.org/#http-fetch, it gets an opaque redirect from the SW, which survives the checks in 2.2 |
| 12:26 | <wanderview> | yep |
| 12:26 | <JakeA> | It doesn't do 5.301.10, because it's manual, not follow |
| 12:26 | <wanderview> | yep |
| 12:26 | <JakeA> | The response is returned to the navigation algo |
| 12:27 | <wanderview> | JakeA: well, does it double wrap as an opaque response then? |
| 12:27 | <wanderview> | but yea |
| 12:28 | <JakeA> | In step 19 of https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents, the navigate algo loops back to create a new fetch based on the redirect url |
| 12:28 | <wanderview> | ok... thats the part I was missing |
| 12:28 | <wanderview> | I find the html spec hard to navigate |
| 12:28 | <JakeA> | it's a beast |
| 12:30 | wanderview | wishes bz was not on vacation... |
| 12:31 | <wanderview> | JakeA: it seems an error that 5.301.11 creates a new opaqueredirect if it already has an opaqueredirect |
| 12:31 | <hallvors> | jgraham: have a moment to look at the last few comments in https://critic.hoppipolla.co.uk/showcomment?chain=12228 ? TIA! |
| 12:32 | <wanderview> | seems like it should just return the existing opaqueredirect |
| 12:33 | <JakeA> | yeah, not sure I fully understand that, annevk usually has a good reason though. He'll be able to clear it up. |
| 12:33 | <wanderview> | JakeA: at least in our impl, we assert that an opaqueredirect doesn't wrap an existing filtered response type |
| 12:33 | <wanderview> | since it breaks the "get unfiltered <value>" semantics... that stuff only looks one level deep |
| 12:37 | <annevk> | wanderview: what is 5.301.11? |
| 12:37 | <wanderview> | annevk: http-fetch step 5, for the 30x series of status codes, step 11 |
| 12:38 | <annevk> | wanderview: hmm yes |
| 12:40 | <annevk> | wanderview: I guess another problem is that when you return an opaqueredirect from a service worker when redirect mode is follow |
| 12:40 | <wanderview> | annevk: I don't think that is permitted today |
| 12:40 | <annevk> | wanderview: although I guess that scenario fails in 2.2 |
| 12:40 | <wanderview> | annevk: yea |
| 12:41 | <annevk> | still, the whole status code dance should probably operate on the internal response, which would avoid recursive wrapping |
| 12:42 | <wanderview> | JakeA: so if someone is doing read-through-caching... we would expect an opaqueredirect to end up in the Cache... and the following secondary fetch event will result in the final resource being in the Cache too? |
| 12:42 | <wanderview> | annevk: the restriction for opaqueredirect for navigations seems a bit problematic to me |
| 12:42 | <JakeA> | wanderview: unless they were serving from cache-first, in which case they'd get a redirect loop |
| 12:43 | <wanderview> | JakeA: hmm... not sure I see where the loop happens |
| 12:43 | <annevk> | wanderview: you'll have to tell me what the problem is |
| 12:44 | <wanderview> | annevk: consider an opaqueredirect gets put in the Cache for navigation... but then the same URL is loaded as *not* a navigation, you will get a failure when its read out of the Cache |
| 12:44 | <wanderview> | annevk: for example, someone visits an img thats served with a redirect |
| 12:44 | <JakeA> | wanderview: no, you're right, it wouldn't loop, sorry |
| 12:44 | <wanderview> | visits the img as a navigation... then loads the page with the img embedded |
| 12:46 | <annevk> | why would the Cache API cache a redirect? |
| 12:47 | <JakeA> | annevk: if the pattern is cache-after-fetch: User visits '/', fetches, response added to cache |
| 12:47 | <wanderview> | annevk: this pattern: https://jakearchibald.com/2014/offline-cookbook/#on-network-response |
| 12:49 | <annevk> | Well, not handling manual redirects for navigations causes its own set of problems |
| 12:49 | <annevk> | Pick your poison |
| 12:49 | <JakeA> | I don't think caching a redirect is so bad tbh. If it's temporary maybe. But yeah, developers will need to watch what they cache |
| 12:50 | <annevk> | wanderview: I filed https://github.com/whatwg/fetch/issues/105 on your double wrapping issue |
| 12:50 | <wanderview> | annevk: by why not allow opaqueredirect for non-navigation |
| 12:50 | <wanderview> | ? |
| 12:50 | <annevk> | wanderview: did you read #66? |
| 12:51 | <annevk> | I think we discussed this |
| 12:51 | <wanderview> | not in its entirety, no |
| 12:51 | <wanderview> | I can look for the navigation restrict |
| 12:54 | <annevk> | wanderview: I think https://github.com/whatwg/fetch/issues/66#issuecomment-121192316 discusses it |
| 12:55 | <annevk> | wanderview: the main problem is where the request ends up if the redirect went cross-origin |
| 12:55 | <annevk> | wanderview: that's clear for "manual", not for "follow" |
| 12:55 | <annevk> | It might be worth explaining that in the specification since it's a security restrictions of sorts |
| 12:56 | <jgraham> | hallvors: Donw |
| 12:56 | <jgraham> | *Done |
| 12:58 | <annevk> | I just received a long private rant about why we have to keep synchronous XMLHttpRequest... |
| 13:00 | <jgraham> | annevk: Do you have a Sync XHR bingo card yet? |
| 13:02 | <wanderview> | someone probably wrote "for a sync xhr, email annevk" in a bathroom stall somewhere |
| 13:02 | <annevk> | If you're curious, I forwarded the email to the responsible party: https://lists.w3.org/Archives/Public/www-archive/2015Aug/0006.html |
| 13:04 | <ato> | annevk: Millions I tell you. MILLIONS! |
| 13:05 | <annevk> | "Douglas Crockford has likened doing changes like the ones you and your ilk imposed, as being like a physical assault, like cutting people with knives..." |
| 13:09 | <TabAtkins> | Oh wow, both "nazi" *and* "indian giving". Had to throw in some racism at the end there I guess. |
| 13:09 | <caitp> | imposed? |
| 13:10 | <caitp> | i didn't think anyone actually turned the feature off yet |
| 13:11 | <ato> | Turning off sync XHR would have devastating effects on the web I think, although I can't back that up with data. |
| 13:12 | <caitp> | yeah, it sounds like it's probably not going to happen |
| 13:12 | <annevk> | The warning is there mostly to recommend better practice |
| 13:12 | <annevk> | And it seems to be effective in raising awareness |
| 13:13 | <TabAtkins> | And, I guess, having people with unrelated bugs fly off the handle. |
| 13:14 | <wanderview> | annevk: you could have gotten a short message like he sent this person: http://thehandshakedrugs.tumblr.com/post/22360423717/i-woke-up-to-this-email-this-morning-its-pretty |
| 13:15 | wanderview | goes on kid duty |
| 13:16 | <annevk> | wanderview: o_O nice detective work |
| 13:16 | <TabAtkins> | omg |
| 13:17 | <annevk> | I missed this gem at the end: "my hate and that of many others will be forever" |
| 13:52 | wanderview | resists making a Warhammer joke. |
| 13:53 | <wanderview> | annevk: why is the http-fetch 2.2 check "fail if non-navigation and opaqueredirect" instead of "fail if redirect mode is follow and opaqueredirect"? |
| 13:54 | <wanderview> | annevk: I mean.. why can't code do fetch(url, { redirect: 'manual' }) and get it intercepted with an opaqueredirect? |
| 13:57 | <annevk> | wanderview: well, redirects have tons of security issues around them, I rather keep them closely guarded until we know it's safe |
| 13:58 | <annevk> | wanderview: what's the use case of allowing that? |
| 13:58 | <annevk> | wanderview: we could work through it I suppose and add it if you think that's valuable |
| 14:02 | <wanderview> | annevk: no use case in mind... just trying to understand why we are operating on "navigation" instead of the primitives script can see/reproduce (since we rolled back context for now) |
| 14:04 | <annevk> | wanderview: since it's more restrictive |
| 14:04 | <annevk> | more MVP, if you will |
| 14:28 | <annevk> | So for whoever is attending TPAC... When you book the Renaissance Sapporo Hotel through Egencia (perhaps Expedia too?) the rates are less than half from what is listed on w3.org and their recommend travel agency... |
| 14:29 | <annevk> | As in, I'm staying six nights for USD ~400 |
| 14:30 | <wilhelm> | Yes. I got it cheaper from Hotels.com. |
| 14:31 | <jgraham> | annevk: You're going to get angry mail from W3C management :) |
| 14:31 | <annevk> | jgraham: Film at 11 |
| 14:32 | <wilhelm> | I'm arriving in Tokyo on Saturday morning (23rd). Will drink the best cocktails in town that night (you're all invited). Off to Sapporo the next day. |
| 14:32 | <annevk> | I'm arriving Friday morning... |
| 14:33 | <wilhelm> | In Sapporo or Tokyo? |
| 14:33 | <annevk> | Tokyo |
| 14:34 | <annevk> | I'm either staying there until Sunday, or join mnot's road trip idea, but that thread's been kind of silent lately |
| 14:38 | <wilhelm> | I'll be here all of Saturday night: http://www.japantimes.co.jp/life/2014/06/10/food/meet-willy-wonka-extraordinary-cocktails/ :D |
| 14:38 | <wilhelm> | (The Akasaka branch.) |
| 14:40 | <TabAtkins> | wilhelm: If you're ever in Seoul, you must go to Le Chamber. Best cocktails I've ever had. |
| 14:40 | wilhelm | takes notes. |
| 14:41 | <TabAtkins> | (We happened to go the night before the Korean bartending championships, so they had some guest mixers that night who made some *amazing* drinks.) |
| 14:41 | <TabAtkins> | The owners are brothers who have both won the championship, iirc |
| 14:41 | <wilhelm> | Oh, fun. |
| 14:42 | <TabAtkins> | I believe you always need a reservation, at least for a bar seat (which you want). |
| 14:47 | <wilhelm> | I attended a rather amazing food-and-cocktails pairing dinner at the above-mentioned place last week. The head bartender from Tippling Club in Singapore did the cocktails. That place is hereby recommended by proxy, too. |
| 14:55 | <gsnedders> | wilhelm: Sat is the 24th? |
| 14:56 | <wilhelm> | gsnedders: Yes. |
| 14:56 | <gsnedders> | wilhelm: silly wilhelm, can't you even date? |
| 14:56 | <wilhelm> | Eh, mistyped. |
| 14:56 | <wilhelm> | No. |
| 14:56 | <wilhelm> | Because timezones. |
| 14:56 | <gsnedders> | …that sounded more questionable than I meant. |
| 15:26 | <wanderview> | JakeA: annevk: if a navigation triggers a fetch event, then fetch event does nothing (does not call respondWith()), then the normal browser processing hits a redirect, should a second fetch event be triggered in that case? |
| 15:26 | <wanderview> | or only a second fetch event if an opaqueredirect is hit? |
| 15:27 | <JakeA> | Second fetch event, targeted at the controller of the new url |
| 15:27 | <wanderview> | JakeA: even if the controller is the same as the first fetch event? (same origin/scope) |
| 15:28 | <JakeA> | wanderview: yep! |
| 15:28 | <wanderview> | ok |
| 15:28 | wanderview | is beginning to think taking this bug was a mistake. |
| 15:28 | <JakeA> | wanderview: if I respondWith(Request.redirect('/')) to a navigation, I'd expect another fetch event too |
| 15:29 | <wanderview> | JakeA: but only for navigations, right? |
| 15:29 | <wanderview> | or manual redirect flag |
| 15:29 | <wanderview> | JakeA: Request.redirect('/') is not an opaqueredirect, right? |
| 15:31 | <JakeA> | wanderview: I'd expect another fetch if the original request was manual-redirect, and the initiating algo reacts to redirects by starting a whole new fetch (which is navigations, there may be others) |
| 15:31 | <JakeA> | wanderview: Request.redirect('/') is just a Response |
| 15:31 | <wanderview> | JakeA: so I guess if a script does fetch(url, { redirect: 'manual' }) they could detect the 30x status code and do a new fetch() |
| 15:32 | <JakeA> | annevk: would it be useful to start a ticket for drafting the patches to HTML regarding fetch? |
| 15:42 | <wanderview> | JakeA: do you consider this new redirect behavior v1 or v2 for service workers? |
| 15:42 | <wanderview> | should I be concerned about being incompatible if chrome waits to implement? |
| 15:53 | <JakeA> | wanderview: Google docs hit a problem where, on navigation, their SW would fetch the page, but it'd hit a redirect to the (other origin) login page. If they served this they'd get an error. They could work around it by making a no-cors fetch and assuming an opaque response was a redirect, and issue the redirect themselves, but then they're downloading the |
| 15:53 | <JakeA> | login page twice |
| 15:54 | <JakeA> | The changes to redirect were to handle this case |
| 15:54 | <JakeA> | So, without these changes, offline may fail in Google Docs, so I guess it depends on how much that matters |
| 16:09 | <annevk> | wanderview: yeah, because of manual and each request being fresh |
| 16:09 | <annevk> | JakeA: yeah sounds fine |
| 16:22 | <wanderview> | JakeA: well... from the issue comments the chrome impl team were a bit surprised by the changes... so I was wondering if it was going to be implemented later, etc |
| 16:22 | <wanderview> | not a priority or something |
| 16:23 | <JakeA> | wanderview: Docs are a pretty high priority customer for us, so pretty sure it'll get done with pretty high priority |
| 16:27 | <wanderview> | JakeA: annevk: do we need Request.context sorted before integrating with other specs? |
| 16:27 | <wanderview> | or I guess its not hard to change later... just might be more work to roto-till the other specs twice |
| 16:27 | <annevk> | wanderview: we'd just not define it for now I guess |
| 16:27 | <annevk> | I should have made a proposal for that today |
| 16:27 | <annevk> | forgot |
| 16:27 | <JakeA> | although CSP has kinda defined most of them |
| 16:35 | <ccardona-work> | Good morning WHATWG crew o/ |
| 17:22 | <wanderview> | annevk: any chance you want to put http-fetch step 4, 30x case, step 11 before the "follow" steps? short circuiting the short path is nicer when implementing |
| 17:22 | <wanderview> | minor nit |
| 17:32 | <annevk> | wanderview: file an issue? |
| 17:33 | <annevk> | wanderview: seems fine |
| 17:33 | <wanderview> | ok |
| 17:39 | <wanderview> | annevk: https://github.com/whatwg/fetch/issues/107 |
| 18:10 | <miketaylr> | i need a better test word when trying to figure out how bikeshed works https://github.com/whatwg/compat/commit/2530dc6adcbd46f88f61c662501ff2ea81ba8ebf |
| 18:10 | <miketaylr> | >_< |
| 18:37 | <caitp> | so, what is the/an "associated url" of URLSearchParams? |
| 18:37 | <caitp> | a hack of URLs that have a reference to it? |
| 18:37 | <caitp> | hash* |
| 18:38 | <caitp> | "run these steps for each associated url object urlObject" --- i assume that's like a weakmap that gets added to on assignment or something |
| 18:56 | <caitp> | annevk: if you're still around, am I reading that right? we have this sort of URLSearchParams-looking polyfill in angular2, and if it's too complicated to actually polyfill correctly, or we end up wanting different behaviour, I'd like to clarify that asap |
| 19:34 | <annevk> | caitp: we will probably make it 1:1 instead |
| 19:34 | <annevk> | caitp: need to check if the change in Mozilla sticked around |
| 19:35 | <caitp> | but during the update step, any original search query stuck on the associated url is replaced right? |
| 19:36 | <annevk> | sure |
| 19:37 | <caitp> | Jeff Cross at google is saying that's probably not very good for our use cases, so i guess we can't leverage the native URLSearchParams if available :( oh well |
| 19:38 | <annevk> | caitp: he should file an issue against the URL spec |
| 19:38 | <annevk> | caitp: if it's not meeting someone's needs I'd like to know |
| 19:41 | <caitp> | maybe another method like URLSearchParams.prototype.append(urlSearchParams) { /* update current fields with new ones or different ones */ } might work better for us, we could probably leverage that |
| 19:41 | <caitp> | anyway I'll let him know he can file |
| 20:14 | <TabAtkins> | caitp: Note the possible semantic confusion - when there's a collision, are you adding your values, or replacing them? |
| 20:14 | <caitp> | yeah, i renamed that idea to .merge() in PM with jeff |
| 20:15 | <TabAtkins> | So adding? |
| 20:16 | <caitp> | that's a hard semantic to really figure out :| |
| 20:16 | <TabAtkins> | Because there's no single right answer! |
| 20:17 | <TabAtkins> | Thus why MultiMaps expose API for manipulating their values as a list *or* as a single value, depending on what your particular model is for the keys. |
| 20:17 | <caitp> | but the primitive of doing it manually by iterating over each field and deciding on a key by key basis, kind of sucks too |
| 20:19 | <TabAtkins> | Yeah, sure. Just means that we need *two* update methods (like we have .set() and .append(), and .get() and .getAll()) with names that suggest the right behavior as clearly as possible. |
| 20:19 | <TabAtkins> | Like updateReplace() and updateAppend() (using "update" because it's the Python name for the operation) |
| 20:22 | <caitp> | well, already got set/add/delete, how about merge(object, optionalSchema) :x |
| 20:25 | <TabAtkins> | You only listed a subset of the operations, and mixed the two modes together in doing so. I'm confused... |
| 20:26 | <TabAtkins> | We'd got get/set (for treating it as a Map) and getAll/append (for treating it as a MultiMap). has/delete work the same in either type, so they're not duplicated. |
| 20:26 | <TabAtkins> | So for merging in another map, you need both a Map version (replaces collisions) and a MultiMap version (appends collisions). |
| 20:28 | <caitp> | so, if one key in your Map has a List value, and another key in your Map has a String value, you may want to append to one, and replace the other |
| 20:28 | <TabAtkins> | Then you have to do it manually, because you're being complicated. |
| 20:30 | <caitp> | well it is complicated, but nobody would want to write instructions for multiple query parameters that need to be merged with some default query parameters specified somewhere else, if they could simply write up a frozen schema and just reuse it, right? |
| 20:30 | <caitp> | that seems more friendly |
| 20:31 | <TabAtkins> | It's quite trivial to package that up yourself in a method on your own, so you just have to pass in the two maps and get the result. I don't think there's enough call for "mixed" maps to justify specifying a schema, *particularly* not if you're suggesting using that *instead of* providing the two simple Map/MultiMap variants. |
| 20:32 | <caitp> | alright, not a fan of the idea, I get that =) |
| 20:33 | <TabAtkins> | It's super easy to write a function that does this automatically based on whether the key ends in [], a la PHP, too. |
| 20:36 | <caitp> | yeah but there are problems with that :( certain php authors assume that every client and backend understands that notation |
| 20:37 | <caitp> | ah well, can't spend too much time on this discussion, but maybe someone who has more time to think it through will float a proposal at whatwg/url |
| 20:51 | <TabAtkins> | Yeah, I didn't mean it as some universal baked into a spec, just as something you could do within a project to enable a generalized function for merging url search params, rather than having to write individual ones for each different search param pattern, or write up a separate schema for each pattern. |