| 03:21 | <annevk> | dtapuska: maybe the BCG’s map should be weak, that would solve things |
| 11:22 | <domfarolino> | annevk: btw does this sound OK? https://github.com/whatwg/html/pull/3752#discussion_r303720464 |
| 11:24 | <annevk> | domfarolino: more or less, you also have to account for it not delaying the load event I suspect |
| 11:24 | <annevk> | domfarolino: the current text doesn't do that quite as clearly either |
| 11:24 | <domfarolino> | agreed |
| 11:24 | <annevk> | domfarolino: (that would also make it observable whether you do it same-origin/cross-origin btw) |
| 11:26 | <domfarolino> | annevk: Hmm, well I'm wondering since the lazy load attributes are "strong hints" right, does that mean the UA could choose to defer the rest of the iframe navigation whenever it wants? |
| 11:27 | <annevk> | domfarolino: what is a strong hint? I think blocking or not blocking the load event better be normative |
| 11:31 | <domfarolino> | annevk: Sorry, I was referring to https://whatpr.org/html/3752/edc1e95...ba7593f/urls-and-fetching.html#lazy-loading-attributes "The attribute provides a hint...". I agree that deferred requests not blocking load event should be more rigorous. But it seems like whether a request is deferred or not ultimately depends on what the UA does with the hint |
| 11:31 | <domfarolino> | Maybe it shouldn't be a "hint", and should be more firm? |
| 11:33 | <annevk> | domfarolino: yeah, I guess we should reword that, it's definitely fine to fetch immediately, but certain aspects better be implemented consistently across user agents |
| 11:37 | <domfarolino> | annevk: yeah I think auto should be the only hint. The others should be “non-negotiable” perhaps |
| 11:38 | <annevk> | domfarolino: even with auto it should still be clear whether you delay the load event I think |
| 11:39 | <annevk> | domfarolino: and since that's the default it means that in that case you do delay |
| 11:41 | <annevk> | domfarolino: I guess I got that wrong as the default is different from omitting the attribute entirely |
| 11:54 | <domfarolino> | annevk: well I think with auto it’s not clear whether the UA will actually defer or not. But as long as we make clear that if the image does defer, load is not blocked. Else, load is, since the request wasn’t deferred. |
| 11:54 | <domfarolino> | annevk: Also it was my understanding that the missing value default was auto, is that wrong? |
| 11:54 | <domfarolino> | (On a train now can’t check) |
| 11:54 | <domfarolino> | s/image/request |
| 11:55 | <annevk> | domfarolino: oh right, in which case I'm right |
| 11:56 | <annevk> | domfarolino: with auto the behavior will have to be as if the attribute was not specified, which definitely delays the load event today |
| 11:57 | <domfarolino> | annevk: I think auto was introduced to let UAs determine whether imgs/iframes without the developer specifying the attribute. Is this bad? |
| 11:58 | <domfarolino> | If auto should just == eager, we should make it a binary attribute |
| 11:58 | <annevk> | domfarolino: if <iframe loading=auto> === <iframe> we cannot really change the status quo, right? |
| 11:59 | <annevk> | domfarolino: perhaps you didn't mean to have a missing value default? |
| 11:59 | <annevk> | I wonder if we should rename that to "missing attribute default" for clarity |
| 12:00 | <annevk> | "missing value" might mean empty string to some people |
| 12:01 | <domfarolino> | annevk: I think Ben’s goal with including “auto” initially was to give room in the future to change the status quo, i.e., possibly defer <iframe> (no attributes) |
| 12:01 | <domfarolino> | I’ll double check with him though to be sure. But yeah renaming that might be nice |
| 12:02 | <domfarolino> | But it’s equally possible Ben thought missing value default only applied to <iframe loading> (no value) |
| 12:02 | <domfarolino> | I will ask |
| 12:08 | <domfarolino> | I guess this is the trouble with changing spec authors |
| 12:12 | <annevk> | domfarolino: well, and not having clearly publicly logged discussions for all the design aspects to reflect upon |
| 12:12 | <domfarolino> | Heh that too |
| 12:13 | <annevk> | If that was done and there was some design involvement from multiple parties, you wouldn't really run into this |
| 12:13 | <annevk> | But now we're often hitting the design questions at the time of an HTML PR... |
| 12:13 | <annevk> | Which isn't ideal |
| 12:46 | <domfarolino> | annevk: Yeah, that makes sense |
| 12:56 | <annevk> | dtapuska: Domenic: https://github.com/whatwg/html/issues/4782 |
| 13:02 | <dtapuska> | annevk: Yup I saw that.. I definitely agree it is a weak map (at least that is definitely how we implemented it in Chrome). |
| 13:06 | <dtapuska> | annevk: https://github.com/whatwg/html/pull/4772 this is mainly editorial... the current inheritance across browsing contexts occurs even in the current published version.. It sounds like the double "remote" call is an implementation detail... ie; in Chrome we have an object representing the Remote Browsing Context so that doesn't really get cloned but the remote frame tree node has a copy of the feature policy so it |
| 13:06 | <dtapuska> | isn't a cross process messaging.. but that is an impl detail |
| 13:14 | <annevk> | dtapuska: I guess currently policies can't be changed, but when they can (as with CSP or Referrer Policy), it's not an impl detail |
| 13:14 | <annevk> | dtapuska: and there's folks continuously pushing for <meta> |
| 13:16 | <dtapuska> | annevk: Right but I'm just trying to have the spec better match Chrome's implementation at this point and I believe it is a reasonable editorial change for now. I don't want to get into the case where feature policy should or shouldn't be in the HTML spec |
| 13:17 | <annevk> | dtapuska: I thought you wanted shared understanding on how to model things? |
| 13:19 | <dtapuska> | annevk: I was going after that things should be created before the document is created.. And ya it might move higher before the browsing context is created in the future.. |
| 13:20 | <dtapuska> | annevk: ie; determination of sandbox flags, creation of agent, determination of origin.. All the changes I'm making are before the document is created... Fundamentally this is probably done before the browser context is created.. probably when COOP and COEP are parsed.. In Chrome that would be in the browser process before determining which process the browserContext is going to get created in. |
| 13:22 | <annevk> | Sure, the specific concern I have is around navigateChild(); changeStateOfParent(); queryStateOfNavigatedChild() |
| 13:23 | <annevk> | I'd like changeStateOfParent() to never be able to affect the results |
| 13:28 | <dtapuska> | annevk: wrt https://github.com/whatwg/html/pull/4617#discussion_r304388723 Do you expect two frames that aren't same-origin domain to be able to pass shared array buffers via postMessage? |
| 13:29 | <annevk> | dtapuska: if they are same-site, yes |
| 13:29 | <annevk> | dtapuska: or same agent-cluster, rather |
| 13:30 | <annevk> | dtapuska: a.example.com and b.example.com get shared memory without document.domain (it'd be pretty bad if document.domain changed what agent cluster you were part of) |
| 13:30 | <annevk> | dtapuska: assuming they're in the same BCG |
| 13:37 | <dtapuska> | annevk: Right so this comment is wrong.. Chrome currently doesn't do that for MessagePorts so I got confused |
| 13:39 | <annevk> | dtapuska: I'm not sure what you mean |
| 13:39 | <annevk> | dtapuska: what I'm saying is correct though, including in Chrome, see html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/window-similar-but-cross-origin-success.sub.html for instance on WPT |
| 13:40 | <annevk> | dtapuska: I guess you're saying we need more MessageChannel coverage |
| 13:41 | <dtapuska> | annevk: Yes I wrote a WPT test for this https://chromium.googlesource.com/chromium/src/+/96f9c17b2cc57bc443580c8b4c6845424e8555b1 |
| 13:41 | <annevk> | dtapuska: cool |
| 13:41 | <annevk> | dtapuska: the real complicated case with MessageChannel might also be worth testing |
| 13:41 | <annevk> | dtapuska: you have agent clusters A and B |
| 13:42 | <annevk> | dtapuska: you message a MessagePort to B |
| 13:42 | <annevk> | dtapuska: you message a SAB to the port still on A, but you don't call start() yet |
| 13:42 | <annevk> | dtapuska: you then message the MessagePort in B back to A |
| 13:42 | <annevk> | dtapuska: you call start |
| 13:42 | <annevk> | dtapuska: it should succeed |
| 13:43 | <annevk> | dtapuska: this is tracked at https://github.com/whatwg/html/issues/4209 |
| 13:44 | <dtapuska> | annevk: Ya that is an interesting case I agree.. |
| 15:33 | <annevk> | Domenic: it seems your questions are primarily about the non-session bits, right? |
| 15:34 | <Domenic> | annevk: I don't really understand enough to know whether that's true |
| 15:34 | <annevk> | Domenic: so we should make sure they're addressed somehow by dtapuska's PR |
| 15:36 | <annevk> | Domenic: I can sketch a simple collection case now I suppose; say in TLBC we navigate from "scheme-and-site" 1 to 2. This ends up creating two entries in TLBC's BCG's agent cluster map. The user agent can collect 1 once the navigation is complete, assuming they don't intend on doing bfcache or some such to it. |
| 15:37 | <annevk> | Domenic: similar if there was a nested browsing context created in 2 that ends up creating 3 and is then removed. 3 can be collected assuming no references to any of its objects are hold (objects have strong references to globals which hold strong references to agents which hold strong references to agent clusters). |
| 15:40 | <annevk> | (Hmm, technically nobody can hold references to objects from 3 but 3, but as I mentioned we currently assume 3's WindowProxy and Location objects can be accessed from elsewhere as we don't have explicit "remote" variants, and even if we did we might wanna pretend those remote variants have a strong cross-process pointer for specification-simplicity.) |
| 19:04 | <bkardell> | probably a silly question, but is there any prop anywhere or a getter that I don't know of that would give me a list of all of the browsers known (not custom) elements that wont parse as HTMLUnknownElement? |
| 19:28 | <Domenic> | bkardell: there is not. I think there is a feature request like this, either on whatwg/html or w3c/webcomponents. |
| 20:04 | <innovati> | bkardell I haven't discovered this yet ;) the closest I found was a JSON file in browser source code that listed them out, or writing a function that uses document.createElement() to check the constructor to see if that browser sees it as HTMLUnkownElement https://github.com/chromium/chromium/blob/6efa1184771ace08f3e2162b0255c93526d1750d/third_party/blink/renderer/core/html/html_tag_names.json5 |
| 20:06 | <annevk> | TabAtkins: FWIW, the main problem is lack of agreement around creation; at some point constructors were gonna be it, but they haven’t quite made it. And then we have all these variants on setting attributes/properties/listeners at the same time. I guess most things beat the status quo, but would still be nice to get it right 😊 |
| 20:08 | <TabAtkins> | Yup. There's solutions around all of this, of course, we just need to settle on one. |
| 20:08 | <TabAtkins> | (My element-creation helper, for example, interprets _-prefixed keys in the attributes bag as being properties, and _onFoo keys as being event listeners.) |
| 20:08 | <TabAtkins> | (That's probably a touch too hacky for the platform.) |
| 20:09 | <TabAtkins> | Tho for real, "foo" being an attribute, ".foo" being a property, and "on(foo)" being a listener, might legit work. |
| 20:11 | <annevk> | A think Yehuda proposed is something similar to the HTML parser. That you create with a context element and based on that it picks the namespace. |
| 20:12 | <annevk> | It could work, but might not be fast… |
| 20:15 | <bkardell> | Yeah, I mean - i really seem to bump into this a lot and I have a list of all of the elements that I use, but it always feels very icky and silly - I guess I was just hoping the platform advanced something while I was looking the other way or something and I could stop that since I know there's been a lot of asks over the years.. :) oh well, worth a shot |
| 20:15 | <bkardell> | good old list of elements it is :) |
| 20:17 | <TabAtkins> | annevk: I don't get why we need to be magical about this. There's like four collisions, and only *one* of them is something you'd generally create with a DOM API (<a>). Just list out all the elements, have the collisions default to HTML, and let you use a name prefix to disambiguate. |
| 20:32 | <annevk> | It depends a bit on what kind of code you want to simplify. I largely agree though and DOMChangeList has that API. |
| 20:33 | <annevk> | bkardell: it takes people to advance things and DOM/HTML isn’t invested in much at the core |
| 20:36 | <bkardell> | annvk I realize... I'm not sure if you read what I wrote there as a complaint or indictment or something, but if so it wasn't intended in any way... no harm in checking if there was a thing I wasn't aware of - I'm not sure this is 'common' I just seem to bump into it myself a lot because of the weird stuff I wind up into :) |
| 20:37 | <annevk> | All good, just clarifying why not everything is moving |
| 20:39 | <bkardell> | like, even myself, if I have to choose where to invest my finite time, it's probably not this... Trying to figure out how I efficiently go about getting folks to agree to particularly which shape of which idl should go where to achieve the goal with the same observable impacts seems more important/worth my own time :) |
| 20:40 | <innovati> | When I was looking into if I could get a list of supported tags for doing HTML templating, I had a peek at how other frameworks/libs do it, and almost all that had a list of known elements like this were outdated/inaccurate :/ also there was a lot of confusion around which elements are void elements or not |
| 20:40 | <bkardell> | but sometimes you get lucky and there's just an answer you missed or somethign |
| 20:40 | <bkardell> | I really didn't intend to open a can of worms :) |