| 07:09 | <yoav> | annevk: to continue our discussion from last week, maybe I can simply modify step 3 in https://fetch.spec.whatwg.org/#concept-fetch to be based on destination rather than type |
| 07:09 | <yoav> | that would solve the preload case and help nudge us towards a future without `type` (without breaking other specs that may rely on type) |
| 07:11 | <annevk> | I'd rather we just fix it all in one go |
| 07:11 | <annevk> | I'm happy to help |
| 07:14 | <yoav> | OK |
| 07:15 | <yoav> | what about other specs that may rely on type? |
| 07:17 | <annevk> | yoav: we should probably submit PRs |
| 07:17 | <yoav> | ok, is there an index that tracks usage? (or should we just look around for them) |
| 07:18 | <annevk> | yoav: no index, though we should maybe add one in the source of Fetch as we find them |
| 07:18 | <annevk> | I found https://w3c.github.io/webappsec-csp/#effective-directive-for-a-request |
| 07:19 | <annevk> | https://w3c.github.io/webappsec-mixed-content/ |
| 07:19 | <annevk> | and HTML |
| 07:19 | <annevk> | I think that's it |
| 07:20 | <annevk> | https://w3c.github.io/webappsec-subresource-integrity/ uses destination, but not type |
| 07:21 | <annevk> | I guess we should note that it relies on destination |
| 07:21 | <annevk> | yoav: I'll file a tracking issue against Fetch |
| 07:21 | <yoav> | ok, thanks |
| 07:21 | <annevk> | yoav: and I'll work on the HTML patch |
| 07:22 | <yoav> | Thanks, I'll clean preload in the mean time |
| 07:35 | <annevk> | yoav: I found that we never aligned HTML with the change you made to Fetch... |
| 07:35 | <yoav> | hmm... |
| 07:35 | <annevk> | yoav: for <audio>, <video>, and <track> destination was still set to "media" |
| 07:35 | <annevk> | yoav: I hope we did end up testing that somehow |
| 07:36 | <yoav> | tested that change for preload, but not sure for HTML |
| 07:36 | <yoav> | looking |
| 07:39 | <yoav> | can't find an HTML test for that |
| 07:39 | <yoav> | also, IIRC last time I tried to test in SW based on Request.destination, it wasn't really implemented anywhere |
| 07:40 | <yoav> | but can try again (or add a failing test) |
| 07:41 | <annevk> | yoav: oh that's interesting, is .type implemented? |
| 07:41 | <yoav> | dunno |
| 07:42 | <annevk> | nope |
| 07:42 | <annevk> | Both are undefined for (new Request("about:blank")).type|destination |
| 07:42 | <annevk> | So I guess that means we can easily remove type |
| 07:42 | <annevk> | That simplifies matters |
| 07:43 | <yoav> | Regarding preload's https://w3c.github.io/preload/#link-element-extensions |
| 07:43 | <annevk> | Would still be good to have failing tests for destination I suppose, now we're double downing on that approach with rel=preload |
| 07:44 | <yoav> | I can easily remove the parts that use type, but there's nothing in HTML that replaces "When the resource is declared via the Link header field ([RFC5988]), the resource's as attribute is defined via the as link-extension target attribute. ([RFC5988] section 5.4)" |
| 07:45 | <yoav> | (or anything that maps the other attributes from WEBLINK to HTML) |
| 07:45 | <yoav> | and I'm not sure if this is needed or not |
| 07:46 | <annevk> | I suspect the HTTP Link header is rather poorly defined for things defined in HTML too |
| 07:46 | <annevk> | E.g., nothing really says how that header works for rel=stylesheet |
| 07:46 | <yoav> | yup |
| 07:47 | <annevk> | I'd probably keep the text and maybe file an issue against HTML about providing better infrastructure for that |
| 07:47 | <yoav> | there's no mapping from the header to the attributes |
| 07:47 | <annevk> | For rel=stylesheet you need even more, as it also influences APIs and such |
| 08:25 | <annevk> | JakeA: can https://github.com/whatwg/fetch/issues/556 be closed? |
| 08:25 | <annevk> | JakeA: and https://github.com/whatwg/fetch/issues/554? |
| 08:51 | <zcorpan> | Hmm, this is curious. `<!DOCTYPE html SYSTEM""` sets force-quirks, but `<!DOCTYPE html SYSTEM""x` does not |
| 08:52 | <zcorpan> | not going to change it though |
| 11:43 | <JakeA> | annevk: done |
| 12:55 | <annevk> | belated ta! |
| 14:02 | <annevk> | Is GitHub slow for anyone else? |
| 14:02 | <annevk> | It also doesn't seem to update Travis at a reasonable speed |
| 14:05 | <tobie> | annevk: https://status.github.com/ |
| 14:05 | <tobie> | (i.e. yup) |
| 14:08 | <annevk> | ta |
| 14:21 | <annevk> | Oooh fun, Firefox Nightly is sticking with the doge logo |
| 14:21 | <wanderview> | JakeA: I wish MDN would just link to caniuse.com for API stability info... it seems to be more reliable and a better measure of "experimental" status |
| 14:22 | <wanderview> | annevk: I just wish they would stop changing the icon... its fun but too much gets a bit annoying |
| 14:22 | <JakeA> | Yeah, agreed! |
| 14:23 | <annevk> | wanderview: it's still the same icon in the doc here on macOS |
| 14:23 | <wanderview> | JakeA: or maybe make out "experimental" thing link to a "this a w3c spec related thing on MDN" explainer and also provide a caniuse.com link |
| 14:23 | <wanderview> | ^out^our |
| 14:24 | <annevk> | wanderview: though in Spotlight I get the old logo |
| 14:24 | <annevk> | messy |
| 14:24 | <wanderview> | annevk: I just mean how it went from old nightly -> new nightly -> calvin+hobbes -> firefox 0.8 -> firedoge in the space of a few weeks |
| 14:25 | <annevk> | wanderview: ah yeah, I saw that on Twitter, though never really noticed it happening |
| 14:25 | <wanderview> | we should have an opt out if we are going to do this sort thing |
| 14:25 | <annevk> | wanderview: I only noticed the change to new Nightly as that ended up changing the icon on the doc |
| 14:25 | <wanderview> | although I can see how that would be hard |
| 14:25 | <annevk> | wanderview: maybe I need to reboot or some such for icons to update so often? |
| 14:26 | <beverloo> | annevk: qq for the push api, would we want to define [SecureContext] on the event types as well, given that them being limited to secure contexts is implied by them only being available on the SW global scope? |
| 14:26 | <wanderview> | annevk: I think its hit or miss whether it replaces your dock icon unless you stop and restart firefox... I think the dock keeps it cached or something |
| 14:26 | <annevk> | beverloo: the events already have Exposed=ServiceWorker? |
| 14:26 | <beverloo> | yes |
| 14:26 | <annevk> | beverloo: in that case it's a no-op, but might as well for clarity |
| 14:27 | <annevk> | wanderview: well starting Fx happens all the time due to updates |
| 14:27 | <annevk> | wanderview: restarting* |
| 14:28 | <wanderview> | annevk: yea, just saying I had to explicitly quit firefox and restart to get some icon updates... but only on my mac |
| 14:28 | <beverloo> | annevk: cool, thanks! I also notice that we have [Exposed=(Window,Worker)] on our ServiceWorkerGlobalScope extensions, lol, that needs to go |
| 14:28 | <annevk> | beverloo: if you really want to drive it home file an issue against heycam/webidl to get a statement on the matter, it seems like something we need to decide on although it might be hard to find enough people who care |
| 14:29 | <annevk> | beverloo: yeah that seems buggy 😃 |
| 14:29 | <beverloo> | sure, will do! |
| 14:30 | <annevk> | wanderview: oh that's different from restart to update? |
| 14:36 | <wanderview> | I guess? I don't know much about mac integration stuff |
| 14:42 | <wanderview> | annevk: I guess I would settle for another icon update for this: https://twitter.com/mart3ll/status/899637173682622468 |
| 15:09 | <wanderview> | I should really avoid commenting on spec issues while I'm still drinking coffee... |
| 16:32 | <tobie> | ^ me at least three times a week. |
| 16:32 | <tobie> | Am I the only one finding the phrase "the construct is not available only in secure contexts" hard to parse? |
| 16:45 | <tobie> | beverloo, annevk : would the [SecureContext] / [Exposed] issue still be a thing if we flipped [SecuredContext] around to [AllowInNonSecureContext]? |
| 16:45 | <beverloo> | tobie: I think that'd more accurately reflect our intentions of pushing https, but there's a whole bunch of legacy specs that we'd never be able to update.. |
| 16:46 | <beverloo> | the vast majority of things has no reason to be secure context only, too |
| 16:46 | <tobie> | beverloo: that's a good point. |
| 16:48 | <annevk> | Anything that can be should imo |
| 16:48 | <annevk> | HTTPS carrots ftw |
| 16:49 | <annevk> | Or sticks, depending on your pov |
| 16:49 | <tobie> | beverloo: I guess the question wrt to those APIs you mentioned is whether they'd need to be secured if they were suddenly exposed in an new global interface that wasn't https by default. |
| 16:51 | <beverloo> | tobie: unlikely as that may be (why would we introduce new non-secure context-only globals at this point?), it's a good point as it may impact a lot of assumptions |
| 16:54 | <annevk> | I wonder if all worklets are [SecureContext], I hope so... |
| 16:57 | <tobie> | annevk: https://github.com/w3c/css-houdini-drafts/issues/92 "this seems overdue" |
| 16:58 | <beverloo> | from the PR (#379): ""Specifications which use worklets should decide if their worklet(s) should be allowed outside SecureContexts"" |
| 17:03 | <tobie> | beverloo: so the thing is we can't add a clause that says that if something is exposed in a SW, then it must be secure context only elsewhere. |
| 17:05 | <tobie> | beverloo: (as it would make secure context only in Window, stuff you would add to SW) |
| 17:06 | <tobie> | beverloo: so your options are basically (1) mark all Exposed=SW APIs also as [SecureContext] (2) mark only the ones that do represent as security concerns as [SecureContext] (3) consider these APIs won't ever be exposed elsewhere and not do anything. |
| 17:07 | <tobie> | beverloo: I think (1) is probably the cheapest and most forward-looking thing to do. |
| 17:11 | <tobie> | beverloo: I'm having the hardest time parsing my own comments above. Sorry about that. |
| 17:16 | <tobie> | beverloo: so without considering the unlikely case that we introduce a new non-secure context, you might have the case where you start adding an API to SW and then want to move it to workers or window. For example, I think that's what happened with fetch, caches, etc. |
| 17:19 | <tobie> | beverloo: unless you've added a [SecureContext] extended attribute to such APIs, you have to remember doing a privacy/security assessment when you expose those elsewhere. |
| 17:30 | <beverloo> | tobie: I agree with (1), too |
| 17:30 | <beverloo> | looks like we found enough arguments to warrant being explicit, even though it's repetitive (and hopefully will be even more repetitive in the future) |
| 17:31 | <tobie> | yeah, I guess the other option is to switch the extended attribute around |
| 17:31 | <tobie> | Note we have a plan to do that for Exposed. We could do both at the same time |
| 17:32 | <tobie> | beverloo: see: https://github.com/heycam/webidl/issues/365 |
| 17:35 | <beverloo> | Ack, sounds good to me. I like making [Exposed] mandatory, we've had some bugs in the past where interfaces accidentally were not exposed on all global scopes they should've been |
| 20:52 | <TabAtkins> | annevk, Domenic: For MultiMaps, a non-existent key should still return undefined from getAll(), right? Same as .get()? (Rather than returning `[]`.) |