| 13:48 | <littledan> | is this a good place to bikeshed about whether we should use the term "module script" for how we want to generalize to JSON module scripts, CSS module scripts, etc or something else? I share Domenic's uncertainty, but I also can't think of a better name. I'm thinking "module script" for the whole category, and then within that, JavaScript module script, WebAssembly module script, JSON module script. |
| 13:48 | <Domenic> | This is a good place. |
| 13:48 | <littledan> | re https://github.com/whatwg/html/pull/4407 |
| 13:48 | <Domenic> | Terminology wise I think module script is good |
| 13:49 | <Domenic> | I'm a little uncertain infrastructure-wise whether "JSON module script" should be a type of the "script" struct |
| 13:49 | <littledan> | I don't think anyone uses the fetch options or base URL, but we definitely do need a settings object as you suggested |
| 13:49 | <Domenic> | But probably it would end up poorly to try to have two separate things that could be in the module map/returned by "fetch a module script"/etc. |
| 13:50 | <littledan> | can we say, JSON module scripts and CSS module scripts are script modules which always have fetch options, base URL, and error to rethrow null? |
| 13:51 | <littledan> | *are script modules which... |
| 13:51 | <Domenic> | Yeah I was thinking that too |
| 13:51 | <Domenic> | Or we could introduce a new thing, "JavaScript module script", which has those three fields, and leave them out of the base "script" struct. |
| 13:51 | <Domenic> | But that refactoring is probably too early |
| 13:51 | <littledan> | well, then we'd have to re-add them to classic scripts, right? |
| 13:52 | <littledan> | anyway, the rename idea was a really good once, since it lets us introduce a general "module script" concept, which should be applied some of the time, and not other times |
| 13:53 | <Domenic> | Right, the hierarchy would be script -> {JSON module script, JavaScript script -> { JavaScript module script, classic script } } or something like that. I think that works? |
| 13:53 | <littledan> | well, then there's some things that are in common to all module scripts |
| 13:53 | <littledan> | at least algorithm-wise, maybe not storage wise |
| 13:54 | <Domenic> | Ah I see, yeah, I was only looking at storage wise |
| 13:54 | <littledan> | anyway, thanks for the detailed review; I think it makes sense from here |
| 13:54 | <Domenic> | Cool |
| 13:59 | <annevk> | Perhaps we should drop "script" from "module script"? |
| 13:59 | <Domenic> | I think the reasoning still stands; they're still introduced through <script> elements |
| 13:59 | <annevk> | And then we'd have "script" and "modules" |
| 14:00 | <annevk> | At some point the <script> element is quite far removed though. E.g., a service worker JavaScript module |
| 14:00 | <Domenic> | We'd also need a term for the unified concept, since several places in the spec operate on (what are currently called) "scripts" generically |
| 14:00 | <annevk> | "script or module" (I realize this is not great given ECMAScript) |
| 14:01 | <Domenic> | It feels weird to define a struct named with a space :) |
| 14:02 | <annevk> | I could also live with "script" -> { "module" -> { "JavaScript module", ... }, "classic script" } |
| 14:03 | <Domenic> | I guess I just find retaining the script suffix clearer in that case |
| 14:03 | <annevk> | The "script" suffix feels very redundant and somewhat wrong in the non-JavaScript cases |
| 14:04 | <annevk> | Also minor nit: probably "style sheet" rather than CSS given precedent? Or maybe precedent is bad here... |
| 14:06 | <Domenic> | Interesting question |
| 14:16 | <littledan> | "module document" for JSON, "module sheet" for CSS? no, that's a joke |
| 14:17 | <littledan> | yeah, looks like we should be talking about "style sheet modules" |
| 14:18 | <littledan> | or "style sheet module scripts" |
| 14:18 | <littledan> | unfortunately, if we use "CSS modules" we run into a naming ambiguity... |
| 14:19 | <Domenic> | We do? |
| 14:22 | <littledan> | referring to those CSS specs |
| 14:23 | <Domenic> | Oh lol |
| 15:06 | <astearns> | I wouldn't worry too much about a naming collision with spec terminology, but "style module" seems good |
| 15:09 | <annevk> | Domenic: I haven't really bothered to setup a package thing locally yet to be able to install new Python modules |
| 15:09 | <Domenic> | OK, well, I can try to do so myself I suppose to review |
| 15:10 | <annevk> | Domenic: that'd be great, thanks; I did try in with Github and their Markdown would mess up links coming after explicit markup |
| 15:10 | <Domenic> | Hmm, I wonder if it's even worth converting to Markdown then, if it won't display on GitHub properly... |
| 15:10 | <annevk> | Domenic: GitHub Markdown did show I got the indentation correct for multiple paragraphs in a list item, though I don't know how stable that notation is across versions |
| 15:11 | <annevk> | Domenic: that's a fair point, or maybe we should do the classes differently somehow |
| 15:12 | <annevk> | Domenic: https://github.com/whatwg/sg/blob/ae3d8b6ca82ec3013b7eb29c085800cd83b1b01b/Working%20Mode.md |
| 15:12 | <Domenic> | Ah right, yeah, I think per CommonMark if you're inside a HTML block you can't use Markdown |
| 15:12 | <Domenic> | Although the rules might be different for `<p class="note">\n ... stuff \n</p>` vs. `<p class="note"> ... stuff</p>` |
| 15:14 | <annevk> | I want to get to https://github.com/whatwg/sg/issues/78 though I suppose I could give that a go in parallel given how far along we are now |
| 15:14 | <annevk> | But not today |
| 18:32 | <Domenic> | annevk: to confirm, window.close() queues a task to discard in Chrome and Safari too? |
| 18:32 | <annevk> | Domenic: yeah, they fail due to poor global obj impl |
| 18:33 | <Domenic> | I was hoping they might discard synchronously |
| 18:33 | <annevk> | Domenic: for which there are bugs on file |
| 18:33 | <annevk> | Domenic: Safari does not have the is closing flag |
| 18:33 | <annevk> | or boolean |
| 18:34 | <Domenic> | Yeah, but nobody does the simple thing, I guess |
| 18:34 | <annevk> | But it seemed safer to follow others for that |
| 18:35 | <annevk> | It’s rather silly given nested bcs, but yeah |
| 20:13 | <hober> | i keep failing to think of the right search terms for the relevant html issue on github; does anyone remember where we ended up with the "label of the enter key on a virtual keyboard during text input" thing? |
| 20:13 | <hober> | or just a link to the issue |
| 20:15 | <hober> | oh, enterkeyhint. nevermind. |