| 10:56 | <annevk> | JakeA: we need some new terms for service workers |
| 10:56 | <annevk> | JakeA: when request's destination is "unknown", the service worker needs to be skipped |
| 10:56 | <annevk> | JakeA: when it's "subresource", the service worker is selected based on the client |
| 10:57 | <annevk> | JakeA: when request's destination is any other value, the service worker is selected based on the request's url |
| 10:57 | <JakeA> | Makes sense |
| 10:58 | <annevk> | JakeA: we used to call this last one "client request", but does that still make sense if it includes NEL and CSP reports? |
| 10:58 | <annevk> | (and downloads) |
| 11:00 | <JakeA> | annevk: agreed, describing it in terms of destination makes more sense. Although I'm still not totally sure if CSP reports are "of the page" or not |
| 11:00 | <annevk> | If they're not they could become a subresource, but it doesn't really resolve the naming issue |
| 11:00 | <annevk> | Assuming we want to have names |
| 11:01 | <JakeA> | Since CSP can block "client" requests, I guess they're not of the page |
| 11:01 | <JakeA> | (of the client, I mean) |
| 11:01 | <JakeA> | So the system works |
| 11:01 | <JakeA> | "" is an acceptable destination |
| 11:02 | <annevk> | Sure, but my question is what we should do with "client request" as a term |
| 11:02 | <annevk> | And "navigation request" |
| 11:02 | <annevk> | Etc. |
| 13:04 | <annevk> | JakeA: are you explaining microtask vs compound microtask, too? |
| 13:04 | <JakeA> | annevk: I wasn't, but probably because I don't understand it myself |
| 13:04 | <JakeA> | I could |
| 13:06 | <annevk> | JakeA: I just know I need the latter for mutation observers... I forgot why it has that setup |
| 13:06 | <annevk> | JakeA: aklein knows and explained it to me once |
| 13:06 | <JakeA> | annevk: just saw the other messages, we could get rid of "client request" and "navigation request" and instead describe them in terms of destination |
| 13:06 | <annevk> | JakeA: I have some kind of solution for that already |
| 13:07 | <annevk> | JakeA: it's "non-subresource request" |
| 13:07 | <annevk> | JakeA: not super elegant, but it'll do |
| 13:07 | <JakeA> | Seems fine to me |
| 14:11 | <annevk> | JakeA: is https://github.com/whatwg/fetch/issues/79 going to result in a change to the Cache API? |
| 16:22 | <JakeA> | annevk: yeah, I think the same-origin restriction seems reasonable |
| 16:22 | <JakeA> | (sorry that reply took so long) |
| 16:24 | <annevk> | JakeA: hmm, that's not the one I hoped for |
| 16:25 | <annevk> | JakeA: I was hoping that if we the request has redirect mode not to follow and the cache only has a redirected response, it returns failure |
| 16:25 | <JakeA> | annevk: oh, wait, you're right |
| 16:25 | <JakeA> | yeah, it won't need a change |
| 16:25 | <JakeA> | sorry |
| 16:25 | <JakeA> | I should think more |
| 16:25 | <annevk> | You mean Fetch doesn't need a change, but the Cache API does? |
| 16:26 | <JakeA> | No, cache doesn't need to change, "same-origin" navigations are enough |
| 16:27 | <annevk> | Hmm. I thought we wanted to allow CORS responses for those in theory? |
| 16:27 | <annevk> | I do anyway |
| 16:27 | <JakeA> | I think this is a good reason not to |
| 16:27 | <annevk> | Seems rather arbitrary |
| 16:27 | <annevk> | I think this is a good reason to not make the Cache API return something different from the fetch() API |
| 16:31 | <JakeA> | annevk: not sure what you mean |
| 16:32 | <JakeA> | This bug can be fixed by a same-origin restriction in cache, or enforcing same-origin for navigations in fetch. In both cases, you could take a CORS response, read the data & make a synthetic response to circumvent the limitation |
| 16:33 | <annevk> | What about my solution? |
| 16:34 | <annevk> | What I mean is that the Cache API not respecting RedirectMode seems like a bit of a bug |
| 17:42 | <wanderview> | annevk: JakeA: whatever happened to the idea of requiring SW scripts to be 'use strict'? |
| 18:21 | <jsbell> | wanderview: https://github.com/slightlyoff/ServiceWorker/issues/294 captures most of it, I guess. |
| 18:22 | <wanderview> | ok, thanks |
| 18:44 | <annevk> | wanderview: I think that failed |
| 18:45 | <annevk> | wanderview: we need something like module:true at some point |
| 18:49 | <wanderview> | annevk: ok... I was more just verifying we should not be treating script warnings as hard failures in the SW script... currently gecko does that |
| 18:50 | <annevk> | wanderview: what is a script warning? |
| 18:50 | <annevk> | wanderview: sounds bogus |
| 18:50 | <wanderview> | annevk: function f() { return 1; return 2; } |
| 18:50 | <wanderview> | legal js, but we generate a warning |
| 18:51 | <wanderview> | I believe |
| 18:51 | <annevk> | that doesn't even throw with "use strict" afaict |
| 18:52 | <annevk> | wanderview: so yeah, we shouldn't do that |
| 18:52 | <wanderview> | right |
| 18:59 | <Domenic> | yeah that's a devtools thing basically |
| 19:32 | <wanderview> | Domenic: whats really awesome is that because of this bug we can't load asmjs stuff in service worker scripts... because it "logs" success messages as "warnings" |
| 19:32 | <Domenic> | oh wow that is fun |
| 19:39 | <annevk> | wanderview: so much wrong :-/ |
| 19:40 | <wanderview> | annevk: Its a one-line fix thankfully |
| 20:14 | <JosephSilber> | TabAtkins, when nesting two `flex-direction: column` containers in a `flex-direction: row` container, the innermost flex items seem to overflow the innermost container. |
| 20:14 | <JosephSilber> | http://codepen.io/anon/pen/oXOYNz?editors=110 |
| 20:14 | <JosephSilber> | Is that right? I have an app that I haven't touched in months. It used to work as expected, but doesn't now. |
| 20:15 | <TabAtkins> | JosephSilber: That's the min-height:auto triggering. |
| 20:15 | <TabAtkins> | Set min-height:0 to make it not expand too large |
| 20:15 | <JosephSilber> | TabAtkins, In that example, I would expect the list to scroll, since it should stop at the boundry of its container. |
| 20:15 | <JosephSilber> | min-height makes it spill over? |
| 20:16 | <TabAtkins> | Yeah, it forces it to a minimum height equal to its natural height. |
| 20:16 | <JosephSilber> | Which element needs the min-height:0 |
| 20:16 | <JosephSilber> | ? |
| 20:16 | <TabAtkins> | The column |
| 20:17 | <JosephSilber> | Why does it only happen in triple-nested flex containers like that? |
| 20:17 | <JosephSilber> | TabAtkins, it doesn't happen here: http://codepen.io/anon/pen/mJgOeB?editors=110 |
| 20:18 | <JosephSilber> | Only when I wrap it in an additional flex container with a perpendicular axis. |
| 20:30 | <TabAtkins> | It does happen, but overflow is complicated and hard to debug. |
| 20:31 | <TabAtkins> | In that case you're specifying the height on the containers, so the min-width adjusts to that. |
| 20:31 | <TabAtkins> | But when they're perpendicular, if often doesn't have a definite-height container any more. |
| 20:31 | <TabAtkins> | So the min-height is full-powered. |
| 20:36 | <JosephSilber> | hmmmmmm. |
| 20:36 | <JosephSilber> | Like you said, complicated. |
| 20:37 | <JosephSilber> | :) |
| 20:39 | <TabAtkins> | It turns out to be complicated no matter what. :( Before we did min-height:auto, flexboxes did visible overflow constantly and it was really hard to debug which one was the problem. |
| 23:20 | <gsnedders> | NetVC is aiming at WebRTC and similar things, right? who has (and hasn't) expressed an interest in it? |
| 23:20 | <gsnedders> | I presume it's mostly the normal crowd (Moz, Goog, Op) |