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

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? 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+ 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 q+ q+ scotto 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 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 q+ 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 are putting this on is a button means it won't work the majority of the time 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 alexking: We can agree with that, it makes sense to me 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 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+ 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 the rest? ack masonf 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 masonf: there is one implementer who is against builtin custom elements but I agree that it is the better solution masonf: some browsers ship this - just one doesn't. 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 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

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 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 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 :) 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?