| 12:06 | <nicolo-ribaudo> | Does the HTML spec consider "returning an ECMA-262-style throw completion" be the same as throwing? If not, I cannot find where the QuotaExceededError in the last step of run a classic script is ever used. |
| 12:08 | <nicolo-ribaudo> | And I feel like it interacts in some way with the "let the aborting continue" in the last step of https://html.spec.whatwg.org/#import-scripts-into-worker-global-scope, but it's not clear if that means that it re-returns that throw completion |
| 12:09 | <annevk> | nicolo-ribaudo: isn't throwing an abrupt completion and handled in step 8? |
| 12:10 | <nicolo-ribaudo> | I mean the throw completion it creates at step 11 |
| 12:11 | <annevk> | Oh I wonder if that's a leftover from a refactor. Looking at 8.2.2 I think that should also be just a throw. |
| 12:11 | <annevk> | Or at least they ought to be consistent. |
| 12:12 | <nicolo-ribaudo> | There is one caller that checks the completion record returned by that algorithm (https://html.spec.whatwg.org/#the-javascript:-url-special-case:run-a-classic-script, step 9), but it then never actually checks the error if it returns a non-normal completion |
| 12:13 | <nicolo-ribaudo> | So a question would also be: should that "evaluate a javascript: URL" algorithm re-throw errors thrown by running a classic script, or should it handle them as if they were throw completions and thus just return null at step 10 (rather than propagating the exception at step 7) |
| 12:14 | <annevk> | Yeah, makes sense. If you have the time figuring that out would be good, failing that an issue would be appreciated. |
| 12:15 | <nicolo-ribaudo> | I'll open an issue but figuring it would will be very low in my priority list of things to do :P |
| 12:15 | <nicolo-ribaudo> | I guess for this I can actually write a test and see what is the expected behavior |
| 12:15 | <annevk> | Maybe we can nerd snipe zcorpan |
| 12:21 | <nicolo-ribaudo> | https://github.com/whatwg/html/issues/11404 |
| 12:25 | <zcorpan> | nicolo-ribaudo: it seems to me returning null at step 10 is what was intended, but if so the spec should be changed to explicitly catch it per https://infra.spec.whatwg.org/#algorithm-control-flow |
| 12:38 | <annevk> | If we rely on rethrow elsewhere (and it seems like we do), yes. Also, if we only return a value for javascript: URLs we don't have to return an ECMAScript-style completion. |
| 14:52 | <cwilso> | I'm not seeing any agenda items on today's WHATNOT meeting (https://github.com/whatwg/html/issues/11386, nothing agenda+ in the repo). Should we cancel? |
| 15:00 | <smaug> | I think so, it is the meeting which gets least participation in general, I believe |
| 18:00 | <anthonyv.be> | With the release of Firefox 140 I found out about https://github.com/whatwg/html/pull/7829 One part of the outline algorithm I heavily rely on, is the ability to just use h1 tags everywhere, and have them rendered at the expected level (this is e.g., really helpful when moving sections/articles around in a document and not having to worry about updating their header tags to the level of their new location). Are there any plans to bring back this part of the algorithm or to provide a replacement feature (e.g., a hn tag)? Or is the recommendation to implement this myself with a custom element? Thanks in advance for any insights. |
| 22:41 | <TabAtkins> | anthonyv.be: Check out https://github.com/whatwg/html/issues/5033 |