calcite-dropdown: Add additional placement options for left/right

[ellenupp]

Description

Currently, the only documented placements for the dropdown are variations of top/bottom. We have a scenario where it would be ideal for the menu to open to the left or right instead. Setting any valid popper placement currently appears to work (example), but it would be nice if these were more officially accepted and documented as options. Didn't necessarily want to use these options as is if there's a chance they would be deprecated in the future since they aren't documented.

Acceptance Criteria

left-* and right-* are valid placement options for calcite-dropdown

Relevant Info

No response

Which Component

calcite-dropdown

Example Use Case

[driskull]

hey @ellenupp I'm not sure we want to support those.

I think for these kind of menus like dropdown, combobox, etc. We only want to have them open above or below consistent with how native select menus appear.

@jcfranco @benelan Maybe we can further restrict them from even working if we are concerned with users setting them.

[ellenupp]

I guess my use case is not a typical use case for a dropdown, where it'd be in a form or such. These are floating menus that appear around each widget on the dashboard. That means their position will be highly variable (depends on dashboard layout & also browser window size) and there may or may not always be space for the menu to open above or below the trigger, in which case it'll need to open next to it to avoid being cut off. It'd just be really nice if the dropdown supported those placements because it otherwise works really well for these menus.

[vijayendranj]

@driskull Is there another UI calcite proposing in those scenarios?. simply restricting them from working is not a good user experience. Users use browsers in several ways for ex. if the layout goes from landscape to portrait the height may be considerably less.

We'd be happy give a demo of how we are using this in Dashboard.

[ellenupp]

Here is a video showing the usage, including an example where left placement is preferable over top or bottom.

[macandcheese]

I don't think allowing dropdown to appear as requested here is a risk - I agree for input-related "floaties" (combobox) - it should be restricted to above / below. Dropdown can be invoked from any trigger - where having it on the side as shown above makes sense.

[jcfranco]

Dropdown can be invoked from any trigger - where having it on the side as shown above makes sense.

@macandcheese @ashetland @SkyeSeitz Can we confirm if this is a supported use case from the UI/UX perspective? If so, we should widen the placement options.

According to our doc, any element can be slotted as a trigger, so it's not clear what our dropdown trigger/placement guidance is.

[ashetland]

I agree this make a lot of sense. Since anything can be a trigger, the dropdown should be positionable to where it best fits the use case. Top / bottom / left / right + start / end would all be acceptable depending on the layout.

[driskull]

Yeah I think if we allow it on dropdown because its not a form element then that's fine. We should run it by the a11y team though just to make sure. We can ask them if a role of "menu" is allowed to open on the sides.

[jcfranco]

@geospatialem Can you help us get an answer for the above? I would assume that as long as the proper roles, ARIA attributes are used, and keyboard usage is maintained, the position of the menu won't be relevant, but I could be wrong.

• https://www.w3.org/WAI/GL/wiki/Using_ARIA_menus
• https://www.w3.org/WAI/ARIA/apg/patterns/menu/
• https://www.w3.org/WAI/ARIA/apg/example-index/menubar/menubar-navigation
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menu_role
• https://www.digitala11y.com/menu-role/

[geospatialem]

Somehow missed the notification on this, apologies for the late reply.

Can you help us get an answer for the above? I would assume that as long as the proper roles, ARIA attributes are used, and keyboard usage is maintained, the position of the menu won't be relevant, but I could be wrong.

@jcfranco Yes, that is accurate. The placement of the component wouldn't impact assistive technologies or audiences, as long as the proper roles and the user experience is the expected pattern.

[macandcheese]

Since this already works (https://codepen.io/mac_and_cheese/pen/GRYVRBX?editors=1000), to get it documented I think we just need to use the type that has all the available options, not the limited set here: https://github.com/Esri/calcite-components/blob/4150b57358bcc180e298c9eaff48fbd2fea1c4a7/src/utils/floating-ui.ts#L170

[jcfranco]

@macandcheese @driskull WDYT about typing placement props with a suggested and fallback types? Something like the following:

@Prop({ reflect: true }) placement: MenuPlacement | LogicalPlacement = defaultMenuPlacement;

We could get fancy with naming or excluded types if it makes things clearer in the doc and code too.

[driskull]

If we're not going to restrict "menus" to MenuPlacement then we can just get rid of that type and allow anything.

[jcfranco]

My suggestion was more about the doc/types emphasizing the suggested options from the rest.