| 01:18 | <Timo Tijhof> |
|
| 05:21 | <annevk> | Timo Tijhof: we were just discussing this case earlier in this channel; however, with the crossorigin attribute set it should in theory match up. Thinking about it again there's another thing however that set module scripts apart and maybe that's why Gecko doesn't reuse the cache. And that would make sense. Module scripts parse differently and so if you eagerly parse and don't store the original text you couldn't reuse the script as both classic and module script. |
| 05:23 | <Domenic> | It felt like that thread had several good implementation bugs that should be filed. Although I can understand that discriminating between impl bugs vs impls following the spec could take some work. |
| 05:23 | <annevk> | I guess that makes me lean towards only endorsing modulepreload for this, but I see you also need import maps at that level for that to be an okay solution. It's a bit unclear whether that should be prioritized or we should try to make rel=preload type=module be a thing as some kind of inbetweeny solution as well. |
| 05:25 | <annevk> | Domenic: I only saw this Chrome/Firefox mismatch and if anything that's probably a specification bug for suggesting rel=preload as=script works for type=module. At least I'm quite convinced now that shouldn't work as it would rule out pre-parsing. |
| 05:27 | <Domenic> | Firefox downloading bare imports seems bad. Safari not using module map to dedupe requests seems bad. Chrome downloading bare imports seems bad. |
| 05:28 | <Domenic> | rel=preload as=script crossorigin seems like it should not work, although it might populate the HTTP cache. Maybe Chrome has some general request deduping happening; I suspect that's not a module specific problem. "Memory cache"?? |
| 05:30 | <Domenic> | That said I'm not sure the description is accurate since it includes the <script>. Some of the things <a href="https://matrix.to/#/@timotijhof:matrix.org">Timo Tijhof</a> ascribes to preload/modulepreload are almost certainly due to the <script> |
| 05:31 | <Domenic> | Safari behavior also looks so strange that I wonder if it's a DevTools issue. |
| 06:50 | <annevk> | Oh, I guess I should have read the Observations section more carefully. |
| 07:41 | <zcorpan> | Oooh another browser engine https://github.com/Wuelle/Stormlicht |
| 12:08 | <annevk> | PSA: Now would be good time to do a thorough review of https://github.com/WICG/sanitizer-api if that kind of API interests you. We're trying to settle the remaining details so if there's anything you don't like please raise it. |
| 15:30 | <bkardell> | annevk:
Just curious where was that discussion? |
| 15:38 | <annevk> | bkardell: Sanitizer API meeting |
| 15:41 | <bkardell> | what is the meeting organized under? Igalia is interetested in the Sanitizer API but we weren't aware of the meeting annevk |
| 15:43 | <bkardell> | we'd like to attend future meetings, and obviously would have liked to have been at that one given the whole mathml thing :) |
| 15:43 | <annevk> | freddy: ^^ |
| 15:56 | <bkardell> | for the record, we're not unhappy with that decision or anything - we just would like to be involved and have interests |
| 16:17 | <freddy> | Oh yeah, happy to send invites. Which timezone do you have folks? We're currently very EMEA friendly ;-) |
| 16:35 | <Luke Warlow> | Oh yeah, happy to send invites. Which timezone do you have folks? We're currently very EMEA friendly ;-) |
| 17:23 | <bkardell> | I'm in ET |
| 17:44 | <annevk> | It's at 4AM ET. |
| 17:50 | <bkardell> | 🤷 unfortunate, but I guess I can't expect the world to bend to my schedule :) Luke will be there at least. If I need to be there I will |