| 07:52 | <annevk> | JakeA: so what do about canceling promises now? |
| 07:53 | <annevk> | JakeA: seems Domenic had to abandon given some Google-internal struggles, but fetch() is still without termination |
| 07:56 | <annevk> | felixjet: legend means definition |
| 07:56 | <JakeA> | annevk: I think we should leave the dust to settle on this (until Jan?), but I guess we provide a method to reject with an AbortError :( |
| 07:56 | <JakeA> | annevk: I need to catch up a bit and see if tokens are similarly doomed |
| 07:57 | <annevk> | felixjet: using data-* instead of class is fine |
| 07:58 | <annevk> | JakeA: if this is on Request objects we will need to redesign how they work |
| 08:00 | <JakeA> | annevk: we already pass the stream from object to object, wouldn't we just pass a token along as well? |
| 08:02 | <annevk> | JakeA: yeah I guess |
| 08:02 | <JakeA> | annevk: along with the mechanism, need to figure out "does [solution] error the request only, or the response too?" |
| 08:02 | <JakeA> | annevk: I posted on the centithread btw |
| 08:02 | <annevk> | JakeA: I think I'd still like to figure out if we can prevent copying Request sometimes |
| 08:02 | <annevk> | JakeA: oh my |
| 08:54 | <MikeSmith> | can somebody remind me: custom elements can only be used in text/html, right? |
| 08:57 | <annevk> | MikeSmith: I thought they'd work in XML too |
| 08:57 | <annevk> | MikeSmith: I don't remember a lot of text/html special casing, but I'm not entirely sure |
| 09:00 | <MikeSmith> | Ok |
| 10:06 | <JakeA> | annevk: https://github.com/whatwg/notifications/pull/89/files - Bikeshed turns Note: into <p class=note> automatically, or are you wanting to be explicit about it? |
| 10:07 | <JakeA> | annevk: also, not sure I understand the indenting stuff - it isn't indented on master https://github.com/whatwg/notifications/blob/master/notifications.bs#L382 |
| 10:09 | <annevk> | JakeA: oh, it seems it's all inconsistent :/ |
| 10:09 | <JakeA> | annevk: but the stuff in the PR is how you'd like it from now on? |
| 10:30 | <zcorpan> | MikeSmith: i think they should work in XML too but it's limited to HTML elements |
| 10:58 | <annevk> | JakeA: I'll fix the remaining nit in that PR with respect to indenting |
| 10:59 | <annevk> | JakeA: oh, you fixed some of that |
| 10:59 | <JakeA> | annevk: lmk if it's wrong (for my own learnings) |
| 11:00 | <annevk> | JakeA: that resource is super inconsistent; my usual style is one-space indentation |
| 11:00 | <annevk> | JakeA: and you missed the first <li>, but I'll do a pass |
| 11:00 | <JakeA> | ah, balls |
| 11:01 | <JakeA> | annevk: http://editorconfig.org/ is kinda useful when it comes to indenting & wrapping |
| 11:14 | <JakeA> | annevk: why go headers use byte sequences? Because they're not unicode? |
| 11:15 | <annevk> | JakeA: basically |
| 11:15 | <JakeA> | ta |
| 11:15 | <annevk> | JakeA: various programming languages represent them in different ways, but they're effectively bytes |
| 11:16 | <annevk> | JakeA: although I suppose we could use the ASCII string abstraction we use for URLs too |
| 11:17 | <annevk> | JakeA: any rejiggering of that though will have to wait until the HTTP community decides what they want them to be |
| 11:17 | <robertkowalski> | annevk: question to the url spec |
| 11:17 | <robertkowalski> | before i open an issue / invetsigate further |
| 11:18 | <robertkowalski> | new URL('https://rocko:pass#word⊙ec/blerg';) |
| 11:18 | <robertkowalski> | throws because of the hash |
| 11:19 | <robertkowalski> | i haven't found a section regarding passwords and special / reserved chars. is this a bug in the spec? it limits the amount possible passwords a lot |
| 11:20 | <nox> | robertkowalski: It should be encoded. |
| 11:20 | <annevk> | Yeah, you can encode it |
| 11:21 | <annevk> | robertkowalski: the specification basically doesn't want you to use URLs to encode username/password |
| 11:21 | <annevk> | robertkowalski: https://url.spec.whatwg.org/#url-syntax doesn't allow them |
| 11:21 | <annevk> | robertkowalski: (see note at the end of that section) |
| 11:22 | <annevk> | robertkowalski: the reason that throws though I think is because # is seen as the start of the path and then a host cannot contain : |
| 11:22 | <annevk> | robertkowalski: well, because :pass is not a valid port |
| 11:23 | <annevk> | robertkowalski: for that, see how https://url.spec.whatwg.org/#authority-state and also the host state will treat # as the end of that |
| 11:24 | <annevk> | robertkowalski: and https://url.spec.whatwg.org/#port-state for how port will return failure for non-digits |
| 11:27 | <robertkowalski> | thank you |
| 11:27 | <robertkowalski> | the replciator in couchdb accepts urls with hash as part of the password |
| 11:27 | <robertkowalski> | and when we pull them out and want to use them in the browser |
| 11:27 | <robertkowalski> | it explodes |
| 11:30 | <nox> | robertkowalski: new URL('https://rocko:pass%23word⊙ec/blerg';) |
| 11:31 | <robertkowalski> | ty nox - we run into a chicken egg problem here. as we use `new URL` to parse the URL ^^ |
| 11:31 | <robertkowalski> | so we probably have to fix that in the couch api, not in the frontend |
| 11:36 | <annevk> | robertkowalski: yeah, it sounds like the Couch DB API parses URLs differently from browsers |
| 11:36 | <annevk> | robertkowalski: that will cause subtle bugs |
| 12:20 | <zcorpan> | foolip: hmm https://travis-ci.org/w3c/web-platform-tests/jobs/184507619 |
| 12:21 | <foolip> | zcorpan: a timeout, or what is one to make of that? |
| 12:21 | <zcorpan> | foolip: not a testharness.js-level timeout |
| 12:22 | <foolip> | flaky infra? can one poke travis to try again? |
| 12:22 | <foolip> | If you're happy with the nit, I can just rebae or something to tickle it |
| 12:22 | <zcorpan> | i can try restarting the build |
| 12:23 | <zcorpan> | restarted |
| 12:32 | <foolip> | zcorpan: seems to have worked? |
| 12:38 | <zcorpan> | foolip: ya |
| 12:41 | <yoav> | annevk: in https://fetch.spec.whatwg.org/#concept-request-destination wasn't "track" its own destination, rather than "media"? If it changed, why did it change? |
| 12:44 | <annevk> | yoav: I'm not sure |
| 12:44 | <yoav> | git blame points to the bikeshed conversion :/ |
| 12:44 | <annevk> | yoav: I think when we changed how this worked we grouped them because CSP did? |
| 12:45 | <annevk> | yoav: the commit prior to Bikeshed just renames the files, should be doable to trace from there? |
| 12:45 | <yoav> | that makes sense from a CSP perspective, but doesn't correspond to how preload is implemented |
| 12:46 | <yoav> | yeah, I'll blame it to track the change |
| 12:46 | <yoav> | but currently hitting issues in Chrome's implementation of `type` for `as=media` |
| 12:46 | <yoav> | vtt is not a valid type |
| 12:47 | <yoav> | for media files |
| 12:47 | <annevk> | Hmm |
| 12:47 | <annevk> | Why can audio and video be grouped then? |
| 12:50 | <yoav> | both considered "media" internally |
| 12:50 | <yoav> | I guess you could argue that they shouldn't be |
| 12:50 | <yoav> | https://github.com/whatwg/fetch/commit/6b9cdaa9 |
| 12:51 | <foolip> | the media resource for audio/video elements is treated the same internally, quite differently from the vtt resources for track elements, so grouing audio/video but not track makes sense to me |
| 12:53 | <yoav> | foolip: from an implementation perspective or from a spec perspective? |
| 12:54 | <yoav> | So, I implemented as={video/audio/track}, then spec changed, but I failed to change impl for track (only changed it for video/audio) |
| 12:54 | <foolip> | yoav: both, https://html.spec.whatwg.org/multipage/embedded-content.html#concept-media-load-resource is shared for audio/video, and is different from https://html.spec.whatwg.org/multipage/embedded-content.html#concept-media-load-resource |
| 12:55 | <yoav> | foolip: same link twice, so I'm guessing the second was pointing at VTT loading |
| 12:55 | <foolip> | That being said, ungrouping into three categories would be fine two, but I guess that's not what you're discussing |
| 12:55 | <foolip> | yoav: https://html.spec.whatwg.org/multipage/embedded-content.html#start-the-track-processing-model |
| 12:55 | <foolip> | yoav: yes :) |
| 12:56 | <yoav> | foolip: I'm fine with leaving audio and video grouped, if it makes sense for non-Blink/Chromium implementations |
| 12:56 | <yoav> | but I'd like to split track into it's own destination (that maps to media-src in terms of CSP) |
| 12:57 | <yoav> | annevk: Thoughts? If OK by you, I'll spin up a PR |
| 13:02 | <annevk> | yoav: seems we agreed in https://github.com/whatwg/fetch/pull/211 to merge all |
| 13:07 | <yoav> | Yeah... not liking past me for https://github.com/whatwg/fetch/pull/211#issuecomment-181813238 |
| 13:07 | <yoav> | "probably also possible" |
| 13:08 | <annevk> | yoav: I think if we degroup we should also split audio/video |
| 13:09 | <annevk> | yoav: e.g., one thing we could do then is define an Accept header for those |
| 13:09 | <yoav> | true |
| 13:10 | <annevk> | foolip: so I thought we uncovered quite a few problems last we looked at the animation frame task stuff |
| 13:11 | <annevk> | foolip: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28876 is one |
| 13:11 | <yoav> | foolip: Thoughts on changing `as` values? I'm guessing we'd need UMA to see usage under "media" (or continue to support "media" after adding "video" and "audio") |
| 13:11 | <annevk> | foolip: and https://www.w3.org/Bugs/Public/show_bug.cgi?id=28001 in particular |
| 13:12 | <annevk> | yoav: the problem is that these values are also exposed to service workers |
| 13:12 | <yoav> | so exposed in two places? :| |
| 13:13 | <foolip> | yoav: I'm not really familiar with this stuff, but having media as a group for audio+video as well as them individually seems fine, if that's what you mean |
| 13:13 | <yoav> | foolip: Yeah, that's what I meant |
| 13:14 | <yoav> | to avoid potentially breaking content with `as=media` out there |
| 13:16 | <zcorpan> | drive-by fixes, knowing when to stop :-D https://github.com/w3c/web-platform-tests/pull/4353 |
| 13:16 | <foolip> | annevk: which bits of #28001 in particular? I think that Fullscreen could work without a queue of its own, and the timing of "enqueue animation frame task" would be right before the requestAnimationFrame callbacks for that same window, not a top-level thing |
| 13:16 | <foolip> | annevk: which makes things interesting for Fullscreen because we have to pick which document to use, and I think the one the request was on makes sense |
| 13:17 | <foolip> | annevk: unfortunately, if one wanted to use one task per document affected, then events would always fire in frame tree order, which isn't what we currently want for fullscreenchange events when exiting |
| 13:21 | <annevk> | yoav: https://fetch.spec.whatwg.org/#dom-request-destination |
| 13:23 | <annevk> | foolip: I don't know which of HTML or Fullscreen is wrong, but HTML is currently running the hook per-document |
| 13:23 | <annevk> | foolip: the event loop is I guess per unit of browsing contexts that can touch each other, though OOP <iframe> is making that much more complicated... |
| 13:24 | <yoav> | JakeA: around? Do you have a hunch on how many SW code relies on request.destination? |
| 13:24 | <yoav> | s/many/much/ |
| 13:25 | <foolip> | annevk: yes, cross-origin is still a bit of a mystery for fullscreen |
| 13:25 | <foolip> | annevk: currently Blink tries to do make the observable behavior the same as if everything was in the same process, but things can go wrong in funny ways |
| 13:27 | <annevk> | foolip: anyway, I guess what I meant was that figuring out what HTML should do there seems important |
| 13:27 | <foolip> | annevk: FWIW, I think one could make it all work with each document running their steps fullscreen individually and sacrificing event order on exit, but it'd all look quite different from now |
| 13:28 | <foolip> | the unpleasant part is what happens with fullscreen requests that then come in between those small chunks of applying a single requestFullscreen call |
| 13:28 | <foolip> | (with OOP <iframe> it becomes unfeasible to say that there can only be a single pending request globally) |
| 13:29 | <foolip> | If I had better imagination, maybe I could see how Fullscreen would have worked if designed with multi-process in mind. |
| 13:34 | <annevk> | foolip: okay with you if I merge the two if statements in https://github.com/whatwg/fullscreen/pull/68 into a single step? |
| 13:35 | <annevk> | foolip: since the consequences are the same we might as well OR it |
| 13:35 | <foolip> | annevk: sure, I kept them separate because I wanted to change on of them to resolve, but I can unmerge later if so :) |
| 13:36 | <annevk> | foolip: ooh, hmm, I guess unmerge later is better in case that doesn't end up happening |
| 13:36 | <foolip> | annevk: yep! |
| 13:44 | <annevk> | I think I finally completed my GitHub backlog |
| 13:45 | <annevk> | If anyone is waiting on me, let me know, since I missed it |
| 13:47 | <JakeA> | yoav: I don't think we support it in stable, so not a lot |
| 13:48 | <yoav> | that's great news! |
| 13:48 | <yoav> | Sounds like the exact right time to break it :) |
| 13:49 | <yoav> | JakeA: What do you think of breaking up the `media` destination into "audio", "video" and "track"? |
| 13:56 | <JakeA> | yoav: I think "type" already takes care of that |
| 13:56 | <JakeA> | yoav: https://fetch.spec.whatwg.org/#concept-request-type |
| 13:57 | <yoav> | JakeA: So, the issue is that <link preload as=media> as currently defined can mean video, audio or track |
| 13:58 | <yoav> | which now I realized is: a) not how I actually implemented b) causes impl problems in terms of internal resource type and "type" attribute support |
| 14:00 | <yoav> | so it'd make me happy if we could split the destination up (preload is using the destination values for `as` values) |
| 14:01 | <JakeA> | yoav: preload should be using "type" I think |
| 14:02 | <yoav> | type doesn't cleanly map to CSP directives |
| 14:02 | <JakeA> | hmm fair point |
| 14:09 | <JakeA> | yoav: I'm struggling to work out the distinction between type/destination now |
| 14:11 | <yoav> | Dunno, seems to be related to content sniffing & mime type blocking |
| 14:13 | <yoav> | so, iiuc (and annevk will probably correct me) type is related to the expected resource type while destination is related to where that resource will be used |
| 14:15 | <annevk> | yoav: yeah, roughly |
| 14:15 | <annevk> | yoav: it's clearest with script |
| 14:15 | <yoav> | yeah, that's the only point I see where there a clear 1 type => many destinations |
| 14:19 | <annevk> | I could see something similar happening for "image", but I think we care less about the destinations |
| 14:28 | <yoav> | annevk & JakeA: I think I'll send a PR changing all "media" to their relative types and we can further discuss it over there |
| 14:52 | wanderview | tries to formulate Client questions for Jake earlier in the day... |
| 14:56 | <wanderview> | JakeA: so... I'm trying to understand the case of the reserved Client during a navigation that is redirected |
| 14:57 | <wanderview> | looking at the html spec it seems we create a single reserved Client at step 7 of https://html.spec.whatwg.org/#process-a-navigate-fetch |
| 14:57 | <wanderview> | and then just keep that reserved client through the redirects at step 9 |
| 14:58 | <wanderview> | but we never update the URL on the reserved client |
| 14:59 | <wanderview> | so those FetchEvents for the redirected URLs will see the wrong URL on clients.get(evt.reservedClientId).then(client => client.url) |
| 14:59 | <wanderview> | right? |
| 14:59 | <wanderview> | JakeA: is that what we intend? ^^^ |
| 14:59 | <wanderview> | it would seem to me we should either create a new reserved client for each redirect step or update the url on the client |
| 15:01 | <wanderview> | although I guess we allow Client.url to be different in the cases where history.pushState() has changed the location |
| 15:01 | <wanderview> | I think that has to be same-origin, though |
| 15:02 | <wanderview> | in this case we may get a reserved Client with a cross-origin creation URL |
| 15:02 | <wanderview> | maybe thats ok since the FetchEvent.request.url will have the current URL |
| 15:02 | <wanderview> | anyway, just trying to clarify intent |
| 15:19 | <JakeA> | wanderview: huh, good catch. We don't want to create a new client, else you can't postMessage to it |
| 15:19 | <JakeA> | wanderview: I guess we should update the URL |
| 15:19 | <JakeA> | wanderview: but if it goes cross origin we need to make sure postMessage doesn't get delivered to it |
| 15:19 | <wanderview> | JakeA: I mean... do we want people to be able to observe the original URL that started the navigation? |
| 15:20 | <wanderview> | started the redirect chain |
| 15:20 | <wanderview> | JakeA: what is the use case for postMessage() to the reserved client across redirects? |
| 15:20 | <wanderview> | feels to my like it would be cleanest to not propagate postMessage() there |
| 15:32 | <wanderview> | JakeA: not updating the url would also mean that Client.ancestorOrigins[0] could be different from the origin of Client.url... I think that would be a bit unexpected |
| 15:33 | <annevk> | wanderview: did Client.ancestorOrigins land already? With bz objecting to its sibling feature elsewhere, it would be somewhat weird for us to ship that |
| 15:33 | <wanderview> | annevk: its in the spec AFAICT... https://w3c.github.io/ServiceWorker/#client-ancestororigins |
| 15:34 | <wanderview> | annevk: which builds on https://html.spec.whatwg.org/multipage/browsers.html#concept-location-ancestor-origins-array |
| 15:34 | <annevk> | wanderview: understood, but https://github.com/whatwg/html/issues/1918 (and prior issues) |
| 15:35 | <annevk> | wanderview: hence me wondering if we ship it one place and not another and bypassed bz somehow |
| 15:35 | <annevk> | wanderview: which would argue for using "Intent to ship" for more minor things I think |
| 15:35 | <wanderview> | annevk: we ship Location.ancestorOrigins in Firefox, but not Client.ancestorOrigins yet |
| 15:36 | <wanderview> | annevk: oh, we don't ship it |
| 15:36 | <wanderview> | its just in some tests |
| 15:36 | <annevk> | Okay, all good then |
| 15:37 | <annevk> | miketaylr: we forgot to actually discuss https://github.com/whatwg/dom/issues/334 |
| 15:49 | <wanderview> | JakeA: I wrote it up in an issue: https://github.com/w3c/ServiceWorker/issues/1031 |
| 16:03 | <JakeA> | Thanks! |
| 19:57 | <annevk> | Domenic: https://github.com/w3c/web-platform-tests/pull/4299 has some tests |
| 20:14 | <Domenic> | Ah excellent |
| 22:34 | <jsbell> | Dangit, https://github.com/whatwg/fetch/issues/332 bites again |
| 22:35 | <jsbell> | Well, that or my inability to see the "The definition of value needs serious work." warning. :P |