| 06:18 | <annevk> | Yeah, that aspect would be observable with this change. I think if we had to preserve that I'd favor some kind of [VerifyArgument] annotation over attempting to change the type. So you'd have to write [VerifyArgument] (TrustedHTML or DOMString) input and [VerifyArgument] would take care of running the "verify/validate" algorithm based on the type of argument. Maybe that's a reasonable middle ground that would also allow the more complicated cases to rely on IDL. |
| 07:36 | <Ms2ger> | I'm not sure if running arbitrary validation code in the middle of IDL conversion excites me all that much. Is changing the order of operations a blocker? |
| 08:48 | <Luke Warlow> | We're already changing the ordering for some things (script element properties) so I don't think that's gonna be a blocker personally. It would be odd if people are relying on that ordering. And as we already use unions in some places its not consistently ordered already. |
| 08:59 | <dprz> | Sorry, yes, Chrome's behaviour for non-special URLs is currently incorrect, but we're working on it. You can star this bug https://issues.chromium.org/issues/40063064 to be notified when there are updates. |
| 14:32 | <Domenic> | I think the question is do implementations want to code-gen in their bindings or write custom per-method C++. If they want to code-gen in their bindings then I think it should be handled with an IDL extended attribute or type. I think this IDL construct should be very trusted types specific; I don't understand why we'd want something generic like [StringContext] or [VerifyArgument]. |
| 14:58 | <Luke Warlow> | My two cents are that implementations already have to write custom c++ in a number of cases (I count at least 11 separate places), so it's probably not particularly worse to have to do it for the 19 or so new places. That being said it's ultimately up to WebKit, Gecko and Chromium projects to decide if they're comfortable with that. |
| 14:59 | <annevk> | Given what CEReactions does I don't think the timing has to depend on where it's solved. Although I guess there's an interesting question as to whether CEReactions or this goes first? Also the fact that there's a number of cases that are not solved through bindings makes me rather wary about having a complete special case for a subset. |
| 15:01 | <Luke Warlow> | My two cents are that implementations already have to write custom c++ in a number of cases (I count at least 11 separate places), so it's probably not particularly worse to have to do it for the 19 or so new places. That being said it's ultimately up to WebKit, Gecko and Chromium projects to decide if they're comfortable with that. |
| 15:14 | <smaug> | Looks like the image around https://html.spec.whatwg.org/#attr-script-async isn't working too well in dark mode |
| 16:49 | <sideshowbarker> | jarhar: Can you remind me what setup you’re using with vim to get auto-completion when working on the Chromium sources? |
| 16:54 | <jarhar> | i dont use auto completion in vim. for browsing the code and figuring out what to write i just use source.chromium.org |
| 17:02 | <sideshowbarker> | ah OK (I vaguely recall now that’s what you’d already actually told me before…) |
| 17:14 | <annevk> | bakkot: I'm postponing merging Float16Array into IDL/WPT till Monday. Not feeling great and want to make sure it happens correctly. |
| 17:15 | <bakkot> | √, no rush at all given that it's only barely implemented in one engine |
| 18:07 | <hacknorris> | okay, this might be offtopic but better here than nowhere. someone knows any cool tutorial for writing xsd schemas? i'm that dumb i don't understand even from w3schools… |
| 18:11 | <hacknorris> | like i wanted to make something like sitemap.xml but for "bookmarks" of sites people like (idk how it's named. webring? maybe…) |
| 19:05 | <hacknorris> | so any tutorial? |
| 20:33 | <hacknorris> | nvm. manually downloaded sitemap.xsd from origin and learning from there 😕 |
| 22:19 | <TabAtkins> | Looks like the image around https://html.spec.whatwg.org/#attr-script-async isn't working too well in dark mode |
| 22:19 | <TabAtkins> | annevk or Domenic ^^^ |
| 22:21 | <smaug> | superb. Will there be a preview of that all? |
| 22:22 | <smaug> | ah, it is there now, I think |
| 22:24 | <smaug> | but looks like the new diagrams aren't there |
| 22:26 | <TabAtkins> | Yeah, I suspect it's still linking to the ones on whatwg.org, not the local files from the PR |
| 22:27 | <TabAtkins> | but if you drop in a .render-shell img { background: none !important; } into your inspector and look at the files-changed tab, you'll see the files against a dark background. |
| 22:29 | <TabAtkins> | you'll have to do it per-file, since they're in separate iframes, unfortuantely. |
| 22:29 | <TabAtkins> | oh, also need .render-shell { color-scheme: dark; background: #222; } |
| 22:30 | <TabAtkins> | then you can properly see the old image failing and the new one succeeding |
| 23:07 | <TabAtkins> | https://github.com/whatwg/whatwg.org/pull/439 as well, to cover the same problem cases across the rest of WHATWG specs. I'll review their usage of SVGs later, but for now just giving them a white background will ensure they're readable. |