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
feat(nav): add overflow styling to horizontal nav examples #1615
Conversation
Deploy preview for pf-next ready! Built with commit 65ff9f3 |
Does this component's scroll buttons need the current styles, like used in tabs? |
@mcoker I don't think so as its just meant to be an addition to overflow scrolling but I can check |
Since the UI and basic interaction is the same, seems like they should match in that regard. Also, since this pattern is effectively the same between the components, I'm curious if this should be it's own component that nav and tabs use. And maybe it has a modifier to create both the UI used for the primary and secondary tabs examples. |
In terms of a new component would you be talking about the overflow button as a component or the entire horizontal list overflow. I don't know how I feel about that because one is a nav and one is a secondary tab list, and the lists have really different styles. and then we have the horizontal nav version for the masthead that seems like it should be an example of the nav component rather than using a component. I could also see the styles for secondary tabs maybe changing too @mcoker |
Looks like it would be an overflow-scroll component that you put a list inside of, and it could apply to tabs, secondary tabs, horizontal navigation, or if you had another list somewhere you wanted to treat similarly. Just in general, it's the same structure, and if I came across this pattern in the nav and tabs, I would expect it to behave the same or at least very similarly. The visual differences could be handled in the choice of icon or modifiers applied. It just looks like there is a lot of copy and paste between the two currently. What I would want to avoid is having 2 unique implementations because there are slight design changes between them. And question the design differences anyways, and ask if, since they're very similar patterns, they should present themselves more similarly, too. I don't think we need to worry about it for this PR, but something to think about in the future. |
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.
oops, approved the wrong PR, please disregard :)
padding-right: var(--pf-c-nav__scroll-button--PaddingRight); | ||
padding-left: var(--pf-c-nav__scroll-button--PaddingLeft); | ||
background-color: var(--pf-c-nav__scroll-button--BackgroundColor); | ||
border: initial; |
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.
Is there a reason you use initial
over 0
?
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.
This was used in the tab example so I thought it was purposeful. I can make a note to update both.
@mcoker the reason I moved |
|
@mcoker updated this, visuals have approved of the box shadows.
I also added some styles to the page to show how the nav would work.. Ill remove those, but definitely check out the nav on the page component. |
@mcoker I successfully added the horizontal nav to the masthead in the page demo & updated the box shadow color as per @mceledonia recommendation |
@@ -24,6 +24,27 @@ The navigation system relies on several different sub-components: | |||
|
|||
| Class | Applied To | Outcome | | |||
| -- | -- | -- | | |||
<<<<<<< HEAD |
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.
Looks like you have some merge remnants left in here...
|
||
// Hide scrollbars | ||
&::-webkit-scrollbar { | ||
&.pf-m-dark { |
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.
I wonder if instead of pf-m-dark
, you should just style the button box-shadow
in the horizontal nav? And can the color and background colors not inherit from @include pf-t-dark;
in .pf-c-nav__horizontal-list
?
@@ -204,6 +215,10 @@ | |||
overflow: hidden; | |||
background-color: var(--pf-c-page__header-nav--BackgroundColor); | |||
|
|||
> * { |
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.
is there a reason you're using *
instead of .pf-c-nav
?
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.
I was thinking for flexibility but I don't think that's necessary here so good point!
@@ -1,3 +1,38 @@ | |||
{{#> page-main-nav page-main-section--modifier="pf-m-light"}} |
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.
Are you sure you want to add tertiary nav to every demo? Also the expandable nav already had tertiary nav, so now you have 2 in that demo - https://deploy-preview-1615--pf-next.netlify.com/demos/Page/examples-full/?component=Page%20Component%20Expandable%20Nav%20Example
// Base styling | ||
overflow-x: auto; |
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.
Sorry if I asked you this already, but why move this from nav to the horizontal nav components? Curious if this is necessary?
@christiemolloy this looks great! Just one question about moving the Also, I see you are not using pf-m/t-dark, or including
|
Ah, I see what you're saying about needing a dark class on the nav if the buttons are outside of the list. In this case, we style another nav element based on the page element it's applied in, and I think that's fine here, too. The buttons have to be outside of the list though, otherwise you get a11y errors. Plus if we make this a component in the future, the buttons will need to be outside of the list (and probably the entire nav element). In this PR - christiemolloy/patternfly-next#13 I refactored that and fixed a couple of a11y issues, as well as used |
refactor(nav): refactor header-nav scroll buttons, a11y issues
@mcoker thanks for making those changes! This is happening in the example because the page__header-nav has 'width: auto` on it rather than width: 100%, but it works in the demo, so not sure if it even matters: |
@christiemolloy I think that's fine. This is one of those cases where the example doesn't look right because it's outside of the context where it is designed to be used. Though looks like you could add |
@mcoker I'm not seeing what you're describing. We're using what's called Horizontal Nav not Tertiary Nav in our Page component. And on the the Nav component page, it does have I did notice that before this PR, the page component has two aria-label attributes though. One of them was changed to "Global" in this PR, so now at least they're both correct, but we only need one. 😉 |
@jgiardino we use tertiary nav on the expandable nav page demo. It's also in all of the data list demos and data table demos |
@@ -1,4 +1,4 @@ | |||
{{#> nav nav--attribute=(concat 'id="' page--id '-primary-nav" aria-label="Grouped Nav Example"')}} | |||
{{#> nav nav--attribute=(concat 'id="' page--id '-primary-nav" aria-label="Global"')}} |
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-label
appears to already be defined on the nav
handlebar. It's showing up twice in the Page and Datalist demos.
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.
Nice find! Looks like we should just remove any reference to aria-label
from all of the nav components in the examples, except for the tertiary nav used in the page expandable demo, data list demo, and data table demos. And in those cases, define aria-label
as an attribute of the hbs partial, not in the nav--attribute
attribute value, since this is the logic that generates aria-label
in nav.hbs
<nav class="pf-c-nav{{#if nav--modifier}} {{nav--modifier}}{{/if}}"
{{#if aria-label}}
aria-label="{{aria-label}}"
{{else}}
aria-label="Global"
{{/if}}
{{#if nav--attribute}}
{{{nav--attribute}}}
{{/if}}>
{{> @partial-block}}
</nav>
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.
Or alternatively, we could remove the aria-label
logic from nav.hbs
, and include it in nav--attribute
instead. That would probably be more consistent with our other partials.
Thanks for the example, @mcoker! That example uses the correct aria-labels. The primary nav is referred to as "global" navigation. Then the tertiary nav region is "local" navigation relative to the "Resource Usage" page that's selected in the global navigation. |
@@ -1,4 +1,4 @@ | |||
{{#> nav nav--attribute=(concat 'id="' page--id '-primary-nav" aria-label="Grouped Nav Example"')}} | |||
{{#> nav nav--attribute=(concat 'id="' page--id '-primary-nav" aria-label="Local"')}} |
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.
{{#> nav nav--attribute=(concat 'id="' page--id '-primary-nav" aria-label="Local"')}} | |
{{#> nav nav--attribute=(concat 'id="' page--id '-primary-nav" aria-label="Global"')}} |
Left one change suggestion. Also. Can you just remove the nav component from this page component example, and replace the component with I also wonder if we should add |
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.
nice!!
🎉 This PR is included in version 2.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
fix #1519
Visuals: