Tie events to specific parts

[gregwhitworth]

We need a way in which to show transition of states and other modifications. The checkbox WD does a decent job of this but we need to get a bit more explicit. I think a table that looks like this may be preferable however to show events tied to specific parts as that's how they'll be implemented. In discussing this on discord we discussed having a table per part and the events that are attached to each one and their subsequent impact.

## PART
| Event   |  Behavior      |  Impacts |
|----------|:-------------:|------:|
| foo | the impacted change | State, aria, etc |

This then can be linked to from the the states table that's in the checkbox spec now by linking to the parts that impact a given state. I also added a column so people can quickly skim to see which events impact what. Thoughts?

[gregwhitworth]

@nicholasrice can you take a glance at the above - @dandclark and I have been discussing this

[nicholasrice]

This looks great to me - it sets up a framework for describing more nuanced interaction guidelines. Good idea!

[gregwhitworth]

Ok, I started doing this for <select> and before I go too much further I'd like to ensure this is the direction we'd like to continue going. Here's what it looks like:

One question I have is do we want to sort on event or impact? If markdown supported rowspanning I'd avoid duplicating the content so if anyone knows of a way to do that in MDX I'd love to hear it.

[dandclark]

Direction looks good to me. Dunno about the rowspanning but if you don't find a solution for it I prefer sorting on the event like you've done in this sample.

[dandclark]

Looking ahead a bit I wonder if we'll start running into issues with events that interact. For the listbox we'll likely have a row for blur that sets the open state on the host to false, closing the popup when the use clicks away.. Consider the case where the listbox is open, and the user clicks on the button part. That then triggers both the listbox blur's sets the open state on the host to false and the button click's toggles the open state on the host. If the blur one fires first, the result is that the popup stays open (or closes and immediately reopens). If we follow the normal DOM event order, that is the order we'd get per this little test: https://jsfiddle.net/dandclark_msft/wzs1mkc7/3/. But when I test with a native <select>, the behavior is for the popup to close and remain closed.

Those sorts of concerns are probably out of scope for what you're doing here, but it's something we might start pondering.

[dandclark]

One way to avoid that particular interaction would be to prepend the two click row behaviors with "If the host is in the closed state...". Where we know the corresponding listbox blur rows will handle the open case.

Edit: but that might not be satisfactory because a scripted .click() call on the button should maybe still close an open listbox, hmm...

[gregwhitworth]

As we just discussed on discord, we may in the future want to add in an additional column for current states of parts to handle different events in a specific way that may interact with one another. For now though, let's get all non-combinatorial events into the table and then reason about the overlap later.

[chaance]

Wouldn't the effects of a specific event depend on the current state? For example, keyup(ArrowDown) would either navigate a list of options or expand the options depending on whether or not the select is already expanded. Is it possible to capture this nuance in the table format without cluttering it up too much, or is this intended to be more of a brief reference with a more detailed spec available elsewhere?

[gregwhitworth]

@chancestrickland yep for sure, @dandclark and I have discussed adding a state column to allow for pivoting of that and that one is a good example of that. I'll file a separate issue for that as I'd like to get the initial ones in, I'm sure this isn't the entire list but it's an editor's draft afterall.

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.