feat(Overlay): slide away from anchor based on position #1322
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/primer/primer-components/6tF9Rmx2gZnDZ9VzRhUvqK6EtVa7 |
dgreif
force-pushed
the
overlay-transition-from-anchor
branch
from
210b535 to
8374dd5
Compare
|
From @dgreif in #1322 (comment):
To clarify: This PR prevents the page from flashing scrollbars (as demonstrated in #1231). The scrollbar flash added via #1276 to |
smockle
reviewed
Jun 25, 2021
smockle
reviewed
Jun 25, 2021
smockle
reviewed
Jun 25, 2021
smockle
reviewed
Jun 25, 2021
dgreif
force-pushed
the
overlay-transition-from-anchor
branch
from
2b7953c to
db69e07
Compare
- https://dequeuniversity.com/rules/axe/4.1/aria-dialog-name - https://dequeuniversity.com/rules/axe/4.2/presentation-role-conflict - https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-links.html First, 'Overlay's aren’t 'listbox'es, because (when used in 'DropdownMenu' or 'ActionMenu') they contain 'menuitem's, 'menuitemradio's, or 'menuitemcheckbox'es. Second, 'Overlay's aren’t 'dialog's, because (as demonstrated in the WAI ARIA practices page linked above), 'menu's need not be contained in a 'dialog', and also (as noted in the 'aria-dialog-name' link above), 'dialog's must have an 'aria-label', 'aria-labelledby', or 'title', but neither 'DropdownMenu' nor 'ActionMenu' have any kind of header element that could be used for this. Third, if 'Overlay's are 'none', they can’t be focusable (as noted in the 'presentation-role-conflict' link above), but one of our hooks (maybe 'FocusTrap', maybe 'FocusZone') was setting 'tabIndex' to '0' (in the test component), because it did not contain a focusable child. This PR adds a focusable button child so the 'none' 'Overlay' container won’t receive 'tabIndex' '0'.
smockle
approved these changes
Jun 29, 2021
colebemis
pushed a commit
that referenced
this pull request
Jul 19, 2021
* feat(Overlay): slide away from anchor based on position * fix: handle position changes when re-opening AnchoredOverlay * refactor: use js animation for slide to fix safari * fix: Tests were failing with Axe violations - https://dequeuniversity.com/rules/axe/4.1/aria-dialog-name - https://dequeuniversity.com/rules/axe/4.2/presentation-role-conflict - https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-links.html First, 'Overlay's aren’t 'listbox'es, because (when used in 'DropdownMenu' or 'ActionMenu') they contain 'menuitem's, 'menuitemradio's, or 'menuitemcheckbox'es. Second, 'Overlay's aren’t 'dialog's, because (as demonstrated in the WAI ARIA practices page linked above), 'menu's need not be contained in a 'dialog', and also (as noted in the 'aria-dialog-name' link above), 'dialog's must have an 'aria-label', 'aria-labelledby', or 'title', but neither 'DropdownMenu' nor 'ActionMenu' have any kind of header element that could be used for this. Third, if 'Overlay's are 'none', they can’t be focusable (as noted in the 'presentation-role-conflict' link above), but one of our hooks (maybe 'FocusTrap', maybe 'FocusZone') was setting 'tabIndex' to '0' (in the test component), because it did not contain a focusable child. This PR adds a focusable button child so the 'none' 'Overlay' container won’t receive 'tabIndex' '0'. * fix: Resolve lint errors Co-authored-by: Clay Miller <clay@smockle.com>
colebemis
added a commit
that referenced
this pull request
Jul 19, 2021
* add utility props to Box * update box docs * export box props * update snapshots * Create green-worms-nail.md * AvatarStack story in storybook * Update .changeset/green-worms-nail.md Co-authored-by: Cole Bemis <colebemis@github.com> * Update docs/content/Box.md Co-authored-by: Cole Bemis <colebemis@github.com> * Remove duplicate border system prop definitions * Remove duplicate grid system props definitions * Update FlexProps definition * Remove duplicate position system prop definitions * Update Box documentation * Update BoxProps * Update Box docs * Update Box props * fix: Type 'DropdownButton' as 'button' (#1318) * fix: Type 'DropdownButton' as 'button' * chore: Update snapshots * chore: Set test directory via config rather than flag (#1319) * feat(useFocusZone): update active-descendant on mousemove (#1308) * fix: Split `<Item>` labels (#1320) * fix: Separate 'Item' content into 'label' and 'description' * fix: Only add 'aria-describedby' when 'description' exists * fix: Memoize 'id' so 'Item's and labels match * fix: Don’t rely on 'id' which is possibly not globally-unique * fix: Restore semi-full-width 'Item' dividers, without giving up the semantic nesting. By “semantic nesting”, I mean that the 'Item' label and description are now siblings, which is preferable to the previous implementation, where the description node was a child of the label node. As a general principle, we should align DOM hierarchies with information hierarchies. An analogy: If I were using a bulleted list to describe a dog, I would not indent its breed as a second-level bullet beneath the bullet for its name, because a dog’s breed is not dependent/derived data from its name. Similarly, description is not dependent/derived from label, and so should not be nested in DOM. * fix: Reduce styled-components class permutations. https://www.joshwcomeau.com/css/styled-components/ * feat(Overlay): slide away from anchor based on position (#1322) * feat(Overlay): slide away from anchor based on position * fix: handle position changes when re-opening AnchoredOverlay * refactor: use js animation for slide to fix safari * fix: Tests were failing with Axe violations - https://dequeuniversity.com/rules/axe/4.1/aria-dialog-name - https://dequeuniversity.com/rules/axe/4.2/presentation-role-conflict - https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-links.html First, 'Overlay's aren’t 'listbox'es, because (when used in 'DropdownMenu' or 'ActionMenu') they contain 'menuitem's, 'menuitemradio's, or 'menuitemcheckbox'es. Second, 'Overlay's aren’t 'dialog's, because (as demonstrated in the WAI ARIA practices page linked above), 'menu's need not be contained in a 'dialog', and also (as noted in the 'aria-dialog-name' link above), 'dialog's must have an 'aria-label', 'aria-labelledby', or 'title', but neither 'DropdownMenu' nor 'ActionMenu' have any kind of header element that could be used for this. Third, if 'Overlay's are 'none', they can’t be focusable (as noted in the 'presentation-role-conflict' link above), but one of our hooks (maybe 'FocusTrap', maybe 'FocusZone') was setting 'tabIndex' to '0' (in the test component), because it did not contain a focusable child. This PR adds a focusable button child so the 'none' 'Overlay' container won’t receive 'tabIndex' '0'. * fix: Resolve lint errors Co-authored-by: Clay Miller <clay@smockle.com> * Generate prop documentation (#1323) * Add new filesystem source * Add component metadata type * Create Props component * Update props table * Handle empty and error states * Add required label * Update required prop styles * Clean up code comments * Remove filesystem plugin * Remove extra markdown file * Add component comment Co-authored-by: Clay Miller <clay@smockle.com> * Improve treeshaking by setting package.json sideEffects (#1332) * fix: mark sideEffects free * fix: update sideEffects delcaration in package.json to improve treeshaking * fix: update sideEffects delcaration in package.json to improve treeshaking * fix: BaseStyles doesnt use sideeffects * chore: add changeset * Update Box documentation * Update BoxProps * Update Box docs * Update Box props * Remove AvatarStack story * Update .changeset/green-worms-nail.md Co-authored-by: Cole Bemis <colebemis@github.com> Co-authored-by: Clay Miller <clay@smockle.com> Co-authored-by: Dusty Greif <dgreif@users.noreply.github.com> Co-authored-by: Matthew Costabile <mattcosta7@github.com>
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The main goal here is to prevent scrollbars from showing briefly when an
AnchoredOverlayis opened. This can happen if theOverlayportion ends up slightly outside the currently visible area upon creation, or because of the slide animation. There are two main changes to correct this behavioranchorSidefromuseAnchoredPositionall the way intoOverlay. With this information, we can infer which direction theOverlayshould "slide" when it is opened. We always want to to start slightly overlapping the anchor and then move into position. Previous behavior had it always sliding "up", which is only desired if theOverlayis positioned above its anchor. If not passed ananchorSide, there will now be no slide animation.visibilitysetting fromOverlay. This was a bandaid to handle scenarios where theOverlaycontents would briefly flash before moving into the correct position. While settingvisibilityremoved the main visible flash, it did not prevent scrollbars from flashing if the unpositioned content happened to overflow the current frame. The more correct solution here is to replace a fewuseEffectwithuseLayoutEffect, which allowsAnchoredOverlayto create theOverlay, calculate position, and re-position theOverlaybefore the browser paints.Closes #1231
Screenshots
Merge checklist