fix: consistent popover padding for filtered collections #1816
Conversation
🦋 Changeset detectedLatest commit: 20941cf The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
|
Size Change: +38 B (+0.01%) Total Size: 533 kB
ℹ️ View Unchanged
|
| &:has(input[type='search']):is( | ||
| [data-trigger='Select'], | ||
| [data-trigger='MenuTrigger'], | ||
| [data-trigger='SubmenuTrigger'] | ||
| ) { | ||
| padding: var(--lp-spacing-200); |
There was a problem hiding this comment.
These things all use the menu styles, which have implicit padding around their items/sections.
But the popover itself does not. Now, when these things are filterable (via <Autocomplete/>), we want also push the search field inward slightly. (And items align will align with the search field's icon or start-of-text.)
| &[data-trigger='DatePicker'], | ||
| &[data-trigger='DateRangePicker'] { |
There was a problem hiding this comment.
These missing bits meant the buttons sat flush against the popover's edges
|
|
||
| &:is([data-trigger='DatePicker'], [data-trigger='DateRangePicker']) { | ||
| padding: var(--lp-spacing-300); | ||
| &[data-trigger='SubmenuTrigger']:has(div[role='application']) { |
There was a problem hiding this comment.
This one ensures a date(range)-picker in a submenu also has breathing room, consistent with the rest.
Calendars/date pickers / etc… don't have a direct WAI-ARIA role, and RAC uses role='application' for them. Based on what I read about that role, this felt reasonable: a widget with the "application" role is meant to be its own little UI, which makes me think that's a reasonable signal/differentiator in this context.
Summary
Screenshots (if appropriate):
Testing approaches