| 11:44 | <Noam Rosenthal> | annevk zcorpan : there seems to be agreement on what https://github.com/w3c/trusted-types/issues/615 should do, would it be best if I incorporate that into my current createParserOptions PRs? It seems like all of that should work together as one solution |
| 12:08 | <annevk> | Noam Rosenthal: yeah I think that should be part of the change. It seems that zcorpan already structured it that way as a PR against your branch? |
| 12:08 | <Noam Rosenthal> | Oh I've missed that in the bulk of github notifications I'm going through |
| 12:09 | <Noam Rosenthal> | great, thanks zcorpan ! |
| 13:23 | <Dominic Farolino> | I've reached out to the Chromium CL author to get things moving there |
| 13:29 | <Dominic Farolino> | Ah, for optional any arguments in WebIDL, there's no way to distinguish between missing undefined and explicit undefined, right? (Due to https://webidl.spec.whatwg.org/#js-overloads:~:text=any%20entry%20in%20S.-,If%20optionality%20is%20%E2%80%9Coptional%E2%80%9D%20and%20V%20is%20undefined%2C%20then,-%3A I suppose) |
| 13:32 | <Dominic Farolino> | It seems like the overload resolution algorithm erases the distinction between "missing" and "undefined", collapsing both to the former. |
| 15:44 | <mfreed> | Hi all, just a friendly reminder to post any discussion topics for this Thursday's joint CSSWG/WHATWG/OpenUI task force meeting to the meeting agenda issue: https://github.com/whatwg/html/issues/12956 |
| 20:08 | <dbaron> | What are the current best practices for naming and building class hierarchies for new HTML elements? In particular, after the discussion in https://github.com/openui/open-ui/issues/1189 I think I'm going to end up with a PR that proposes to add <menuitem>, <menuitemcheckbox>, and <menuitemradio> elements. In the existing proposal (with one element) the element's interface has three properties (disabled, checked, and defaultChecked). The checked and defaultChecked only really apply to <menuitemcheckbox> and <menuitemradio>. But it's also plausible that at some point in the future something (for example, something related to submenus) might apply only to <menuitem> and not to the other two. And it's possible that we want to avoid having an element's interface that inherits from a different element's non-HTMLElement interface, though maybe that's fine. In theory I could architecture-astronaut my way to introducing 5 new classes (MenuItemBase, CheckableMenuItemBase, and then one for each element) but I'm not sure if that's a good idea, although maybe it is a good idea from a feature detection point-of-view. And if I introduce intermediate base classes I'm not sure what the conventions for naming them are. |
| 21:58 | <Luke Warlow> | Spec wise I think you should just do 3 interfaces and perhaps do mixins for anything shared (like checked and defaultChecked) and maybe another mixin for disabled. Though tbh for 3 properties that aren't even fully shared just duplicating IDL attribute is probably fine. Given I think they'll all just be one liners because of modern reflection. In terms of how it's actually implemented I guess that's more a project specific question (e.g. servo wouldn't even have classes). But again I guess it depends what shared logic you want to colocate. |