| 00:35 | <cybai|leave> | Domenic: I see! Thanks! |
| 07:35 | <hsivonen> | annevk: does the Web Platform have support for identity encode into Uint8Buffer? |
| 07:35 | <hsivonen> | annevk: i.e. take the low 8 bits of each code unit in a JS string and put them into an array buffer? |
| 07:35 | <hsivonen> | (assuming the high half of each UTF-16 code unit is zero) |
| 07:36 | <TimothyGu> | hsivonen: there's https://infra.spec.whatwg.org/#isomorphic-encode, which unfortunately has an assert against having non-zero high half |
| 07:38 | <annevk> | TimothyGu: did you need something like that in a spec without the assert? |
| 07:39 | <TimothyGu> | hsivonen: (uhm) ^^ |
| 07:39 | <annevk> | hsivonen: ByteString, but nothing exposed "raw" |
| 07:39 | <annevk> | hsivonen: ByteString throws for > U+0255 |
| 07:39 | <annevk> | euhm |
| 07:40 | <annevk> | > U+00FF |
| 07:40 | <annevk> | I need more sleep |
| 07:40 | <hsivonen> | TimothyGu: I meant: Is that exposed as a JS API? |
| 07:41 | <annevk> | hsivonen: nope, we had some requests for "true iso-8859-1" but nothing came of that thus far |
| 07:42 | <hsivonen> | that is, do we have a story for piece-wise migration from JS strings as containers for binary data to Uint8Array? |
| 07:42 | <hsivonen> | annevk: thanks |
| 07:42 | <annevk> | hsivonen: I think in part because you strongly opposed some of this early on |
| 07:42 | <hsivonen> | oh? |
| 07:43 | <annevk> | hsivonen: well, maybe not distinct APIs, but putting them in TextEncoder/TextDecoder |
| 07:43 | <hsivonen> | that's different |
| 07:44 | <annevk> | Okay, so I've seen requests for "true ascii" and "true iso-8859-1", not sure about ignoring the non-significant bits though |
| 07:44 | <annevk> | And there've been requests for TextEncoder/TextDecoder-style APIs around base64 |
| 07:45 | <annevk> | It's not entirely clear to me what the right approach is as I'm not sure they're worth that much additional classes |
| 07:46 | <annevk> | And putting first-class support for these in JS and not putting first-class support for UTF-8 in JS could also give the wrong incentive to folks |
| 07:46 | <hsivonen> | at this time, I'm not asking for anything to be added |
| 08:03 | <annevk> | hsivonen: okay, curious what made you consider this; did you see a bunch of JS strings containing "binary data"? |
| 08:09 | <hsivonen> | annevk: Thunderbird |
| 08:10 | <hsivonen> | so not a Web use case |
| 08:28 | <annevk> | ta |
| 13:24 | <Ms2ger> | Script experts! In https://html.spec.whatwg.org/multipage/scripting.html#execute-the-script-block , can currentScript ever not be null if the script is a module script? |
| 13:24 | <Ms2ger> | Domenic, zcorpan ^ |
| 13:25 | <Domenic> | Ms2ger: depends on what you mean. That step will set it to null. But if you then synchronously insert a <script>, maybe it can overwrite it... not sure if that's possible though since we disallow top-level document.write, and inserting a script from script will make it async... |
| 13:26 | <zcorpan> | it is both null and not null until you observe it |
| 13:27 | <Domenic> | Probably though any top-level code that runs inside a <script type=module> or its dependencies will see document.currentScript === null. My guess is there are not any tricks to break that, without going back to the event loop in some way. |
| 13:27 | <Ms2ger> | No, I mean, I think it should already be null at the start of the algorithm, since module scripts never execute sync (right?) |
| 13:27 | <Domenic> | Oh |
| 13:28 | <Domenic> | Wow, interesting, I think you are correct. That's a nice simplification... |
| 13:34 | <zcorpan> | Domenic: Ms2ger: the only caller i'm unsure about whether it is free of bugs is https://html.spec.whatwg.org/multipage/xhtml.html#parsing-xhtml-documents:execute-the-script-block |
| 13:35 | <zcorpan> | (I mean, I'm not sure any other part is free of bugs, but you know what I mean) |
| 13:35 | <Ms2ger> | Can a module script be the pending parsing-blocking script? |
| 13:35 | <annevk> | Even with import() you cannot dictate when execution happens? |
| 13:36 | <Ms2ger> | import() returns a promise |
| 13:36 | <Domenic> | It cannot be a pending parsing-blocking script, I just traced it |
| 13:36 | <Domenic> | (Wow, that XML <script> section is scary.) |
| 13:37 | <zcorpan> | Ms2ger: no. I think this part of the spec is fine, upon closer thought. "Prepare" is the same as for text/html parsing |
| 13:37 | <annevk> | Ms2ger: it's the other thing that it does that's important, but I guess it queues a task to execute and resolve the promise |
| 13:37 | <annevk> | (and not give you a handle on something you get to execute) |
| 13:38 | <annevk> | Ms2ger: can Wasm be an escape hatch? |
| 13:39 | <Domenic> | "execute a script block" is only for <script>s |
| 13:40 | <Domenic> | A more explicit name would probably be something like "run a script created by a script element" |
| 13:41 | <annevk> | ah yeah |
| 13:55 | <Ms2ger> | https://github.com/whatwg/html/pull/4627 |
| 17:09 | <annevk> | nox: I have a fun test |
| 17:09 | <annevk> | nox: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/6910 |
| 22:10 | <Domenic> | Ms2ger who hopefully reads scrollback: littledan: I think we should be able to merge JSON modules into the spec tomorrow-ish, I don't recall any blockers besides maybe some nits, and the tests M2ger has done seem good enough to get us started until an implementer gets involved to add more alongside their implementation. The PRs to merge are Web IDL synthetic modules, then HTML + WPT. I'll try to do that tomorrow. |
| 22:20 | <littledan> | Domenic: 🍾 |
| 22:21 | <littledan> | Your test suggestions seemed good to me; agree there is still a bit more to do there |