Extend popovertarget to support custom elements

[alexkeng]

We (Edge) are interested in exploring how we can extend popover API to support custom elements.

Two questions:

1. Is there any concern blocking us from extending popovertarget to support custom elements? The extension has been discussed in several forums (eg., #9110, #9109 in whatwg, and #302 in openui), so far no conclusion has been reached yet, but from what I can find, it seem the community in general believes that the API would be cleaner and easier to use if we could use popover/popovertarget declaratively cross root.
2. If there is no major concern, with the new spec command/commmandfor anticipated to eventually replace popovertarget, do we still want to invest in adding new capabilities to popovertarget? or should we focus on pushing command/commandfor?

@mfreed7 @keithamus @sanketj

[keithamus]

Could you explain more about what you intend to extend? Is the proposal to allow custom elements to have the popovertarget or commandfor attributes? Or is it to extend the value of those attributes to penetrate shadow boundaries or something different?

My opinion is that commandfor has supportive positions from three major browsers and as such I think investment should go into that attribute rather than popovertarget. While we have yet to seek official positions on the deprecation of popovertarget (it would be a little early given commandfor hasn’t shipped) I remain confident that we will pursue deprecation soon.

[alexkeng]

The main goal is to make this example work:

<custom-button popovertarget="foo">Show Popover</custom-button>
<div id="foo" popover>This is a popover</div>

And if we think focusing on commandfor is the preferable direction, then the goal would be to make this work (while leave popovertarget unchanged):

<custom-button commandfor="foo" command="toggle-popover">Open Popover</custom-button>
<div id="foo" popover>Hello world</div>

[sanketj]

@gregwhitworth Could we add this issue to the agenda for the 9/12 meeting? I don't have permissions to add labels.

[gregwhitworth]

@sanketj done, also updated your privileges so that you should be able to modify the labels

[css-meeting-bot]

The Open UI Community Group just discussed Extend popovertarget to support custom elements.

The full IRC log of that discussion

<bkardell_> masonf: There are two directions for the interest target api - a central one, or 'don't do that' - just provide the lower based API that make each thing possible.. Is it better to have a bunch of lower level APIs or a higher level API? If it is lower level it seems like, harder to get the accessibility right? wdyt?
<bkardell_> alexking: I am a web platform developer from Microsoft. The issue is about two things: it seems it has been a pinpoint for developers that they can't use a popover (or invoker) on a custom element...
<keithamus> q+
<gregwhitworth> q+
<gregwhitworth> ack keithamus
<masonf> q+
<bkardell_> keithamus: the reason we picked buttons is for accessibility - they already have the right interaction model, they are exposed the right way, they are the semantically relevant element - none of that is true for custom elements out of the box
<bkardell_> q+
<masonf> q+ scotto
<bkardell_> keithamus: if it gets commandfor does it automatically get all oft hose things
<gregwhitworth> ack masonf
<gregwhitworth> q--
<gregwhitworth> q-- gregwhitworth
<keithamus> q+
<masonf> https://github.com/whatwg/html/issues/9110#issuecomment-1516468633
<bkardell_> masonf: there's a couple of threads you linked to about this. my pref would be to solve the more general "how do you make a custom element that works like a regular button" - there is a suggestion from annevk that says you can put an element internals that just does all that. That makes sense to me. I think it would be better to solve generally and then use that here
<gregwhitworth> ack bkardell_
<gregwhitworth> ack scotto
<sanketj_> q+
<bkardell_> scotto: to echo mason, I understand the use case on custom elements - why use a button when I could use a button that smells like me, my own button. We need it to be a button - exposed as a button... you need to get the a11y semantics and so on. You can use JS right now to make it do all of the things, but you have to do a lot of work to make it accessible. Just allowing this on custom elements without getting the promise that what they
<bkardell_> are putting this on is a button means it won't work the majority of the time
<bkardell_> scotto: so that is the blocker. It should work on a button, but without that author requirement it is going to do harm and people are going to abuse this in ways that won't work for people
<gregwhitworth> ack keithamus
<bkardell_> alexking: We can agree with that, it makes sense to me
<bkardell_> keithamus: There are broader discussion since we don't have is="..", how do we make it into a button? It's not just buttons tho - those are common, so you wind up talking about it, but there are things like tables and lists where you can't have a custom <tr> or <li> because they can't be parsed that way
<bkardell_> keithamus: maybe this is too abstract but maybe we need to look at how to open the parser to how we can interleave them, or maybe make some kind of behavior you can mix in... button has the behavior of my button - they are compositional - we discussed some of these ideas at TPAC last year... the internals, I feel like that's ok, but we're going to wind up with a list of those
<gregwhitworth> ack sanketj_
<masonf> q+
<bkardell_> sanketj_: this is fantastic feedback - the element internals thing is definitely something to go back and look at. This whole discussion is about button and then making the custom element act like a button, but is it specifically the point that it is button and button like, or is it... like, hypothetically if you wanted to use input type checkbox as a popover host - are there things you could to do enable that while still supporting all of
<bkardell_> the rest?
<gregwhitworth> ack masonf
<bkardell_> masonf: are you saying it's not just custom elements, could we make even input type checkbox as a thing that does a popover... we talked about this while designing it. Everything else that isn't a button is different, that's why we didn't do that - they would have other issues
<bkardell_> masonf: there is one implementer who is against builtin custom elements but I agree that it is the better solution
<bkardell_> masonf: some browsers ship this - just one doesn't.
<bkardell_> sanketj_: you mean like extends? That too had it's limitation, you wouldn't be able to attach a shadow Dom, it still doesn't work
<bkardell_> masonf: I'm not saying it fixes all problems, I'm just saying a more general thing - a way that makes it behave as much like a built in would be ideal

[chrisdholt]

The Open UI Community Group just discussed Extend popovertarget to support custom elements.

The full IRC log of that discussion
<bkardell_> masonf: There are two directions for the interest target api - a central one, or 'don't do that' - just provide the lower based API that make each thing possible.. Is it better to have a bunch of lower level APIs or a higher level API? If it is lower level it seems like, harder to get the accessibility right? wdyt?
<bkardell_> alexking: I am a web platform developer from Microsoft. The issue is about two things: it seems it has been a pinpoint for developers that they can't use a popover (or invoker) on a custom element...
q+
q+
ack keithamus
q+
<bkardell_> keithamus: the reason we picked buttons is for accessibility - they already have the right interaction model, they are exposed the right way, they are the semantically relevant element - none of that is true for custom elements out of the box
<bkardell_> q+
q+ scotto
<bkardell_> keithamus: if it gets commandfor does it automatically get all oft hose things
ack masonf
q--
q-- gregwhitworth
q+
https://github.com/[whatwg/html/issues/9110](https://github.com/whatwg/html/issues/9110)#issuecomment-1516468633
<bkardell_> masonf: there's a couple of threads you linked to about this. my pref would be to solve the more general "how do you make a custom element that works like a regular button" - there is a suggestion from annevk that says you can put an element internals that just does all that. That makes sense to me. I think it would be better to solve generally and then use that here
ack bkardell_
ack scotto
<sanketj_> q+
<bkardell_> scotto: to echo mason, I understand the use case on custom elements - why use a button when I could use a button that smells like me, my own button. We need it to be a button - exposed as a button... you need to get the a11y semantics and so on. You can use JS right now to make it do all of the things, but you have to do a lot of work to make it accessible. Just allowing this on custom elements without getting the promise that what they
<bkardell_> are putting this on is a button means it won't work the majority of the time
<bkardell_> scotto: so that is the blocker. It should work on a button, but without that author requirement it is going to do harm and people are going to abuse this in ways that won't work for people
ack keithamus
<bkardell_> alexking: We can agree with that, it makes sense to me
<bkardell_> keithamus: There are broader discussion since we don't have is="..", how do we make it into a button? It's not just buttons tho - those are common, so you wind up talking about it, but there are things like tables and lists where you can't have a custom or

because they can't be parsed that way
<bkardell_> keithamus: maybe this is too abstract but maybe we need to look at how to open the parser to how we can interleave them, or maybe make some kind of behavior you can mix in... button has the behavior of my button - they are compositional - we discussed some of these ideas at TPAC last year... the internals, I feel like that's ok, but we're going to wind up with a list of those
ack sanketj_
q+
<bkardell_> sanketj_: this is fantastic feedback - the element internals thing is definitely something to go back and look at. This whole discussion is about button and then making the custom element act like a button, but is it specifically the point that it is button and button like, or is it... like, hypothetically if you wanted to use input type checkbox as a popover host - are there things you could to do enable that while still supporting all of
<bkardell_> the rest?
ack masonf
<bkardell_> masonf: are you saying it's not just custom elements, could we make even input type checkbox as a thing that does a popover... we talked about this while designing it. Everything else that isn't a button is different, that's why we didn't do that - they would have other issues
<bkardell_> masonf: there is one implementer who is against builtin custom elements but I agree that it is the better solution
<bkardell_> masonf: some browsers ship this - just one doesn't.
<bkardell_> sanketj_: you mean like extends? That too had it's limitation, you wouldn't be able to attach a shadow Dom, it still doesn't work
<bkardell_> masonf: I'm not saying it fixes all problems, I'm just saying a more general thing - a way that makes it behave as much like a built in would be ideal

This is a great conversation and I was sorry to yet again miss - Thursdays are brutal for meetings these days :).

In terms of built-ins, that could be an option, but given that there is an implementor who is fundamentally opposed, it's not something that can scale well as a solution. The lack of a shadow root aside, if we had broad agreement from implementors, I would be much more open to this as a direction.

While the initial conversation is around popover, that's more a singular instance of the overall problem IMO. Consider the <label></label> element - there is literally no way to get label semantics outside of using that element. If we stick it in a shadow root, we've got cross-root aria problems (solved but not scaled/shipped). You also have the reality of creating layers of elements (element w/ shadow root => semantic element) where one would suffice...at scale and as a convention, this creates increased cost from a performance standpoint. Built-ins help solve this as well, but again, there is an implementor that has signaled they are fundamentally opposed and will not implement.

In terms of using element internals, both of these use cases (and more) could be solved if there were a way to inherit the behaviors and semantics of a native element as part of that API. It seems like that's what was potentially proposed, and if it's feasible, could be a good way to ensure that something signaling as a button performs as a button. It's possible that could help solve the long overdue issue where custom element buttons can't act as submit buttons: WICG/webcomponents#814.

elementInternals.extends = "button" or elementInternals.implements = "label" or whatever is the best semantic would be a welcome addition.

Ultimately, my growing concern is that while the declarative API's that are being iterated on are helpful for part of the web platform, they leave out a first-class citizen in Web Components, which is the web platforms design for componentization - a central delivery method of most design systems these days. If our goal is to advance the web platform, it seems like we need to keep an eye on how these solutions scale to it's own component model. Without that as a core consideration, it feels as though we're not delivering on a holistic solution.