We discussed firing a checked or change event on checkable menu items that have their state changed due to activation. So from this, there are two questions:

• What event should fire at the menuitem element? Should it be change or checked? It was noted somewhere that change feels a little weird for a non-form-control element. But at the same time it's familiar, and can already be used on form control elements that are not form associated, so I'm not sure how much we should led form-ness inform our decisino. I think I slightly lean towards change, but am open to introducing a new checked event if people feel strongly.
• How should firing this event interact with the click event that we decided in [menu] Should an event be fired when a <menuitem> is selected? Which event? #1312 should be fired when a menu item is activated?
  • Right now for appearance: auto select, when a new entry is selected, first a change event is fired at the <select>. Then, a synthetic click event (for example, if you hit Enter on the new option) is fired at the <select>. This seems to be consistent with what http://html.spec.whatwg.org/C#activation expects. I'm using https://jsbin.com/lexipis/edit?html,output to test.
  • For appearance: base-select, when a new entry is selected, first a change event is fired at the <select>. Then, a real click event is fired at the selected <option> only if you actually click it! If you pound Enter on it, you only get a change at the <select>, and never see a click.
  • For menu elements, I think this leaves us with firing a change (or checked, if we decide) event at the menu item element that was selected, and then immediately after, a synthetic click also at the same menu item, per the outcome of [menu] Should an event be fired when a <menuitem> is selected? Which event? #1312, since we will have activated the menu item. Alternatively, we could fire the change/checked event, and then omit the click since we had change/checked handlers. I think this would be novel though.

The first part of this issue is mostly event name bikeshedding. Does everyone agree with the second part of the proposal: firing two events back to back for this case? Are there any concerns with doing that? I vaguely recall @mfreed7 registering some worry about this.