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#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: https://github.com/WICG/webcomponents/issues/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.

[alexkeng]

adding more details for the TPAC discussion: (a full explainer will be published soon)

Goal To enable the following example:

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

Proposed Solution Introduce a new attribute type to ElementInternals. The example below shows how an autonomous custom element can define itself as a button using ElementInternals.type = "button", which enables it to have popovertarget/popovertargetaction capability (i.e., when the custom element is clicked, the associated popover element will perform the action defined by popovertargetaction):

class CustomButton extends HTMLElement {
  #internals;
  constructor() {
    super();
    this.#internals = this.attachInternals();
    this.#internals.type = "button";
  }
}

ElementInternals.type Values ElementInternals.type will support only button for now. Future expansions to include additional types, such as submit, label, or types derived from other form elements (see the full list at the end) are anticipated, but it'll be discussed/addressed separately.

Behaviors Accessibility When ElementInternals.type is assigned, the ARIA attributes of ElementInternals will be implicitly assigned accordingly. For example, if ElementInternals.type = "button" and ElementInternals.role is null, the custom element will behave as if ElementInternals.role = "button". If ElementInternals.role is assigned, it will take precedence over the default role derived from ElementInternals.type. If the role attribute on the custom element is assigned, it’ll take precedence over ElementInternals.role.

Focus When ElementInternals.type = "button", the custom element becomes focusable.

PreventDefault The popover behavior can be suppressed if the author calls preventDefault() in the click event handler of the custom element. This aligns with how <button popovertarget> handles preventDefault().

formAssociated The attribute can be either true or false.

ElementInternals.type is one type and the custom built-in element extends another This case is not possible at the moment as ElementInternals does not support custom built-in elements.

Alternative solutions ElementInternals.button = button Pros: TBD Cons: the extensibility is limited

<custom-button role=button> Pros: declarative Cons: backward compatibility. The attribute is designed/used with ARIA in mind. The new behavior is not necessarily what the authors want.

Full list of potential values for ElementInternals.type NOTE: this is NOT directly part of the custom button + popovertarget solution. The list is to give readers a sense of how the .type API could evolve. Each individual element would need separate discussion and our solution to button shouldn't be blocked by the progress of other element.

Derived from <input type=*>:

• button
• submit
• reset
• checkbox
• radio
• color
• date
• datetime-local
• email
• file
• hidden
• image
• month
• number
• password
• range
• search
• tel
• text
• time
• url
• week

Derived from other form elements:

• textarea
• label
• fieldset
• legend
• select
• optgroup
• option
• datalist
• output

[scottaohara]

If type took precedent over role, that’d be the opposite of how role is supposed to work.

Role should still be allowed to modify the role of the element, but the element should still have all the behaviors / functionality of the type that was declared.

[chrisdholt]

If type took precedent over role, that’d be the opposite of how role is supposed to work.

Role should still be allowed to modify the role of the element, but the element should still have all the behaviors / functionality of the type that was declared.

I would expect that element internals would set the default for the element and not take precedence over declarative syntax. Just as native HTML elements have default semantics which can have precedence taken by role, custom elements have this today (constrained) with ElementInternals. If I define the default role as "button" for my custom element with ElementInternals and then in HTML land add role="menuitem", the role is menuitem. I wouldn't expect that to change with "subclassing" here.

Just a note, but speaking specifically of button, this would solve a very longstanding issue and pain point with form associated buttons in that they cannot be a submit button: https://github.com/WICG/webcomponents/issues/814. Building off the very primitive example provided by Domenic, using elementInternals would take the strawman proposal slightly further but allow reusable, encapsulated, semantically correct, and likely more performant custom elements to be delivered at scale for design systems.

In the Webkit position on customized built-in elements, they brought up some very fair concerns about customized built-ins that this proposal may be able to address as well: https://github.com/WebKit/standards-positions/issues/97#issuecomment-1328880274

[scottaohara]

@chrisdholt yup that's what i'd expect. reading through this again, maybe i misread how the role/type were taking precedent over each other? but sounds like we agree, so if i did read that wrong, never mind me :)

[alexkeng]

yes, to clarify, the order of precedence is <custom-button role=*> > ElementInternals.role > ElementInternals.type

[sanketj]

Pasting in minutes from the ad-hoc extension of the joint WHATWG-CSSWG-OpenUI CG session:

Extend popovertarget to support custom elements github: openui/open-ui#1088 (comment)

sanketj: use case we're looking to enable is popovertarget on custom elements

sanketj: allow authors using custom element to ?? without any script

sanketj: we believe the proposal can be extended to other types of form control behavior

sanketj: proposal leverages element internals

sanketj: give the cusotm element button-type button behavior, support things like popovertarget/action

sanketj: also a11y things, if no role defined

sanketj: easy opt-in to communicate to the browser that this custom element should have button-type behavior on the page

chrishtr: so if clicked, will open popover?

sanketj: behavios just like , so if popover defined

chrishtr: so when click bubbles up it would be the default action?

sanketj: yes. can be preventDefault'ed

lea: what is current behavior?

sanketj: nothing. it does nothing

annevk: it's only an attribute for buttons

sanketj: you'd have to write script to call popover methods in JS

lea: are we limiting to custom elements with [limits] or any element?

sanketj: you'd have to give it type of button

sanketj: today, button regardless of type, can launch popover regardless

sanketj: maybe if extended later ???

sanketj: custom element needs to resemble the type of the native element it's emulating

lea: [missedq]

sanketj: set internals, and there you say it's emulating a button

lea: other values?

sanketj: none yet, but could do submit or others

lea: why not use computed role?

annevk: roles don't have API around them. They're only used for reflection to AT.

annevk: they're not semantic

annevk: all of ARIA is just affecting the accessibility tree; intentionally no other side-effect

<Zakim> Domenic, you wanted to talk about disabled=""

Domenic: Makes sense. one thing to keep in mind is interaction with disabled

Domenic: if form-associated, can be disbled

Domenic: so will need to check that the same way

sanketj: good point

keithamus: lots of subtle differences wrt e.g. activation via spacebar or enter etc.

keithamus: working inside a form or outside a form, should have consistency. but might be confusing to developers

Domenic: spacebar thing is interesting. would adding this make spacebar cause click events?

sanketj: for behaviors, have we discussed in WHATWG?

keithamus: We resolved that if it's a form participant, needs to have type=button as content attribute

keithamus: and has to be a tag of button (or exception for this case)

keithamus: so we should make provisions the same

sanketj: so strictly needs to be of type button if form-associated, but if not they could be of type reset or submit as well?

sanketj: We want this behavior to also extend to ??? things like commandtarget

sanketj: ideally work the same

keithamus: lots of small assitive pieces like spacebar that have implicit ????

annevk: is that what we do for form-associated elements?

Domenic: web devs add own keyboard/click listeners

Domenic: if it is going as far as behavior, then maybe it should do the spacebar->click translation also …

sanketj: proposal is if you set type=button, and no explicit role set anywhere, then it gets implicit role of button

sanketj: if element-internal role, then those take precedence

lea: I agree ARIA should not produce side-effects, but what about the other way?

lea: would type=button cause ARIA to compute to button?

Domenic: different about ??, but should reflect in AT

keithamus: we already have the different levels

annevk^: do we want that many layers of abstraction?

annevk: not reflecting in element internals

keithamus: I consider that part of raw computation. Another lookup in the if-chain

keithamus: aria-reflected will always be whatever content attribute is

annevk: idk if it matters about table

annevk: but I think we can just put it on the internals

Domenic: element.internals role is to define its default role

Domenic: if designing button from scratch, would set it

Domenic: now saying you can set type

Domenic: but could also set internals

Domenic: but C++ elements don't have this third way

Domenic: For every built-in element there's C++ dfeault role, and there's content attribute. Now we're adding third one.

keithamus: we have third raw computation already

Domenic: which element?

keithamus: I believe there's code that computes roe

annevk: but that's just flattening the role, if multiple are specified in the attribute

annevk: but that's still only one level, it's not an extra level

Domenic: might not agree on how many levels there are, but question is do we want to add the additional leveL?

Domenic: [missed]

sanketj: so you're proposing it should change element.internals.role

sanketj: if you never set role, and you query element.internals.role then you get button

annevk: Should this be on internals? Form-associated is on constructor.

lea: it's static

lea: my high-level concern was to not have authors declare their intent twice

lea: otherwise will end up with wrong roles

+1 lea

lea: so don't mind how it happens, as long as simple case works by default

lea: and allow override in internals

Domenic: all agreed, but just question of how

annevk: do you remember why form-associated is static?

Domenic: for inheritance, which webkit doesn't support

Domenic: could do autonomious custom button inheritance

keithamus: common practice ot have a base classs and then extend it

keithamus: can't think of why you'd have inheritance chain for button

annevk: e.g. submit button subclassing from button

Domenic: if you call super, then the superclass will set element.internal.type

keithamus: a lot of internals can only be captured once, so if you are defining ?

Domenic: oh, basically can't use element.internals for inheritance

keithamus: element.internals throws on the second call

annevk: so we have static form-associated, should this match that existing pattern yes/no

bkardell_: I like it, but

annevk: Oh, I wanted to say that too

bkardell_: but explainer doesn't mention :focus-visible, but that should also apply

bkardell_: we did so much work to make :focus-visible work, if we make it so that doesn't work it'll be a step backwards

annevk: focus for custom elements is an unsolved problem

annevk: don't know which kinds of elmeents to opt in

Domenic: problem with focus is, say "want to be keyboard focusable or mouse focusable" but what you actually want is to match platform conventions

Domenic: so best proposal was "behave like a button"

Domenic: tried to be too generic

Domenic: but this is more specific, so can solve it

annevk: I guess that works

Domenic: not 100% certain it'll decompose well with the hypothetical future, but 80% sure

annevk: if just going to be default buttons or submit buttons?

Domenic: I hope they have same focus behavior

annevk: yes but different selector matching

sanketj: intent is type=button is button type=button

sanketj: if you want to make it submit, then need type=submit

<bkardell_> selector matching is a good point too

annevk: Maybe do more than just type? or is it open to e.g. hyperlink, submit button, etc.

Domenic: yes that's the idea

annevk: so really big enum

keithamus: wrt roles, image has non or presentation depending on herusitics

keithamus: table has ??

Domenic: those are set by a single property, not two layers

keithamus: Not to derail too much, but what if HTML button had a superclass that was designed for this kind of inheritance pattern

keithamus: woudl be like "is" but sidestepping issues around custom eleents

keithamus: would that ... work?

sanketj: one thing we want to ensure, challenge today, is attaching shadow DOM

sanketj: can't do for something that inherits from HTMLButtonElement

keithamus: I'm proposing a new class, e.g. HTMLAbstractButton, between HTMLElement and HTMLButtonElement

??: do we have anything like that today?

annevk: nope

annevk: but none of those can be extended and used as custom element

keithamus: could we extend HTMLHeadingElement?

annevk: I'd be worried about changing inheritance of existing elements

Domenic: why is this better than element.internals type?

keithamus: I think it's more consistent for developers

keithamus: authors want to extend more than just button

keithamus: we're already talking about other types of buttons and inputs

keithamus: not necessarily a point against this proposal, but ...

Domenic: both would work

annevk: either way would need to go through element.internals

annevk: so not getting much except the type

annevk: and it gives us longer prototype changes, and compat headaches

annevk: maybe impact is negligible but doesn't seem great?

the superclass idea is really interesting

annevk: if there was a concrete benefit

Domenic: conflicts with any base classes that authors might want to use, because can't have more than one

acl leaverou

lea: Value space of this new property... looking at thread seems to mix input types with element types

<Zakim> leaverou, you wanted to ask about property values

lea: e.g. range -> input type=range; textarea -> textarea

lea: worried it might not be future-proof

lea: perhaps a pseudo-selector syntax might work? e.g. writing out the tag name and if want to specify similar to input type=range use input[type=range]

annevk: could we use input-range?

lea: introduces a new microsyntax

Domenic: doing that anyway, but it's a subset of an existing one

annevk: but enums are much easier to parse

lea: wouldn't need a full CSS parser

sanketj: type as an attribute is very familiar, in input and button

sanketj: so keeping alignment would be good for developers

input[type=range] vs input[type="range"] would be surprising if only one of them work

Domenic: I'm sympathetic with this worry. We had this problem when solving focus thing

Domenic: didn't come up with a good solution

Domenic: but also this proposal is very simple, and that's attractive

Domenic: do we have anticipate conflicts between tag names and input types?

Domenic: I could see that happening

(total side comment on an earlier discussion: the details of the keyboard activation behavior for buttons are awful, see https://issues.chromium.org/issues/40863985#comment6 )

lea: we already have conflicts, like search

Domenic: there are complexities to attribute selector syntax, but also sympathetic because devs might find it useful

lea: also room for future extension, e.g. if we need to identify children of a particular eleents

annevk: it's not a microsyntax, it's an enum

annevk: what if you put random other things in?

??: could restrict it to [missed]

lea: just restrict it to '['...

zcorpan: it's surprising to have a syntax that looks like a selector but parses differently

zcorpan: e.g. people will expect to be able to use quotes here

zcorpan: also, select element has two different kinds of widgets, which have a complex way of deciding which one to use

zcorpan: so select[multiple] or select[size]

lea: if we went with enum approach, how would you distinguisH?

zcorpan: select-dropdown vs select-somethingelse for example

lea: but now moved to unfamiliar keywords

lea: introduces more API surface

lea: if connecting to something already familiar with, then easier to relate

annevk: if know about select, select-optionA and select-optionB is not that hard

(if it's select-single and select-multiple?)

lea: how would it grow in 10 years?

Domenic, anne: probably only ~ 5 values

lea: ideally this should serve all the "behaves like this element" use cases

keithamus: value of button adheres to both options, so let's resolve on button and we can have this argument when we need it?

lea: I think 2 main classes of use cases

lea: custom elements that behave like buttons

lea: and custom elements that wrap buttons

lea: in latter case, which element do you want to actually be the popover target?

lea: whereas in first case you generally want to make that custom elemet a popover target

lea: Seen it come up many times, a big class of custom elements is simply wrapping a native element and adding some scaffolding / styling

lea: essentially want to forward things to the shadow DOM built-in element

lea: what do people think?

???: for subset of that problem, doing a breakout tomorrow

lea: worried we solve this as smaller problems and not seeing the forest for the trees

gregwhitworth: scenario in which you bind button via popover target to custom element ... is it because you don't know the ID? why is it a problem

sanketj: wrapped button is largely to get around the limitation that we are trying to solve

sanketj: so if we solve this, maybe we'll start seeing less of that pattern

bkardell_: was going to say the same

bkardell_: we've talked about this kind of thing before

bkardell_: e.g. referencetarget

@fantasai @sanketj I don’t think so, happy to discuss further but don't want to derail this discussion

bkardell_: some of it comes out of Apple's objection to 'is'

bkardell_: is it a button, or does it contain a button? Is it compositiion or inheritance?

keithamus: one way to get around lack of built-in is to use referencetarget

lea: still need an easy way to forward internals in an API

lea: right now need to reimplement everything

bkardell_: I think for button this works fine, but it's the easiest

bkardell_: how realistic is it to extend

bkardell_: do you run into the same kind of problems if you'r doing inheritance-based things for e.g. select

bkardell_: how can you say "this is a select"

bkardell_: wondering if we've thought about those limits, are we ok with them

bkardell_: will we end up with multiple different solutions

bkardell_: for button we can infer so much of the magic, we know exactly what it means to be a button

bkardell_: no parts to it

sanketj: type attribute, when we add things to it, have ability to think through -- does it make sense? It's not allowing eveyrthing

annevk: and what additional API params you need for it

bkardell_: it took so long to get one...

annevk: good to start. let's start with button!

@Domenic btw that proposal also uses "meta-selectors" to specify a class of elements, whose grammar is defined exactly how I described :)

<Domenic> Indeed, there was a reason we didn't ship it :)

sanketj: seems to be overall support for working on this

sanketj: some issues to note, e.g how does type reflect into role; how to deal with element/attribute name conflicts

sanketj: we'll work on it

annevk: can you open issue agianst HTML spec also?

sanketj: yes

bkardell_: would you pick one more besides button to think through?

sanketj: currently submit/reset

sanketj: but label could be another one

annevk: those are often requested (other than reset)

chrishtr: can we resolve on what we agree on so far?

PROPOSED: elementInternals.type='button' enables custom elements to get button-like semantics

https://open-ui.org/components/richer-text-fields.explainer/

RESOLUTION: elementInternals.type='button' enables custom elements to get button-like semantics

[EisenbergEffect]

Can we get a declarative mechanism for type so that we can use it in combination with server renderered shadow dom? In general, we need declarative mechanisms for the internals APIs.

[sanketj]

Can we get a declarative mechanism for type so that we can use it in combination with server renderered shadow dom? In general, we need declarative mechanisms for the internals APIs.

I think we would need declarative custom elements to unlock those benefits. Right?

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.