| 09:38 | <jgraham> | smaug____: There are also magical directories |
| 09:40 | <smaug____> | jgraham: is there a list of those directories somewhere? |
| 09:40 | <jgraham> | smaug____: support, resources, and tools |
| 09:40 | <jgraham> | I'm not sure if that's in the docs |
| 09:41 | <jgraham> | (but if you are trying to add testharness.js to a non-test file, I'm interested in what the use case is) |
| 09:45 | <smaug____> | jgraham: this is a patch in my review queue. Some test file will do location.href = resource/foo.html |
| 10:00 | <jkt_> | annevk: In https://github.com/whatwg/html/issues/2635 you mentioned it would be easier with COOP is there anything else blocking this? |
| 10:05 | <annevk> | jkt_: I don't think so, apart from us not really having formalized user-initiated navigations |
| 10:13 | <annevk> | JakeA: so Chrome's behavior is a bit weird; it doesn't follow redirects across origins, but it does follow them within the same origin and as long as the final URL is identical to the URL determined to be the final URL in the initial request it will continue doing range requests |
| 10:14 | <annevk> | JakeA: it would be a lot easier I think if we just forbid redirects, but maybe some site really does rely on that Chrome oddity? |
| 10:34 | <jkt_> | annevk: right makes sense :) |
| 10:35 | <JakeA> | annevk: Hmm, the Chrome behaviour allows for content negotiation on the server then redirecting to the appropriate media file |
| 10:35 | <JakeA> | Although I don't know if this is used in the wild |
| 10:36 | <JakeA> | Allowing redirects after the first response seems unnecessary though |
| 11:32 | <JakeA> | annevk: I'm working on speccing 'navigable', a thing that can be navigated. When describing "parent navigable", would it be better to write it as a getter, something like "the parent navigable is navigable that contains a session history item that has a document which contains an iframe which uses this navigable", or is it better to give the navigable a "parent navigable" concept, and manage this state as it changes? |
| 11:32 | <JakeA> | I usually do the latter, but it seems like the HTML spec does a lot of the former |
| 11:32 | <JakeA> | but maybe that's legacy |
| 11:34 | <JakeA> | It's kinda hand-waved for browsing contexts "A browsing context child may have a parent browsing context. This is the unique browsing context that has child as a child browsing context, if any such browsing context exists. Otherwise, the browsing context has no parent browsing context." |
| 12:30 | <annevk> | JakeA: I would prefer the latter |
| 12:31 | <annevk> | JakeA: I don't think Chrome allows for that, because if you redirect to the appropriate file you'd have a mismatched URL with the initial final URL and Chrome would error at that point |
| 12:31 | <annevk> | JakeA: ah yeah, this is primarily about redirects after the first response |
| 12:32 | <JakeA> | ta! |
| 14:50 | <annevk> | yoav: hey I thought rel=prefetch was for navigations |
| 14:50 | <annevk> | yoav: I see google.com has a single rel=prefetch entry and it tries to obtain https://apis.google.com/js/api.js |
| 14:51 | <annevk> | oh wait, I guess it was also resources the next document might use |
| 14:52 | <yoav> | yeah, resources for the next document are also legit, although cross-site ones may not survive the cache partitioning |
| 14:54 | <annevk> | yoav: as long as the partition is the same cross-origin resources would work, but google.com prefetching the first three search result documents is not a thing that would work anymore, indeed |
| 14:56 | yoav | nods |