| 08:23 | <Tim van der Lippe> | Would be great if that could be addressed. Should I maybe file an issue on the repository instead if WebKit is open to improving the script? |
| 14:29 | <annevk> | I suspect that already exists |
| 14:59 | <annevk> | Hmm, the person in favor of cross-origin storage has gone full AI. Except that as far as I can tell AI hasn't solved the basic privacy issue. Good times. |
| 15:00 | <Noam Rosenthal> | Link? |
| 15:01 | <annevk> | https://github.com/whatwg/fetch/issues/1954 is the latest in a series of things I've seen come by. |
| 15:07 | <Noam Rosenthal> | There's a lot in https://github.com/WICG/cross-origin-storage#privacy-considerations, though I haven't dived into it |
| 15:12 | <annevk> | That starts with
meaning it's a Chromium-only API as Chromium has a privacy hole. |
| 15:13 | <annevk> | But anyway, recent posts sought to address that, but it seemed primarily AI-driven without addressing the known issues with hash-based caching. |
| 15:15 | <Noam Rosenthal> | gotcha |
| 15:41 | <annevk> | Ah I just found most of the remaining context in my notifications: https://github.com/WICG/cross-origin-storage/pull/73 |
| 15:46 | <Noam Rosenthal> | Github actions is down/moody: https://www.githubstatus.com/ So some html builds are failing |
| 15:48 | <annevk> | Also impacts WPT. Not too bad if you're in Europe I suppose. |
| 15:53 | <Noam Rosenthal> | yea I'm sure Thomas Steiner consults with our privacy experts and is open to feedback, despite the AI |
| 15:58 | <annevk> | Sure, but maybe do that before you ask other companies to take a look |
| 16:15 | <Noam Rosenthal> | For whoever is editing the HTML standard https://github.com/noamr/web-archeologist/tree/main/skills/html-spec-splitter |
| 16:15 | <Noam Rosenthal> | See fix (https://github.com/whatwg/html/pull/12846) Tries to follow what blink does which I think is sensible |
| 16:26 | <zcorpan> | @noamr:matrix.org: maybe we can reconsider splitting source |
| 16:30 | <Shannon Booth> | on a very loosely related question, is there a single page version of the MR diff viewing thing linked on MR? or is it split into the different sections only |
| 16:34 | <Noam Rosenthal> | I'm always supportive of that. |
| 17:31 | <annevk> | What's the MR diff viewing thing? |
| 17:33 | <annevk> | Optimizing for AI while that's still changing week-to-week seems premature. I'm always open to people splitting a logical chunk away from HTML into its own standard though, as we did with Fetch, Infra, XMLHttpRequest and various other aspects. |
| 17:34 | <Noam Rosenthal> | It's not just for AI, also for github diffs and for IDEs. I don't know what having a single file is optimized for |
| 17:46 | <Noam Rosenthal> | but anyway, until there's any consensus on that, that kind of tool can help with the current version of what AI does |
| 17:50 | <Noam Rosenthal> | Re modularization, I think contenders can be canvas (8%, was a separate spec before...), microdata (2%), messaging (1.4%), drag&drop (1.3%). But that would make a small and temporary difference in terms of file size |
| 18:06 | <Noam Rosenthal> | Green now |
| 18:10 | <Shannon Booth> | Ah, sorry, I mean whatpr |
| 18:19 | <Luke Warlow> | https://html.spec.whatwg.org/multipage/forms.html#category-listed - is it just me or does the definition for listed elements read as if the form IDL attribute can also be used to specify a form owner?
|
| 18:21 | <Noam Rosenthal> | Isn't that what that attribute does? |
| 18:22 | <Noam Rosenthal> | (it doesn't specify that it's an actual element vs. an IDREF) |
| 18:22 | <Luke Warlow> | Yes the attribute does do that. But the form IDL attribute doesn't? To me this reads as if both allow you to do that. |
| 18:24 | <Noam Rosenthal> | ah yea it reads a bit implicit in that sense as if the IDL attribute is also a setter |
| 18:46 | <annevk> | That does not exist. Tobie would remember why. Prolly some tools cannot deal with the large input size. |
| 19:10 | <zcorpan> | I didn't mean changing what we publish, to clarify |
| 21:36 | <smaug> | jarhar: FWIW, we've been considering more pip-window like API for "Persistent Widgets". That would solve various issues around session history handling for example. (but might introduce others) |
| 21:39 | <smaug> | (but perhaps a new element is effectively that in some sense. The old proposal was iframe, and that wasn't good) |
| 21:53 | <jarhar> | thanks for the feedback! yeah having a PiP-like window makes sense for some cases, but the primary use cases seem to be more focused on the embedder having full control over how its rendered like an iframe |
| 22:48 | <smaug> | well, embedder would have. It would be bound to something in the new page |
| 22:49 | <smaug> | new element isn't less magical |
| 22:50 | <smaug> | pip approach might be also simpler for things like focus handling during page load. Maybe. But a new element might be then simpler after page load |