WHATWG
2023-12-05
plaintext logs
prev next
source on github
00:47
<Domenic>

If you don't need a content attribute then you are just doing normal JS API design.

This is the part I'm curious about. I just don't really know when you would "need" a content attribute vs just stick with JS API design on the element's IDL interface. If someone says "I want to introduce a new 'attribute' on this element", then they've two options: (1) content attribute with automatic IDL reflection, vs (2) just IDL attribute, for a JS API. I'm not clear on how to provide guidance to select between those two. I would need to ask them a question relating to "If you need/don't need a content attribute" above. So I guess I'd ask "Can this just be a JS API on the element's interface, or do you need it to also be a content attribute". But to "need a content attribute" (i.e., an IDL attribute alone is insufficient) means your design desires to trigger the attribute's behavior without script... I think.. like just from HTML.

Yes, your last sentence is correct.
00:48
<Domenic>
In general HTML elements are designed as HTML first; the fact that they have JS APIs is an interesting addition in some cases.
00:48
<Domenic>
But if you just want a JS API then you can just design a JS API. Maybe even not tied to a HTML element at all.
03:56
<sirisian>
Has anyone ever suggested allowing an element to exist in two places in the dom tree? Like a <slot> that can point to another node? I have vague memories of reading about this over a decade ago before web components. Seems more feasible now though.
07:06
<annevk>
sirisian: we could use it for <select>, but it's more of a CSS feature I'd think
17:45
<sirisian>
@annevk That's exactly what I've always needed it for. I have thousands of drop downs and code to deduplicates such picker options. My code would be very elegant if I could just point to their options and not move stuff around manually.
22:51
<sirisian>
How did you envision that working? Thinking of trying to make a very basic proposal. "display: contents; contents: #foo;" I foresee two modes. #foo tag is slotted and another mode where #foo's children are slotted. So "contents: #foo" and "contents: #foo / children;" Not sure on the syntax.
23:34
<emilio>
That raises a lot of questions about all sorts of APIs. Lots of things assume an element has one principal box. E.g. how does something like getBoundingClientRect() behave?
23:35
<emilio>
Not trying to discourage necessarily, just pointing out that it's probably a bigger challenge than it seems