| 13:00 | <annevk> | littledan: what are the phases a module goes through again? There's loading, constructing, and evaluation apparently? |
| 13:01 | <littledan> | annevk: well, in the JS spec, they are called ParseModule, Instantiation (now being renamed to Linking), and Evaluation |
| 13:01 | <littledan> | Evaluation is where you actually execute the statements in the module |
| 13:02 | <littledan> | ParseModule is where you create a module record, and Instantiation is where the named exports and imports get associated with each other |
| 13:03 | <annevk> | littledan: I guess it'd make sense to parse HTML/CSS during ParseModule then |
| 13:03 | <annevk> | littledan: their parse operation just doesn't fail |
| 13:03 | <littledan> | that was my expectation as well. Domenic points out that this is a bit more spec bookkeeping, but it's parallel to the JS one. |
| 13:03 | <littledan> | right |
| 13:03 | <annevk> | littledan: I see |
| 13:04 | <annevk> | If it's not observable it doesn't matter perhaps how we do it |
| 13:04 | <annevk> | Guess it depends on if there's stuff planned that would make it observable somehow |
| 13:05 | <littledan> | It's observable, but in a way that doesn't matter much |
| 13:05 | <littledan> | Siblings in the module tree may execute first |
| 13:06 | <littledan> | A related question is, how should [SecureContext] work for modules: should it make the module not exist, or throw when executed? It's observable in the same sort of way (plus through import-maps) |
| 13:10 | <annevk> | IDL makes interfaces not exist, so I guess we should follow that precedent |
| 13:18 | <nox> | How can we observe anything if our eyes aren’t real anyway |
| 13:19 | <Ms2ger> | Through the magic of all-observing baguettes |
| 13:19 | <Ms2ger> | annevk, do we have a policy about acknowedgements if someone files a bug and it's already fixed independently? |
| 13:20 | <annevk> | and an additional glass of wine during lunch |
| 13:20 | <littledan> | annevk: if this is fun for you: the big question we are working through for top-level await is, should we keep the Evaluate phase synchronous when there is no TLA, or should we do a microtask checkpoint after loading each module? https://github.com/tc39/proposal-top-level-await/issues/47#issuecomment-467898555 |
| 13:20 | <annevk> | Ms2ger: not that I know of |
| 14:22 | <annevk> | littledan: I tried wrapping my head around it, but other than "consistency would make sense" I don't have much to contribute |
| 14:23 | <littledan> | annevk: Well, thanks for taking a look. The "problem" is that both options have consistency arguments |
| 14:23 | <littledan> | I guess my feeling is, all else being equal, I'd prefer to leave module semantics in place with respect to what has been shipped in multiple browsers for years (i.e., #49) |
| 14:24 | <littledan> | I don't know how to assess the compatibility risk and upgrade cost of adding the checkpoints |
| 14:24 | <annevk> | littledan: I guess the advantages listed for 49 don't feel like strong advantages to me |
| 14:24 | <littledan> | hmm |
| 14:24 | <annevk> | littledan: whereas the advantages for 51 seem to offer consistency |
| 14:24 | <littledan> | I see |
| 14:27 | <annevk> | I mean, browser status quo is important, but it's not great and can be fixed, let's fix it; and ease-of-polyfilling I'm generally meh on, long term is more important |
| 14:27 | <annevk> | if it's not great* |
| 14:27 | <annevk> | Disadvantages might be interesting |
| 14:28 | <littledan> | yeah, i guess it's mostly about "this feels weird as a synchronization primitive" |
| 14:28 | <littledan> | that's sort of the objection I heard the most |
| 14:28 | <littledan> | I don't feel like the existing microtask checkpoints are serving this sort of purpose |
| 14:28 | <littledan> | I was wondering, should HTML have a way to do a microtask checkpoint without yielding to the event loop? (Or does it?) Would this be useful for people in other cases? |
| 14:29 | <littledan> | or, to be concrete, a way to call a callback after the next microtask checkpoint, and before the event loop |
| 14:31 | <annevk> | littledan: I think HTML already has that, when there's multiple mouse event listeners and the user triggers the listeners |
| 14:32 | <annevk> | littledan: promises are drained at the end of each callback; reading the the issue more attentively Domenic is on point I think and he also knows this area the best among WHATWG folks |
| 14:32 | <littledan> | I see, OK, thanks |
| 14:34 | <littledan> | (I got pushback from someone in V8 about #51, but I'm not sure how strongly held it was; this is part of why I remained uncertain) |
| 14:35 | <annevk> | littledan: actually, JakeA might also be interested, he loves promise-gotchas |
| 14:35 | JakeA | reads back |
| 14:36 | <annevk> | JakeA: https://github.com/tc39/proposal-top-level-await/issues/47#issuecomment-464488593 |
| 16:39 | <Domenic> | zcorpan or anyone: I hear the term "reparenting" a lot for rearranging the DOM tree while we parse, but I Ctrl+F for "reparent" and don't find that in the spec. Is there a centralized description of that somewhere I can point a questioning web developer too? |
| 16:49 | <Ms2ger> | Possibly https://html.spec.whatwg.org/multipage/parsing.html#foster-parent |
| 17:33 | <annevk> | that's it |
| 20:09 | <Domenic> | I guess that's only for tabley stuff |
| 20:10 | <Domenic> | But e.g. nested forms are handled with a separate mechanism |
| 20:29 | <Domenic> | OK, so, this is a cut-down version of GitHub's user profile page. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6728 |
| 20:29 | <Domenic> | It demonstrates an amazing fact |
| 20:29 | <Domenic> | </form> will, under some circumstances, reset the form element pointer. Thus allowing nested forms. But, once it resets the pointer, we do nothing else, and discard the token. |
| 20:29 | <Domenic> | 🤯 |
| 20:30 | <Domenic> | I can only assume this was important for legacy compat |
| 20:30 | <Domenic> | Reference: https://html.spec.whatwg.org/multipage/parsing.html#insertion-mode 'An end tag whose tag name is "form"' |
| 20:36 | <annevk> | Domenic: form is great |
| 20:49 | <annevk> | Domenic: there is also reparenting with misnested inlines |