| 12:21 | <Ms2ger> | annevk, I'm trying to spec the suggestion in https://github.com/whatwg/html/pull/4571#discussion_r373270764 but it seems like the "runnable" check in step 2 of https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model will break the latter case |
| 12:21 | <Ms2ger> | Thoughts? |
| 12:27 | <annevk> | Ms2ger: not really, I see bz left a number of comments there that appear unaddressed as well |
| 12:28 | <Ms2ger> | Like what? Entry globals are defined, incumbent is explicitly marked as no consensus, and everything else is about dealing with documents that are not "fully active", afaict |
| 12:29 | <annevk> | Ms2ger: about confirming what is implemented |
| 14:20 | <annevk> | JakeA: https://github.com/whatwg/html/issues/5484#issuecomment-620015579 I don't see how this works given that discarding is currently synchronous, involves script execution, etc. |
| 14:20 | <annevk> | JakeA: websites will rely on that |
| 14:20 | <annevk> | JakeA: and engines do too |
| 14:22 | <JakeA> | annevk: fwiw, I was thinking about this more for <portal>, so there wouldn't be a backwards compatibility issue there. I suppose there could be <iframe keepalive> or something |
| 14:22 | <annevk> | JakeA: well, it depends on how much logic from frames is reused internally |
| 14:23 | <annevk> | JakeA: I'm guessing <portal> doesn't define browsing context et al from scratch |
| 14:23 | <annevk> | JakeA: but removal is much more involved than that |
| 14:24 | <JakeA> | annevk: I haven't thought too much about this, but my feeling is iframe & portal should extend something common, in the way audio & video have a common ancestor |
| 14:24 | <annevk> | JakeA: as Ryosuke noted multiple elements can be removed at once, script will execute (ideally from a queue as discussed in the various linked PRs) |
| 14:24 | <JakeA> | annevk: what kind of script are we talking about here? Unload? |
| 14:25 | <annevk> | Yeah, though I'm not sure if that's the full extent of things; again, the status quo is not defined and not interoperable |
| 14:25 | <annevk> | First it has to be defined before you can realistically make a change here as otherwise too much will be unclear |
| 14:26 | <annevk> | I recommend reading the issue I linked and perhaps encourage people on Chrome to help solve it as thus far it's been somewhat tricky to get interest from browsers |
| 14:31 | <JakeA> | Yeah, I'm reading through it, the script execution bit just wasn't clear to me |
| 14:33 | <annevk> | I think the basic problem is also clear without that, in that you remove the iframe, but it still has a browsing context and so a bunch of things that branch on that break down because it has a browsing context but it's not in the tree, etc. |
| 14:33 | <annevk> | The only way to get rid of that is by having an atomic move operation |
| 14:34 | <annevk> | And even then it might be tricky given rniwa's comments, though I'm not sure to what extent those things still apply with atomic move |
| 14:34 | <annevk> | It's kind of hard to imagine they do, but who knows |
| 14:35 | <JakeA> | I'll need to dig into the issues more. Bfcache pages seem to survive going away & coming back, so it feels like there's some kind of mechanism. |
| 14:36 | <annevk> | JakeA: that's top-level browsing contexts only and I think only those without reference to them |
| 14:38 | <annevk> | JakeA: not entirely sure about no reference though, that'd be good to confirm |
| 14:38 | <JakeA> | seems likely tbh |
| 14:39 | <JakeA> | Any idea which APIs rely on their nested browsing context's iframe being connected? Or, an example of one |
| 14:41 | <annevk> | Also that too is undefined |
| 14:41 | <annevk> | Gotta stop with swamp-based designs |
| 14:42 | <annevk> | JakeA: maybe search for discard? There’s a bunch I wrote tests for a while back, but I don’t recall offhand |
| 14:42 | <JakeA> | In wpt, or html issues? |
| 14:42 | <annevk> | That too = bfcache |
| 14:43 | <annevk> | In HTML itself; things like .parent or .frameElement iirc |
| 14:47 | <JakeA> | From a quick scan, `.parent` relies on getting the iframe's document, which should still be correct. But yeah, I'm sure there's stuff that doesn't work. |
| 15:35 | <Ms2ger> | MikeSmith, I noticed that https://www.w3.org/TR/dom/ redirects to dom.s.w.o, but https://www.w3.org/TR/domcore/ doesn't. Is that intentional? |
| 18:32 | <Domenic> | TabAtkins: is https://github.com/tabatkins/highlighter/ Python3 friendly? |
| 18:32 | <TabAtkins> | Ooh, good question. Probably not, but I'm happy to update. |
| 18:34 | <Domenic> | That'd be nice; we've got some html-build issues |
| 18:34 | <TabAtkins> | np, i'll see if i can work on that today |