| 07:05 | <annevk> | wanderview: yeah I think so, would love to hear from Google security folks too |
| 14:39 | <wanderview> | not sure what the question for the security folks is |
| 18:51 | <annevk> | wanderview: "could you please evaluate this idea and let us know your thoughts?" |
| 18:53 | <wanderview> | "this" == the refactor to add auth container? or some other part of what we have been talking about? |
| 19:43 | <zcorpan> | Domenic: to solve https://github.com/whatwg/html/issues/7976 we need to solve https://github.com/whatwg/html/issues/1013 , right? Especially if we only want to allow adding new render-blocking things if the "current script" was itself render-blocking |
| 20:11 | <Domenic> | zcorpan: I don't understand the connection |
| 20:13 | <zcorpan> | Domenic: when import() runs, how can it tell whether the running script is render-blocking? (Assuming we don't want async scripts in <body> to be able to add render-blocking imports, or from setTimeout and such) |
| 20:13 | <zcorpan> | I guess the web-exposed mechanism for #1013 is not necessary, but the same internal mechanism |
| 20:31 | <Domenic> | I thought import(..., { blocking: "render" }) would just set the render-blocking flag on the script when it runs |
| 21:11 | <zcorpan> | Domenic: See https://github.com/whatwg/html/issues/7976#issuecomment-1145105267 it should not set the flag if the script was in <body>. Which makes me think the import() steps need to check if the <script> that contains the import() statement is render-blocking, to decide whether to allow the import to also be render-blocking |
| 21:13 | <Domenic> | Well, the problem is probably solvable here. The issue with module scripts is that they have many ancestors. We can "just" check that none of their ancestors is in the <body>. |
| 21:14 | <Domenic> | Although, by default all module scripts are defer, so run after </body> is encountered. So I am skeptical about this framing making sense. |
| 21:14 | <zcorpan> | You'd use async |
| 21:19 | <zcorpan> | I agree it should be solvable. I struggle to find existing terms in the spec to solve it tho :) |
| 22:16 | <Domenic> | Yeah I don't think we (or the JS spec) track ancestor information... I guess you'd probably propagate it down as part of executing a <script> |