[popup] Naming for `show` and `hide` events

[josepharhar]

@domenic pointed out here that the show and hide event names may be too generic: https://github.com/whatwg/html/pull/8221#discussion_r965617087

I feel bad using the generic event names "show" and "hide" for something pop-up specific? Like, if I do el.hidden = true, I would expect this to fire a hide event.

I couldn't find any discussion about these event names in the list of issues at the bottom of the explainer. Does anyone know how we decided on these names? Does anyone have any thoughts?

[Kaiido]

That also struck me when reading the PR at whatwg/html. I believe it's particularily surprising since this event is also available on window. Reading window.onshow = (evt) => {... one would probably expect it to refer to the pageshow event rather than a popup in the document.

If I can start the bikeshedding, I guess popupshow and popuphide would be quite simple and clearer.

[mfreed7]

The counterpoint, I guess, might be that if later there are other non-pop-up things that show and hide, it'd be nice to re-use an easy set of events like show and hide.

If we indeed need to rename these, then popupshow and popuphide seem the most obvious and straightforward.

[domenic]

other non-pop-up things that show and hide

Well, I think <div>s show and hide pretty frequently already, when you e.g. change them from display: none to display: block...

[mfreed7]

other non-pop-up things that show and hide

Well, I think <div>s show and hide pretty frequently already, when you e.g. change them from display: none to display: block...

Then lots of show/hide events! Just kidding. Probably best to go with popupshow and popuphide. I don't see any other downsides, and it does make the context more clear.

Any objections?

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Naming for show and hide events, and agreed to the following:

• RESOLVED: we would like to support event names that are general, and are supported by anything that supports the `:open` and `:closed` pseudo classes. We need to determine the best names for these events.

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] Naming for show and hide events
<gregwhitworth> github: https://github.com/openui/open-ui/issues/607
<JonathanNeal> masonf: I would like to avoid bike shedding if we can. The issue is that the names we have for the events — `show` and `hide` are too generic.
<flackr> q+
<masonf> Proposed resolution: rename `show` to `popupshow` and `hide` to `popuphide`.
<JonathanNeal> masonf: This might be confusing. A developer might try to wire up one of these events and wonder why they don’t fire when something like `display:none` ‘hides’ the element.
<gregwhitworth> ack flackr
<gregwhitworth> That was what I was going to say
<una> q+
<JonathanNeal> flackr: we have these generic terms for CSS. The other option is to follow that convention?
<JonathanNeal> q+
<JonathanNeal> masonf: I suppose we could. That would add events to the dialog element. In principle, it does sound reasonable.
<gregwhitworth> ack una
<gregwhitworth> q+
<JonathanNeal> una: from a dev experience perspective, I would not want to have to know to use `show`, `open`, etc. I would definitely vote to make it as easy as possible to guess what the name is as they are coding. If we have normalized this in CSS, I think it would benefit the API to differentiate that.
<JonathanNeal> masonf: this has been discussed, and, in the context of open and close. The distinction made, particularly to dialog, that close is different than hidden and "open" and "shown" are different. Something can be "open" and not "shown". Like when the content is open but not displayed.
<JonathanNeal> masonf: having said that, for popup, we decided on shown and hidden. some parts of that ship have sailed.
<JonathanNeal> flackr: these would align with our css concept, tho?
<JonathanNeal> masonf: in that vain, would you suggest we rename `showPopup` to `openPopup`
<JonathanNeal> scotto_: there will always be one outlier.
<JonathanNeal> una: I agree there are cases where they are unique. However, when the naming doesn’t have that reasoning and it’s generic, we should try to minimize the number of variations in the syntax.
<emilio> <dialog> uses `show` tho...
<JonathanNeal> masonf: that’s a fair point.
<gregwhitworth> ack JonathanNeal
<una> @emilio 🥲
<gregwhitworth> JonathanNeal: I wanted to ask a question
<gregwhitworth> JonathanNeal: this open keyword being used as an event and CSS psuedo class being well aligned or not
<gregwhitworth> JonathanNeal: open, as a event, doesn't imply I suppose what it does under the hood
<gregwhitworth> JonathanNeal: the name can be evoked as an event
<gregwhitworth> JonathanNeal: the psuedo class can only be applied to something that can be opened or closed
<gregwhitworth> JonathanNeal: if that's not a shared sentiment then I agree with flackr and una on normalizing only if there isn't a footgun where an event doesn't limit itself to an element that can open or close
<flackr> qq+
<gregwhitworth> JonathanNeal: I do understand why you may want them to be different but if they can be normalized
<gregwhitworth> flackr: my hope is if we go with open and closed, they would be mappable that this element has moved to the state where that CSS is applied and that consistent meaning that you're looking for
<masonf> q?
<gregwhitworth> ack flackr
<Zakim> flackr, you wanted to react to JonathanNeal
<JonathanNeal> I’m back to scribing now.
<masonf> Proposed resolution: rename `show` to `opened` and `hide` to `closed`. These events should be fired for anything that supports the `:open` and `:closed` CSS pseudo classes.
<JonathanNeal> Sorry, I was listening. in the other way listening.
<gregwhitworth> ack gregwhitworth
<JonathanNeal> gregwhitworth: currently, it says `show` and `hide` which sound similar to dialog. So, should it be past-tense?
<JonathanNeal> masonf: there may be different cancel-ability.
<JonathanNeal> gregwhitworth: when we show it, is this when it is fired?
<JonathanNeal> masonf: technically, just before
<JonathanNeal> masonf: no matter how its invoked, this event gets fired
<tantek> q+
<JonathanNeal> gregwhitworth: why are we past tense then?
<masonf> Proposed resolution: rename `show` to `open` and `hide` to `closed`. These events should be fired for anything that supports the `:open` and `:closed` CSS pseudo classes.
<JonathanNeal> masonf: I am now convinced to go the other way.
<gregwhitworth> ack tantek
<JonathanNeal> tantek: CSS defines states. Events define transitions, which are verbs.
<emilio> There is a precedent for `:focus`
<JonathanNeal> tantek: I would not align them in names, and I would consider that an error. Aligning them conceptually is helpful. Trying to use the same name is different. They are not the same thing.
<emilio> (the event is focus / blur)
<JonathanNeal> masonf: this begs the question: the particular verb you use depends on the timing of the event.
<JonathanNeal> masonf: and the verb you choose depends on the timing.
<JonathanNeal> tantek: agreed
<gregwhitworth> q+
<JonathanNeal> tantek: the timing should be captured as well to communicate to the developer the lifecycle of what is happening
<JonathanNeal> masonf: any recommendations here? both of these events happen before the thing.
<JonathanNeal> tantek: I don’t have a specific recommendation for a specific name. But I would look at other events in classic HTML support, like loading documents and images, and see where the event gets fired and see if the names that were chosen at the time have any consistent pattern to them.
<JonathanNeal> tantek: I think some of them do have a consistent pattern that we may be able to reuse.
<JonathanNeal> tantek: sorry to answer your question with another question, but I hope it provides a path to a solution.
<JonathanNeal> gregwhitworth: +1 to what tantek said. My key thing is; I would keep with the theme of "open" and "close".
<JonathanNeal> gregwhitworth: when we generalize it (and I hate to delay stuff), say, theoretically, we outline these when they are fired and we decide the event is `beforeopen`.
<JonathanNeal> gregwhitworth: I am in support in being specific, but to Una and Jonathan’s point, I would prefer they are close.
<tantek> q+ to note possible difference between show/hide and open/close even in an event context
<flackr> q+
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack tantek
<Zakim> tantek, you wanted to note possible difference between show/hide and open/close even in an event context
<JonathanNeal> tantek: the other thought I had regarding this — I was in the CSSWG when this was talked about — that there is a semantic distinction between visually showing and hiding something and twidling something open or closed.
<JonathanNeal> tantek: on the other hand, something like showing or hiding a dialog is literally about showing or hiding those things.
<JonathanNeal> tantek: If these are different, I do not believe they should use the same name.
<JonathanNeal> tantek: it should reflect the semantic state of the component, even if it doesn’t reflect the css name, because the event and the css state may be describing two different things.
<JonathanNeal> masonf: if it is `display:none` it will be open but not visible.
<JonathanNeal> gregwhitworth: the 90% use case will be that it is ‘visually’ open
<gregwhitworth> ack flackr
<JonathanNeal> flackr: I wanted to make an argument for the timing of this. I think that, given the way we do animations, where we dispatch the event and then see if animations were added, implies that the pseudo class matching has already change, because you can already start animations on animations change.
<JonathanNeal> flackr: this aligns with `:focus` when you fire the event when it matches. I think this aligns, so the names are good.
<JonathanNeal> masonf: this event is explicitly fired first to allow for any animations, and then the selector matches once those have been completed.
<JonathanNeal> flackr: the fact that when you fire the event is not significant to that, because adding animations would not be related to the pseudo-class change.
<JonathanNeal> masonf: that’s a good point.
<masonf> Proposed resolution: we would like to support event names that are general, and are supported by anything that supports the `:open` and `:closed` pseudo classes. We need to determine the best names for these events.
<JonathanNeal> gregwhitworth: I don’t think we’ll be able to resolve on this. There is a lot of good insight.
<tantek> my understanding is that the event/JS aspect is lower level and thus happens first to allow "patching", while the pseudo-class state is higher-level
<bkardell_> I opened https://github.com/openui/open-ui/issues/621 as gregwhitworth requested earlier - sorry it is long :(
<JonathanNeal> gregwhitworth: I’m supportive of this last resolution.
<JonathanNeal> masonf: It might not be a great solution for all the other elements. I'm supportive of trying.
<JonathanNeal> tantek: I think part of the timing bit derives from JS being lower level, and being able to change things before all the CSS rules get changed, which are the higher level.
<JonathanNeal> tantek: the events I see as callback hooks to change or enhance behaviors that would otherwise be declarative.
<JonathanNeal> masonf: I am generally agreeing. We will need `beforeopen`, `afteropen`. There’s even an issue for that, to having paired events on either side.
<masonf> RESOLVED: we would like to support event names that are general, and are supported by anything that supports the `:open` and `:closed` pseudo classes. We need to determine the best names for these events.
<JonathanNeal> gregwhitworth: seems like we’re heading in a direction to have events tiered on either side.

[mfreed7]

I filed an issue with WHATWG/dom, since this is now a more general feature.

https://github.com/whatwg/html/issues/8386

[mfreed7]

I'm bringing this back due to conversation on the html issue. I'm beginning to think we should just add popovershow and popoverhide, and not add more general events. They don't seem useful, upon further thought.

[mfreed7]

One thought I had was to perhaps combine these two events into a single popover event:

popover.addEventListener('popover',() => {
  if (popover.matches(':closed')) {
    // This is a "show" event, because the popover
    // is going from :closed to :open
  } else {
    // This is a "hide" event, because the popover
    // is going from :open to :closed
  }
});

It takes more work to write the event handler, and it might be a bit confusing that the "show" event is detected by looking for :closed (because the event is fired before the state changes). Even more confusing (and perhaps worth a tweak to the hide animation sequence) is that for the "hide" event, neither :open nor :closed will match. The code I wrote above will work correctly, but if written the other way (looking for :open) it won't work.

But people seem to like short, easy to remember names, and popover is definitely that. The behavior is roughly equivalent to the toggle event for the <details> element.

Thoughts?

[domenic]

I like that direction. I think it will be less work for some use cases, e.g. event handlers that mainly want to sync the state change with some other part of the page and thus would have to listen to both events anyway.

Could we reuse the toggle event name? I guess we'd have to figure out what happens for <details popover> though. It'd be nice if we could make it work, but not sure it's worth it... Another option is popovertoggle as the event name.

To make writing such handlers easier, it might be worth considering adding an IDL attribute, e.g. popover.popoverOpen (or popoverState as an enum if it should be tri-state).

[scottaohara]

yah... though this has been humming along as a global attribute, I'd highly question why someone would even try to do <details popover>. Seems it doesn't even work correctly right now, as with the popover attribute it is still visually rendered even if it hasn't been invoked - but even if it did, someone would need a button to invoke the popup, which if not in the open state by default, would then require someone to then toggle open the content they just toggled open? that's some weird behavior... but arguably less weird than what can happen if contenteditable is put on the details element.

[mfreed7]

yah... though this has been humming along as a global attribute, I'd highly question why someone would even try to do <details popover>. Seems it doesn't even work correctly right now, as with the popover attribute it is still visually rendered even if it hasn't been invoked

This seems to be triggered by normalize.css containing this rule:

menu, article, aside, details, footer, header, nav, section {
    display: block;
}

but even if it did, someone would need a button to invoke the popup, which if not in the open state by default, would then require someone to then toggle open the content they just toggled open? that's some weird behavior... but arguably less weird than what can happen if contenteditable is put on the details element.

Well, you could do <details popover open> to have it start out open? I think the rest would still work though, right? I.e. when the <details> is shown (via .showPopover()), it'll still function as a normal details, where the user can toggle it. I hate ruling out elements, but if you think this is just too confusing, perhaps we could make <details popover> a disallowed element. It would be the only one at this point.

I like that direction. I think it will be less work for some use cases, e.g. event handlers that mainly want to sync the state change with some other part of the page and thus would have to listen to both events anyway.

True, but I'd guess most common use cases need to know hide vs. show.

Could we reuse the toggle event name? I guess we'd have to figure out what happens for <details popover> though. It'd be nice if we could make it work, but not sure it's worth it... Another option is popovertoggle as the event name.

Given the above, I do like "toggle" as an event name that we can re-use!

To make writing such handlers easier, it might be worth considering adding an IDL attribute, e.g. popover.popoverOpen (or popoverState as an enum if it should be tri-state).

This has been brought up before, and this shape of the event might push even more for something like popover.popoverOpen. On the tri-state question, the third state would just be when popover isn't a popover (doesn't have the popover attribute). We could make it a nullable boolean? Or just return false in that case?

[domenic]

On the tri-state question, the third state would just be when popover isn't a popover (doesn't have the popover attribute). We could make it a nullable boolean? Or just return false in that case?

I thought there was some third state while it was doing the animation, where neither :open nor :closed matches?

[mfreed7]

On the tri-state question, the third state would just be when popover isn't a popover (doesn't have the popover attribute). We could make it a nullable boolean? Or just return false in that case?

I thought there was some third state while it was doing the animation, where neither :open nor :closed matches?

Yeah, I was thinking popoverOpen would be just sugar for popover.matches(':open'), but you're right it would be more powerful to expose the full three states.

Perhaps instead of popoverOpen, we go with popoverState, with the following (nullable) enumerated values:

1. "open" === matches(':open')
2. "closed" === matches(':closed')
3. "transitioning" === !matches(':open') && !matches(':closed')
4. null (when element doesn't have popover attribute)

[domenic]

That would make sense to me. Although, coming back to the event, I wonder if it will have expected values when the event fires? E.g. maybe it will always equal "transitioning" during that time, which would not be so useful?

[mfreed7]

That would make sense to me. Although, coming back to the event, I wonder if it will have expected values when the event fires? E.g. maybe it will always equal "transitioning" during that time, which would not be so useful?

Yeah, I worried about that also. For the "show" transition, given the order of operations, the popoverState will still be "closed", so that's ok. As currently spec'd and implemented, during the "hide" transition, the event is fired just after the popoverState changes to "transitioning", which is unfortunate. But looking at the logic, I'm thinking we could/should reverse that, so that the state would still be "open" at that point. Then things here would be fairly clean, right?

[domenic]

Yeah, that sounds right. Although I guess all this complexity further convinces me that we should solve this without popover being a weird tri-state thing, as I communicated in https://github.com/whatwg/html/issues/7785#issuecomment-1317884823

[mfreed7]

Yeah, that sounds right. Although I guess all this complexity further convinces me that we should solve this without popover being a weird tri-state thing, as I communicated in whatwg/html#7785 (comment)

See my response https://github.com/whatwg/html/issues/7785#issuecomment-1317926256 and maybe let's not have the conversation both places. But I don't think you can avoid a tri-state thing, when there is a "hidden" state, a "showing" state, and some other state while you're animating. No matter what the API looks like, and no matter if it's Popover or dialog.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Naming for show and hide events #607, and agreed to the following:

• RESOLVED: Combine the events into a single "toggle" event, which is a new ToggleEvent type. ToggleEvent should have an attribute that has "opening" or "closing". Defer the discussion about adding a "popoverState" enumerated IDL attribute until later. Also defer the discussion on "afteropened" type events.

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] Naming for show and hide events #607
<gregwhitworth> github: https://github.com/openui/open-ui/issues/607
<hdv> masonf: this issue is about show and hide event. we have popoverhide, popovershow, two separate events that fire at the apt time
<hdv> masonf: there are two parts to the new proposal: one is to combine those to a single event that we could reuse the name toggle for
<hdv> masonf: that already exists for details/summary
<hdv> masonf: the word toggle nicely matches how we use it in popovertoggletarget
<hdv> masonf: part two of the proposal is that there would be a single event handler where you would likely want to be able ot branch depending on if you want to transition open or closed
<hdv> masonf: you could do it today with the pseudo classes open/closed
<hdv> masonf: so part two of the proposal would be something like `myPopover.popoverState` that would return a string like open, closed, no
<flackr> q+
<JonathanNeal> q+
<hdv> masonf: would make it easy to write event handlers that deal with when you're in open or closed state
<hdv> masonf: so this would be an IDL atribute
<gregwhitworth> ack flackr
<hdv> flackr: I think the transitioning state always means you're going to close, so I would suggest something like `closing`
<hdv> masonf: good point I think you're right
<gregwhitworth> ack JonathanNeal
<dbaron> q+ to ask about option of putting a property on the event
<hdv> JonathanNeal: my comment was about the IDL… can these states be reflected as CSS states
<hdv> s/states/states?
<hdv> masonf: they already are, :open, :closed
<hdv> Q+
<hdv> JonathanNeal: what is the rationale for adding the IDL?
<hdv> masonf: convenience… syntactic sugar over these two pseudo classes (open, closed)
<gregwhitworth> ack dbaron
<Zakim> dbaron, you wanted to ask about option of putting a property on the event
<hdv> dbaron: should the state either also or instead be reflected on the event itself?
<hdv> dbaron: for an event like this it is relatively common that event itself would have a property to distinguish between the different things that could be happening
<hdv> dbaron: I think for some cases this might be valuable?
<gregwhitworth> I kind of like it being on the event
<JonathanNeal> I would be interested in to see the DX we are talking about between the state being in CSS versus in an HTML attribute.
<hdv> dbaron: also begs the question, if you have the state on the event, how important is it to add it to the element as an IDL attr?
<hdv> masonf: one precedent I know of is the toggle event for details and the fullscreenchange event for full screen
<hdv> masonf: I believe both of those are base event
<hdv> s/event/events
<gregwhitworth> q+
<hdv> masonf: not sure which is betetr or worsr
<gregwhitworth> ack hdv
<JonathanNeal> Is the different like this? `event.target.matches(":fullscreen")` versus `event.target.hasAttribute("fullscreen")`?
<gregwhitworth> hdv: would the open and close pseudo classes in Chromium?
<JonathanNeal> s/different/difference
<gregwhitworth> hdv: are they denoted in the explainer, the answer should be yes to both
<gregwhitworth> s/hdv/masonf
<gregwhitworth> masonf: the open and closed pseudo classes are nominally applied to details/summary, probably selectmenu, etc
<hdv> masonf: :open/:closed pseudo classes were a CSS resolution they don't just apply to popover but also to dialog, selectmenu etc, anything that can open and close
<JonathanNeal> I was happy when I read that CSS resolution and the spec update.
<hdv> gregwhitworth: today you would be able to match media on the element, so this would be syntactic sugar
<hdv> gregwhitworth: so the DX different this would make it easier
<hdv> s/different/difference
<gregwhitworth> ack gregwhitworth
<hdv> masonf: the attr value does not say anything about the state, not whether you are currently open, closed or transitioning
<hdv> JonathanNeal: ooh, the whole time I thought that when you said IDL it was attributes in HTML reflected
<dbaron> s/some cases this might be valuable/some cases this might be valuable, such as a sequence of multiple event handlers where the first one changes the state -- then the second event handler would run multiple times and get confused about state/
<hdv> masonf: we already have that, this is a different one that tells you about the state
<hdv> JonathanNeal: as a property or content attr?
<hdv> masonf: both, they reflect each other
<flackr> q+
<hdv> masonf: the new one we talk about now is the popover _state_, that doesn't have a content attribute
<hdv> JonathanNeal: so it's like the open attribute and the :open CSS state and the el.open property
<hdv> masonf: there are myriad issues with having a content attribute that reflects the state and I want to avoid that if we can
<gregwhitworth> ack flackr
<hdv> flackr: so this is the evnt where you would set up a state that lets you create an animation to do the closing
<hdv> masonf: this may be an initial point of confusion… you get this event if you're trying to add a closing animation, if your state is open and you're about to close
<hdv> masonf: I'm about to land some code to make it more clear what state you're in
<hdv> flackr: that might be an additional argument to suggest having something on the event would be more convenient
<hdv> flackr: the event would say you're closing the popover
<JonathanNeal> Out of curiosity, is the event cancellable, if it is before the behavior?
<hdv> flackr: rather than the event is over
<JonathanNeal> q+
<hdv> masonf: it would be clearer, there would be two states, opening and closing, that would make it clearer
<hdv> masonf: a big motivation to add it was convenience for this event… maybe it is less necessary if we have it on the event itself
<hdv> flackr: I feel it would be less useful if we had it on the event and maybe not worth the effort now
<hdv> masonf: I do like it a lot more the more I think about it, it reduces confusion
<gregwhitworth> ack JonathanNeal
<hdv> JonathanNeal: I also like it being on the event
<masonf> Proposed resolution: Combine the events into a single "toggle" event, which is a new ToggleEvent type. ToggleEvent should have an attribute that has "opening" or "closing". Defer the discussion about adding a "popoverState" enumerated IDL attribute until later.
<JonathanNeal> +1
<flackr> q+
<gregwhitworth> ack flackr
<hdv> flackr: micronit… open and closed would be more canonical than opening and closing even if I recognise it is in the process of opening and closing
<hdv> masonf: what would the name of the state be? maybe that would clarify?
<hdv> masonf: if it says state 'open' you might think I must be closing now but it is actually shown
<hdv> una: are these states only showing during an interaction state?
<hdv> una: is it the process of transitioning?
<hdv> masonf: it is fired when it is about to begin the transitioning?
<JonathanNeal> So like how `click` and `keydown` happen during the triggering but before the behavior?
<hdv> una: is there a different state during transition and after transition?
<hdv> masonf: yes on the closing side at least
<hdv> una: so it seems if there are two events we need two states
<hdv> masonf: in the case of opening and showing there is one event, just before that activity (opening, closing) starts
<JonathanNeal> q+
<hdv> una: the convention seems to be, like for hover and focus, it is from the start of the action to doing it… so I think just having open, if you're styling the state of open or shown, that would make sense
<hdv> masonf: how about will open or will close or will hide?
<hdv> una: but there's only one event?
<hdv> masonf: you'll get two events, one for showing and the state would be show and another event after that
<hdv> masonf: you'll not get an event for closed or opened
<hdv> una: but there is an event for is open?
<hdv> masonf: no
<hdv> una: so that's just a state?
<hdv> masonf: yes
<gregwhitworth> ack JonathanNeal
<hdv> JonathanNeal: my experience with events would be to second when it was mentioned… how other event describe it is just before the behavior, like una did
<hdv> JonathanNeal: also click and keydown… then after an event happens I've seen two patterns: if we feel like there's a need, we can address that later. T
<masonf> q+
<hdv> JonathanNeal: a `playing` event is not cancellable
<hdv> JonathanNeal: maybe this is something we can tackle separately
<hdv> JonathanNeal: would be good to have the event be present tense, that would align most with other events
<hdv> flackr: I agree
<gregwhitworth> ack masonf
<hdv> masonf: keyup and keydown happen after the thing happened, practically… or well… it depends
<hdv> masonf: beforeinput is an event that happens before input happens
<hdv> masonf: maybe beforeopen and beforeclose ? it tells you the state you're going to without 'ing'
<hdv> brecht: when there are events like beforeopening they'll assume there will also be afteropening
<hdv> masonf: interesting point… there is an open issue for open and closed… because it turned out it is a little funny to have an 'after' for most of the things as there is nothing that happens after, except for popover maybe
<JonathanNeal> FWIW, `opening` and `opened` would mirror `seeking` and `seeked`
<hdv> brecht: there might be ideas where you could do something after it is open, you might want to target with CSS to do something extra, might be use cases when it comes to UI styloing
<hdv> s/styoing/styling
<JonathanNeal> ☝️ just throwing that out there, masonf.
<hdv> masonf: I see your point, but then you could use the CSS pseudo classes?
<JonathanNeal> q?
<hdv> masonf: ok so we have opening, open, willopen, beforeopen…
<hdv> JonathanNeal: there would be parity with seeking and seeked, if opening and open were those events, they would mirror the Media API
<hdv> brecht: personally I like opening because it is very clear, it tells you what it does, can't mistake it for something else
<JonathanNeal> +1 to opening
<hdv> una: I think the will verbiage is closely tied to React specifically, maybe familiar to many developers, but opening is closer to what you would expect
<hdv> gregwhitworth: are we entertaining opened?
<JonathanNeal> +1 to that it leaves the door opened for `opened`
<hdv> masonf: the door is *open* for it
<hdv> masonf: we could entertain it, I want to avoid just adding it because we can
<hdv> una: it seems there is no clear use case at the moment
<masonf> Proposed resolution: Combine the events into a single "toggle" event, which is a new ToggleEvent type. ToggleEvent should have an attribute that has "opening" or "closing". Defer the discussion about adding a "popoverState" enumerated IDL attribute until later. Also defer the discussion on "afteropened" type events.
<JonathanNeal> Eeeee
<flackr> +1
<JonathanNeal> q+
<gregwhitworth> ack JonathanNeal
<hdv> +1
<masonf> RESOLVED: Combine the events into a single "toggle" event, which is a new ToggleEvent type. ToggleEvent should have an attribute that has "opening" or "closing". Defer the discussion about adding a "popoverState" enumerated IDL attribute until later. Also defer the discussion on "afteropened" type events.
<JonathanNeal> I’ll be that person, but I might prefer `toggling`. :P
<JonathanNeal> But not in a blocking way. +1 to the resolution.

[mfreed7]

Thanks all!