Luke: Need to look in more detail. I think this is one in which the TAG has an important role to play in trying to steer them. This is the third or fourth attempt to try to solve in this problem area. They tend to focus on very scoped use cases, like a submit button, because someone has requested it, and I don't think they're thinking holistically. I think we need to step in and ask them to think wider.

Brian: We're not the first to mention that it's focused on a couple of very specific use cases. What happened to the other use cases? Do you know why, Dan?

Dan: We've had similar feedback coming from WHATNOT calls. The explainer discusses what may happen to resolution when you have a couple of behaviors attached. Most of the behaviors people are interested in shouldn't really be mixed, so they are not expected use cases. The API has been designed with the idea that we could support combined behaviors in future if we find several that make sense to combine. But things like submitting a form, or triggering a pop-up, wouldn't need to be combined. So we are thinking about the future, but catering for what people are asking for.

Brian: It feels like there's a lot in there about 'a submit button' as a use case. There are lots of simple use cases, but I'm not sure they're the most valuable. If we never got that, the web wouldn't end. How does that help me if there are other use cases? I'd like to see some more on that. It may've changed recently.

Dan: Submit is the focus at the moment. There are two goals: (1) create a framework for adding these behaviors generally; and (2) use submit as the first case. I agree maybe the example isn't the best one - maybe triggering pop-ups is a bigger use case. Those would be coming after this. Maybe this proposal should lay out the roadmap, paint what the endgame would look like. At the same time, we have to do something first.

Luke: There's a middle ground between designing every conceivable behavior, than laying out something concrete like just the submit button. Buttons are an interesting one to start with, as there are many overloaded ways to trigger it. Even taking a button element, thinking about the button element and its behaviors more completely (submit vs reset vs commandfor vs toggle, ...) could be useful. What about those future behaviors? Also somethihng that is not a button element. If we had 2 different elements' behaviors it'd make it a lot easier to explain. And explain how those would and wouldn't go together.

Dan: Most of the complex behaviors and interactions you mention apply to a submit button as well as a generic button. Including keyboard activation etc. I'm not sure switching to a generic button makes too much of a difference. I do like the point that something else, like <label>, is quite different, and would prove out the idea that behaviors could work.

Brian: Just having a list of other things you think people would use, like label, and moderately thinking through them, would help demosntrate that they will work. We risk building a solution that is built very much for that weird case.

Dan: The explainer does have a list - might be worth looking there.

Brian: I'd move those from 'future work' to into the design considerations. And show some kind of thought to them that shows we are not painting ourselves into a corner. I'm curious as to why this is the first case, too.

Lola: Encourage you to continue async and devise a comment.

Luke: Need someone to help me draft a comment. Looked into this, think there are quite some serious problems. API design is mostly ok, but there are other things. Seems they only want to ship submit button to start with.

Hadley: What’s the tl;dr of this?

Luke: Original form of this was that you could customize custom elements and add extra behavior. WebKit was opposed for a very long time, so there’s a new effort to see if WebKit could be brought on board. It gives you implicit submission behavior for a custom element. Not sure if we need this, but people have asked for it. Would be interested on what the other behaviors would look like. Might be ok depending on the behavior set, e.g. draggable. That depends on the design. Think Brian agrees with the submit button overfocus. Wider explanation of separate behaviors would be helpful.

Matthew: +1.

Luke to draft a comment and ask Brian for input.