| 02:14 | <sideshowbarker> | emilio: (or anybody else who might remember) Do you recall how we ended up with the W3C being the home for the Intersection Observer work/spec — rather than WHATWG? |
| 06:24 | <annevk> | Domenic: zcorpan: either of you around to rs https://github.com/whatwg/html/pull/10260? |
| 06:45 | <emilio> | emilio: (or anybody else who might remember) Do you recall how we ended up with the W3C being the home for the Intersection Observer work/spec — rather than WHATWG? |
| 14:28 | <zcorpan> | Does location.reload() end up calling "navigate" somewhere? Or no? |
| 14:42 | <Noam Rosenthal> | it does not I believe, navigate is only for regular push/replace navigations ^ zcorpan |
| 14:43 | <Noam Rosenthal> | https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate 20.9 populates the history entry with type "navigate". when you traverse/reload you wouldn't do that |
| 14:44 | <zcorpan> | Noam Rosenthal: thanks. Yeah that's my conclusion as well, but stepping through the spec from reload() is not easy :) |
| 14:45 | <Noam Rosenthal> | zcorpan: yea, the "session history traversal queue" (aka the browser process in some implementations) is a very technical part of the spec. I get lost in it a lot |
| 14:49 | <zcorpan> | I'm working on tests for https://github.com/whatwg/html/pull/10226 - so reload or history traversal would not cancel the lazy load |
| 14:55 | <Noam Rosenthal> | zcorpan: that iframe will always be on the initial about:blank page, no? since it's lazy and hasn't been loaded yet? |
| 14:56 | <zcorpan> | Noam Rosenthal: I believe so |
| 14:58 | <Noam Rosenthal> | zcorpan: wondering what should be the behavior with same-document navigations. e.g. you pushState in that about:blank page before it's lazy-loaded |
| 14:59 | <Noam Rosenthal> | perhaps a safe-ish way to look at this is to cancel those steps when the about:blank page is about to be unloaded |
| 14:59 | <Noam Rosenthal> | though maybe that's too late for the replace case |
| 15:02 | <zcorpan> | Noam Rosenthal: the spec change only cancels lazy-load in "navigate", which should match Chromium. I think it's a sufficient fix. |
| 15:03 | <Noam Rosenthal> | zcorpan: This particular navigate in the PR is also for e.g. fragment navigations |
| 15:04 | <zcorpan> | Noam Rosenthal: yeah |
| 15:05 | <zcorpan> | My test for fragment navigation seems flaky in chromium, so maybe it doesn't exactly match |
| 15:07 | <Noam Rosenthal> | zcorpan: looking at the code for this in chromium I'm pretty sure we cancel lazy loading on any cross-doc navigation |
| 15:15 | <Noam Rosenthal> | yea I guess you'd want to do this whenever you abort a regular navigation |
| 15:18 | <zcorpan> | Noam Rosenthal: PR for my tests at https://github.com/web-platform-tests/wpt/pull/45650 |
| 15:22 | <Noam Rosenthal> | zcorpan: would be interesting to test also what happens when the iframe receives lazy steps after a navigation is started but before it's committed. e.g. you have an about:blank with lazy and without a src, you navigate it with a link, then set a src, and the new document is ready to commit before the lazy steps are run |
| 15:23 | <Noam Rosenthal> | I think what chromium does here would differ from your spec PR (not saying here what the "right" solution is) |
| 15:25 | <zcorpan> | Noam Rosenthal: hmm ok, can you comment that in the PR? I can add such a test tomorrow |
| 16:06 | <Jake Archibald> | Does anyone have background on why slot.assign(...nodes) only works with nodes that are direct children of the host? |
| 16:45 | <Noam Rosenthal> | Jake Archibald: sounds like https://github.com/WICG/webcomponents/issues/574, lots of discussion there |
| 16:58 | <Jake Archibald> | Noam Rosenthal: yeah, that's it, thanks |
| 16:58 | <Jake Archibald> | ugh |
| 16:58 | <Jake Archibald> | That's a shame |
| 16:59 | <Noam Rosenthal> | yea I would probably use the same utterance |
| 17:01 | <Noam Rosenthal> | there are good/complex points there, hopefully we can revisit this in the future |
| 17:01 | <annevk> | I don't think that's it. We had the discussion again for the imperative API (which that issue is not about) and I recall we were open to revisiting that at some point. |
| 17:03 | <Noam Rosenthal> | there's some openness about revisiting it in the future also in the #574 discussion |
| 17:06 | <annevk> | It was initially a goal of the imperative API to allow that. I kinda forgot why it ended up with the same restriction. |
| 17:09 | <annevk> | https://github.com/whatwg/html/issues/3534#issuecomment-371392184 is the more relevant discussion I think. |
| 17:10 | <Jake Archibald> |
|
| 17:10 | <Jake Archibald> | Yeah, that was a real gotcha for me |
| 17:10 | <Jake Archibald> | not even a warning |
| 17:13 | <Jake Archibald> | oh well. I hope it gets revisited at some point |
| 17:14 | <annevk> | It seems like Google and Mozilla blocked it. |
| 22:00 | <Dominic Farolino> | Suppose I have a spec variable that is "initially null", and I set it to an {{any}} return value of [=invoking=] a JS callback. |
| 22:01 | <Dominic Farolino> | If that callback returns "null" in JS, is my spec variable still "null" (i.e., indicating that it was never set), or is it some special "Web IDL {{null}}" value or something? |
| 22:01 | <Dominic Farolino> | (I know {{null}} does not exist in WebIDL, but I'm trying to understand if spec prose "null" is the same as null that goes through WebIDL) |
| 22:08 | <Jeffrey Yasskin> | I think folks reading that will assume the two "null"s are the same, so you should write the spec so that assumption doesn't cause problems. |
| 22:11 | <Andreu Botella> | Infra's definition of null treats it as interchangeable with the JS null value, but WebIDL's any conversion converts JS null to the null object?, which is not explicitly said to be the same as Infra's null. |
| 22:14 | <Jeffrey Yasskin> | WebIDL 'any' is a weird beast, in that "one value of the any type is the unsigned long 150, while another is the long 150. These are distinct values." Specs often implicitly convert all those contained values into a common spec type, but that's not really justified by WebIDL. |
| 22:17 | <Jeffrey Yasskin> | I do think the null object? value is the same as the Infra null: https://webidl.spec.whatwg.org/#idl-object talks about object? adding "the null value" to the type, and it's no more distinguished from Infra than "true" and "false" are in https://webidl.spec.whatwg.org/#idl-boolean. |