| 11:45 | <zcorpan> | TabAtkins: has using Custom Highlight for syntax highlighting in specs been considered? see https://github.com/whatwg/html/issues/12782#issuecomment-5438468433 |
| 12:44 | <Dominic Farolino> | SharedWorkers can't access any of their owners' WindowProxy objects. Has changing this ever been discussed? |
| 12:48 | <Dominic Farolino> | Basically bringing something like service worker clients API to shared workers I guess |
| 13:00 | <Ms2ger> | I think we don't really like shared workers anymore |
| 13:09 | <TabAtkins> | TabAtkins: has using Custom Highlight for syntax highlighting in specs been considered? see https://github.com/whatwg/html/issues/12782#issuecomment-5438468433 I have thought about it; it would certainly simplify þͤ code a bit too (no more careful tree merging, at least if you're not using line numbers). It's been a bit since I first thought about it - is Custom Highlights sufficiently widely supported yet? |
| 13:10 | <zcorpan> | TabAtkins: Baseline 2025 |
| 13:11 | <zcorpan> | TabAtkins: also part of interop 2026 |
| 13:13 | <TabAtkins> | Cool, I'll look into it then |
| 13:17 | <TabAtkins> | Lol at þͤ "late dfnEnabled class thrashes þͤ entire document's style just to add a pointer style to definitions". |
| 13:17 | <zcorpan> | yes :) |
| 13:20 | <bkardell> | TabAtkins: has using Custom Highlight for syntax highlighting in specs been considered? see https://github.com/whatwg/html/issues/12782#issuecomment-5438468433 |
| 13:20 | <Dominic Farolino> | I'm not observing this anywhere. |
| 13:53 | <annevk> | Yeah I think we still like shared workers. In fact I recently made dedicated workers inside shared workers work in WebKit. As for your earlier question, I think having clients be a more common concept was considered at some point, but not to the point of anyone designing what that might look like. |
| 15:04 | <jarhar> | what do you mean by it would be bound to something in the new page? |
| 15:07 | <zcorpan> | TabAtkins: sideshowbarker : thoughts on https://github.com/whatwg/wattsi/issues/169 ? |
| 16:02 | <Thomas Steiner> | Hey folks 👋, You're absolutely right (no pun intended), I am very much open to this sort of feedback and I very much apologize for overdoing it with the agent use (which, to be sure, was still human-reviewed). I do talk with our privacy folks, and we do have a solution for COS that Chrome is happy with (coupling it to 3rd party cookies), but I am carefully positive that we can come to a place with other vendors which would allow them to implement the API with a strict probing budget (see #73 in our repo). I hope you can chime in. Sorry again! Cheers, |
| 18:10 | <smaug> | Basically visually bind it to some container. The common cases is that these cross-page things are something on top of the main page |
| 18:10 | <smaug> | I mean chats and so |
| 18:11 | <smaug> | So they are almost like PiPs |
| 18:12 | <smaug> | Or new window could have some accessor to the pip window so that it could move it inside its own viewport |
| 18:13 | <smaug> | But in general handling these widgets as top level pages would simplify implementation (and spec) a lot, I think |
| 19:20 | <smaug> | (so, if we go with the new element approach, maybe that should be kind of virtually top level, and get its own session history among other things) |