| 07:39 | <domfarolino> | annevk: (I already commented about this on GH, sorry for the redundancy, but) I'm curious..do you think deferred iframes should not refer to the document-causing-the-navigation at their eventual-load time? |
| 07:41 | <domfarolino> | Ohh. I think you're saying the way it would be spec'ed sounds like the iframe would reference a snapshot of the document's state |
| 08:09 | <annevk> | domfarolino: I think we should snapshot at navigation time generally, however here that should prolly be at attribute processing time as navigation would happen at a “weird” time |
| 08:35 | <annevk> | Hmm https://github.com/tc39/proposal-intl-displaynames/issues/32#issuecomment-510637281 |
| 09:14 | <annevk> | MikeSmith: re https://github.com/whatwg/misc-server/pull/99 what I don't get is why we need a new file |
| 09:14 | <annevk> | MikeSmith: I'm not sure the current setup where the file named redirects contains the Content-Disposition information too, which isn't a redirect afaik |
| 09:15 | <annevk> | MikeSmith: or the 410 gone data |
| 09:45 | <domfarolino> | annevk: I’m wondering what might get us the closest behavior to existing lazy loading libraries. For example, JS-based lazy loading tools I think are likely to “insert” an iframe into the DOM just when it should be loaded, therefore attribute parsing and navigation is kicked off then. I feel like in the PR, deferring _everything_ buys us behavior closest to that, which IMO is intuitive and may match developer |
| 09:45 | <domfarolino> | expectations. Does that make sense? |
| 09:46 | <annevk> | domfarolino: it's not clear to me why copying state at a non-deterministic point is better |
| 09:46 | <annevk> | domfarolino: it's clear why you might arrive at such a compromise in a polyfill, but this isn't that |
| 09:47 | <domfarolino> | annevk: you’re saying it’s non-deterministic because we’re essentially asynchronously waiting for our navigation conditions to be met? |
| 09:48 | <annevk> | domfarolino: yeah, it depends on something rather unrelated |
| 09:48 | <domfarolino> | > “it’s clear why you might arrive ... |
| 09:49 | <domfarolino> | True |
| 09:51 | <domfarolino> | annevk: Hmm. Would it be possible to wait for those conditions and then queue a task to start the navigation? |
| 09:52 | <domfarolino> | I see your concern though...I just wonder if it would be a gotcha |
| 09:52 | <annevk> | domfarolino: that's your proposed setup already (if it doesn't queue a task that's a bug) |
| 09:52 | <domfarolino> | annevk: it’s not explicit about it I believe. Probably should be |
| 09:52 | <domfarolino> | Could be wrong, Ben wrote those bits and I haven’t looked carefully |
| 09:52 | <annevk> | yes, but it's not a solution to this problem |
| 09:59 | <domfarolino> | I guess I don't entirely see it as a problem, but I definitely see what you're saying |
| 10:01 | <annevk> | domfarolino: you'll end up with weird cases where if the user does something that causes the URL to change scrolling to the thing might break some subtle thing |
| 10:12 | <domfarolino> | annevk: I see how that can happen, I'm just wondering if it won't, because of how developers already think about lazy loaded content (i.e., they may already expect the current state of the document to be the "source of truth" for an iframe lazily inserted) |
| 11:30 | <annevk> | domfarolino: sure, if you manage when to load it yourself, but that's not the case here and there's no callback either |
| 14:42 | <JakeA> | Is it fine to say some internal state is an enum? As in: A {{Foo}} object has an associated <dfn for="Foo">internal thing</dfn> which is an {{EnumOfSorts}}. Then later, the <dfn for="Foo" attribute>thing</dfn> getter must return the context object's [=Foo/internal thing=]. |
| 14:42 | <JakeA> | Or must the internal definition duplicate the values of the enum? |
| 14:44 | <JakeA> | For instance: https://fetch.spec.whatwg.org/#concept-request-credentials-mode vs https://fetch.spec.whatwg.org/#dom-requestinit-credentials. Could both of these reference the same enum? |
| 14:53 | <annevk> | JakeA: it should probably be okay |
| 15:01 | <JakeA> | annevk: cheers! |