<blockquote>

The two types ("before" and "on") of event seem very useful things to have.

Why is this "toggle" and not separate "open" and "close" events? The platform is not entirely consistent here, but these elements likely need distinct actions for the two cases. We can't see a reason for this being a single event type. (We'd like to see a path toward harmonization of events across the platform, but that's a larger project.)

We also agree with Dan about <details> and the opportunity for future work. That's not in scope here, but we encourage you to look into it.

</blockquote>

Jeffrey: two comments to choose from..

Matthew: both about consistency

Peter: two different things to be consistent with

Amy: what if we gave them both paths to consistency and handed the decision back

Peter: ask for a broader conversation among stakeholders

Jeffrey: they're likely to pick the one they've already gone with. We're only going to get a change for using open and close if we really push for it

Peter: push harder on the fact that we have established precedent with the open pseudoclass and property and that wasn't taken into consideration properly in the past and should be rethought

Matthew: any explainer about where they considered the alternatives and discussed it

Jeffrey: it's in the issue discussion: https://github.com/openui/open-ui/issues/607#issuecomment-1309330785.

Matthew: also discussion about how things might expand in future.. open and close might be all we need. Is there another aspect for which we could say this is likely to be better.

Peter: I can redraft to blend them

Jeffrey: the :open pseudoclass is newer than all of this. CSS can't do toggle there, they have to do open and close.

Peter: a resting state, not a transition.

New draft for the second option, from Slack:

<blockquote>

We want to emphasize the goal of consistency across the platform, between CSS properties, HTML attributes, and JS methods and events. Unfortunately, none of these are consistent in the current platform, so this change needs to instead chart a plausibly-consistent path forward.

Because <details> and <dialog> have open attributes, CSS added :open and :closed properties, and the event handlers seem likely to be more different than similar, we're inclined to think that the better path forward is to use "open" and "close" everywhere. That implies that it would be best for popover to also migrate from show/hide to open/close. (It doesn't imply that we should try to get rid of the various toggle*() methods.) We recognize that retrofitting new names onto shipped features is a big project, so it would be acceptable to just apply this pattern in the future, but if the community generally approves of this path, we'll file issues in HTML to suggest the retrofit.

</blockquote>

Jeffrey: I had a useful discussion with them this morning... About idea... The objection that it's more typing for authors came up....

Lea: is the idea that open and close would still exist? or phase it out?

Jeffrey: for elements that already have open/close it would stick around but for new things it would be toggle. New state.

Lea: I like this.

Tess: this feels like one of those cases where we are chasing API design fads... Ideally the web's API surface moves more slowly than trends in JavaScript libraries? When we hadd things to the web platform that doesn't look like the web but looks like popular JS libraries, then I would like to see some justification for that... There's no such things as adding web features in a vaccuum. My knee-jerk worry.

Jeffrey: It looks like the precedent that Domenic was following was the details element which has toggle....

Lea: besides what Jeffrey mentioned about details it seems that on the web platform we use a single event for state changes... So that seems to be on par... More than an open and close event...

Yves: as we already have open/close it's easy to have another state. In the case of a toggle it might be more difficult... Especially if you have 2 ways of doing the same thing... something about not doing the same thing 2 different ways in the design principles? There might be dragons.

Dan: https://www.w3.org/TR/design-principles/#consistency ?

discussion on toggle vs state change?

Peter: like a light switch - 2 positions.

Lea: state change is way to generic.

Jeffrey: things are open and closed - not much prospect to add another state... Following precednet - they were right to extend toggle to dialog.

Lea: What about popover?

Peter: uses toggle.

Jeffrey: the event is called toggle but the actions are show and hide.

Peter: having open / close events would be more consistent with CSS... Checkboxes... that pattern comes from other input elements that definitely have more than 2 states. In my mind having open/close event feels more proper. Having them as separate event handlers might be more convenient. Consistency is my main concern. Popover is the odd one out... Not sure that's the pattern to follow. At least "pick a lane and stick to it."

Jeffrey: writes proposal comment

Dan: noting positive review from Mozilla: https://github.com/mozilla/standards-positions/issues/1101

Peter: details has a boolean open attribute... I'd love us to be consistent between CSS, properties, and events... right now it's inconsistent.

Lea: a shared toggle event class? Then you could also do isevent instance of toggleevent...

Peter: a common base class named toggle is fine but more concerned with the event names... I think there's value to developers (DX) to get some consistency... Suggest we leave the comment and not close... but get feedback from the broader community...

satisfied with concerns:

<blockquote>

We want to emphasize the goal of consistency across the platform, between CSS properties, attributes, methods, and events. Unfortunately, none of these are consistent. Based on the history of details having a toggle event and dialog only having a close event, we think popover was correct to use toggle, and then this change is correct to extend that to dialog. There's an argument that open/close would be more consistent with the CSS :open and :closed selectors, but we think it's worth keeping consistency with the events.

</blockquote>

Or unsatisfied:

<blockquote>

We want to emphasize the goal of consistency across the platform, between CSS properties, attributes, methods, and events. Unfortunately, none of these are consistent. Because the elements have open attributes, and CSS added :open and :closed properties, we think the better path forward would be to use "open" and "close" everywhere, across event names and method names. This implies that it would be ideal to retrofit open and close events onto popover too, and we'll file an issue with HTML to ask to do that.

</blockquote>