-
Notifications
You must be signed in to change notification settings - Fork 841
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[EuiSideNav] Fixes and enhancements for the Elastic Solution Nav #4827
Conversation
…in open status within
And more aria props to mobile button
Preview documentation changes for this PR: https://eui.elastic.co/pr_4827/ |
Preview documentation changes for this PR: https://eui.elastic.co/pr_4827/ |
Just some early feedback: Code review looks good Want to check out the docs preview before approving |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of small nits, but otherwise this looks good.
[Future] I agree with removing the arrow for interactive parent items, but I wonder if we should have the ability to expand parents without triggering their action/navigation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few small things but otherwise looks good!
src/components/side_nav/side_nav.tsx
Outdated
iconSide="right" | ||
aria-controls={sideNavContentId} | ||
aria-expanded={isOpenOnMobile} | ||
aria-haspopup="true"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aria-haspopup="true"> |
aria-haspopup
has 5 values plus a boolean: menu
, grid
, dialog
, listbox
, and tree
. true
is the same as menu
. false
is the same as not including it but can indicate that a popup might exist in other situations.
Any of those 5 values then expect that role to be the thing that opens up in some sort of dialog. So a simple open/close pattern doesn't require it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🆒 Thanks for the info. I totally just copy/pasted from a popover menu. 😺
src/components/side_nav/side_nav.tsx
Outdated
aria-expanded={isOpenOnMobile} | ||
aria-haspopup="true"> | ||
{/* Inline h2 ensures truncation */} | ||
{mobileTitle || <h2 className="eui-displayInline">{heading}</h2>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any semantic content inside of a button gets collapsed into a plain string so we need to move this h2
out from inside. A button
inside of an h2
is fine though 👍
(You can see for yourself by opening up this button/heading demo in Safari and opening up VoiceOver. Opening up the rotor (ctrl+opt+u) and arrowing left/right until you find the headings list.)
src/components/side_nav/side_nav.tsx
Outdated
aria-expanded={isOpenOnMobile} | ||
aria-haspopup="true"> | ||
{/* Inline h2 ensures truncation */} | ||
{mobileTitle || <h2 className="eui-displayInline">{heading}</h2>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
{mobileTitle || <h2 className="eui-displayInline">{heading}</h2>} | |
{mobileTitle || <h2 id={uniqueId} className="eui-displayInline">{heading}</h2>} |
Doing this with the mobileTitle
is tricky but we can at least do it with the h2
that we control: setting up a uniqueId
and adding an aria-labelledby={uniqueId}
to the wrapping nav
element will ensure that the nav
is always properly named regardless of browser/assistive tech.
Preview documentation changes for this PR: https://eui.elastic.co/pr_4827/ |
This also meant moving the responsive behavior to JS with Show/HideFor components with the ability to adjust via `mobileBreakpoints` and further heading adjustments with `headingElement`
# Conflicts: # CHANGELOG.md
sass-lint update: Excluding specific mixins from being forced to the top
UpdateIn order to support the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good! One kind of meta question on props though...
We have a few heading related props: heading
, headingElement
, hideHeading
, and headingProps
.
I can understand why/how each exists and developed but I wonder if we should include hideHeading
and headingElement
inside of headingProps
?
On one hand, headingProps
is right now only a subset of the existing EuiTitleProps
but, on the other hand, it thematically makes some sense to include these new heading props under and object called headingProps
.
I'm not sure where the balance of a clean API for this component vs a consistent API across components comes down for this one...
Preview documentation changes for this PR: https://eui.elastic.co/pr_4827/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🎉
Tested in Chrome, Safari, Edge, and Firefox.
The only thing that I noticed is that the new callouts are smaller than the one on the bottom of the page:
New one (I thought I had the zoom out):
And in other pages like https://eui.elastic.co/pr_4663/#/navigation/collapsible-nav we're using the default size. So should we decide what is the size to be used across all pages?
Thanks @miukimiu , I agree we need better consistency. I'll adjust the new one I created to be the medium size and we should probably continue to use that when directly in the docs pages and maybe restrict small to uses within components. |
@myasonik That's a good idea, since these are new props I'll adjust now and hope they're discoverable enough. I'll probably need to add more explanation in the docs to help with that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docs & code changes LGTM! 🦑
Unfortunately the latest change borked the display when the component re-renders because of search. You can the issue if you search for a page in the docs. |
Duplicates a lot of rendered CSS, but can be fixed later with CSS-in-JS
# Conflicts: # CHANGELOG.md
Preview documentation changes for this PR: https://eui.elastic.co/pr_4827/ |
Preview documentation changes for this PR: https://eui.elastic.co/pr_4827/ |
The following screenshots are progressive. Meaning they were taken as the updates were completed so they don't all encompass the final result.
1. Fixes
A. Fixed [EuiPageBody] shadow overlapping emphasized side nav
By adding a
z-index: 1
to the page body. I'll have to monitor any downstream effects of this.B. Better color/transparency for emphasized and proper contrast
Updated background color to be transparent for use in the emphasis mixin (see below) and updated all the calculations including disabled text. There's not much of a visual change.
C. Reduced display of arrow icon to only if the item is not linked but has children
And the component maintains the open status within itself. This drastically reduces noise when all or most of the items have children. It is also the functionality that will help solution teams like Observability create items that aren't actually navigable themselves but have children that are.
D. Fixed up mobile button styles to be more prominent
The button which may be the primary navigation's trigger was rendering quite small. Now it will stretch as tall as its content and the font size is larger.
2. Amsterdam style
A. Reduced the spacing and sizing of root element for Amsterdam only
3. Additions
A. Added
heading
andhideHeading
props for better a11yAnd more aria props to mobile button. Talking with @myasonik, the best approach for labelling sections is to have a nested heading element. Since it's also a pretty safe bet that the rendered
<nav>
will be at the top level, the<h2>
heading level is hard-coded.This
h2
is also then used as the mobile title if a specific one is not supplied, making it easier to create good mobile button labels.B. Added a "hidden" Sass mixin for re-creating the branded nav embellishment.
It's called
euiSideNavEmbellish()
and looks like this:4. Other changes
A. Added
mobile
glyph to EuiIcon.The final before/after.
I think the removal of the repetitious arrows is a big improvement on scannability overall.
Checklist
and playground toggles[ ] Checked for breaking changes and labeled appropriately