| 03:00 | <Kaiido> | Oh, I thought https://github.com/whatwg/wattsi/pull/161 would fix this... |
| 03:39 | <sideshowbarker> | not also fixed in bikeshed yet, maybe? |
| 04:22 | <Kaiido> | Yes, TabAtkins fixed it for bikeshed in https://github.com/speced/bikeshed/commit/72e42de7d16654bc6059cf0d622d14d4035fe536 |
| 05:40 | <Domenic> | Maybe HTML's stylesheet doesn't do the darkmode-aware thing? Although I thought that part was shared between HTML and Bikeshed specs. |
| 06:10 | <TabAtkins> | The fix there is in the markup of the image itself, html is using its own file. |
| 09:55 | <zcorpan> | HTML uses https://resources.whatwg.org/tracking-vector.svg which responds to dark mode. But the img needs class=darkmode-aware |
| 09:59 | <zcorpan> | But now I'm confused why it doesn't - https://github.com/whatwg/wattsi/blob/main/src/wattsi.pas#L1695 |
| 10:48 | <Noam Rosenthal> | zcorpan: I was thinking about the async-CSS discussion... font-display: swap is a valid use case (though I personally really dislike that UX)I thought of an option to add <link rel="font stylesheet">, where rel=font would be non-blocking, but only allow font-descriptors |
| 10:49 | <zcorpan> | Noam Rosenthal: I assume people use the onload hack for more than fonts |
| 10:52 | <Noam Rosenthal> | zcorpan: for that, I thought to have <link rel=stylesheet for=some-id> where the stylesheet would load, but would only apply when we see an element with that ID |
| 10:53 | <Noam Rosenthal> | zcorpan: I kind of see these as separate use-cases, where in one of them you actively opt-in to a FOUT and in the other one you probably don't want it but you don't know when the content will come |
| 10:54 | <Noam Rosenthal> | If we had a general async people would use it for "below the fold" and then they'd have a FoUCy race between scrolling and CSS loading |
| 10:55 | <zcorpan> | Would the parser block on that stylesheet when it sees an element with some-id? |
| 10:56 | <Noam Rosenthal> | yes |
| 10:57 | <zcorpan> | Interesting, so same effect as putting the link just before that element (in chromium currently), but you can do it from head |
| 10:57 | <Noam Rosenthal> | exactly |
| 10:58 | <zcorpan> | That seems reasonable, at least if webkit and gecko are onboard with the general stylesheets block the parser thing |
| 10:59 | <Noam Rosenthal> | zcorpan: also render-blocking rather than parser-blocking at that point would be non-FoUCy |
| 10:59 | <Noam Rosenthal> | though probably it would mean freezing the entire frame, might be worse UX than parser blocking where JS still runs |
| 11:01 | <zcorpan> | Right we don't currently block rendering after the first paint, and might cause issues to start freezing what the user sees |
| 11:01 | <Noam Rosenthal> | I want to see from he thread if more use cases come up. So far we've heard of:
|
| 11:03 | <zcorpan> | I think things that are initially hidden could be a use case. For that, ideally you don't want to block the parser, since that would hold up anything after the non-critical widget |
| 11:04 | <Noam Rosenthal> | zcorpan: yea but you probably want to block the JS that allows showing them |
| 11:04 | <Noam Rosenthal> | Otherwise you're racing between the interaction that shows them and the CSS loading (FoUC again)O |
| 11:05 | <zcorpan> | Yeah. So if for points to a script element, wait with running that script until the stylesheet is loaded? (The script could be async) |
| 11:09 | <Noam Rosenthal> | zcorpan: Yea, parser-blocking would do that automatically. Or alternatively, import the style from the script and adopt it |
| 11:18 | <Noam Rosenthal> | Thought: Maybe in the future this could be extended to a behavior where the target element is not parser-blocked, but instead received display: none until its stylesheet is loaded. So you'd have those elements appearing asynchronously, but at least each of them would be fully styled |
| 11:28 | <annevk> | smaug: were you planning on looking at moveBefore() once more before it lands? |
| 11:29 | <smaug> | yes |
| 11:29 | <smaug> | I was out sick last week |
| 15:19 | <annevk> | Domenic: I looked a bit more at the prerender code in WebKit we found a long time ago and it turns out that visibilityState at some point supported a prerender value. It's related to that. |
| 16:50 | <Dominic Farolino> | I keep seeing people get surprised by the fact that microtasks are not run after callbacks, when JS is on the stack (i.e., user-dispatched events for example). Sometimes it's discussed as a problem that hopefully we can "fix" someday. I'm sure it's intentional, but it is weird and confusing. I haven't thought about it too too much, but is there any appetite / possibility to change this? Any ideas how incompatible it would be? |
| 16:52 | <Dominic Farolino> | I imagine it'd lead to very observable differences, but I wonder if we'd be in a better state if we changed it. I don't have a good reason except for "consistency", with the caveat that changing it might introduce other inconsistencies |
| 16:52 | <Andreu Botella> | You should check with server-side runtimes (Node.js, Deno...) because they write most of the runtime's code in JS, and they have in a sense the opposite problem, in that if some runtime-internal JS code runs multiple callbacks, the microtasks would only get run at the end |
| 16:53 | <Andreu Botella> | That said, making all callbacks behave the same way would also make it easier for them, even if it would mean manually triggering a microtask checkpoint |
| 20:03 | <Shannon Booth> | Funnily enough this is something that I've been digging into a litle recently trying to figure out all of the ins and outs of when microtask checkpoint should be run. E.g with how spin the event loop empties the event loop. And the observability of invoking 'spin the event loop' to implement 'Wait for X', since that performs a microtask checkpoint. |
| 20:36 | <akaster> | Is "Sec-WebSocket-Extensions: permessage-deflate" mandatory? https://github.com/whatwg/websockets/issues/63 |
| 20:39 | <Noam Rosenthal> | Dominic Farolino: We can't empty the microtask queue after the existing dispatchEvent, it would be web breaking... The only reason to do that is to be able to call stopPropagation in a microtask (as user-dispatched events don't have preventDefault). |
| 20:43 | <Noam Rosenthal> | What I would want to have is something like EventTarget.nextEvent(eventType) that calls addEventListener with once and returns a promise... but it would need some mechanism to be able to stop propagation synchronously because of those dispatchEvent scenarios |
| 23:30 | <Kaiido> | Noam Rosenthal: I'm quite confused by this message about nextEvent. If you init your event as cancelable then you can very well call preventDefault() on it, it even sets the return value of dispatchEvent(). Also I'm not sure how stop[Immediate]Propagation would be an issue for a nextEvent(), which I assume would be a kind of "after non-capture" phase, and would thus possibly only prevent other nextEvent() listeners. Or did you envision a second round of the whole dispatching with all 3 phases?The issue I see would actually be with the return value of dispatchEvent(), and maybe it's what you were hinting at? Dispatchers could wait for one more microtask before checking the event's defaultPrevented but that seems indeed problematic that listeners don't know if the dispatcher will receive the info in time. |
