-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Refactor Nav Block Overlay CSS #56037
Conversation
Size Change: -864 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
// Inherit as much as we can regarding colors, fonts, sizes, | ||
// but otherwise provide a baseline. | ||
// In a future version, we can explore more customizability. | ||
.wp-block-navigation__responsive-container.is-menu-open { |
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.
Why don't we move this to the other file too?
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.
Because I believe all the styles and sub selectors within this are not nav-block agnostic. They are specifically related to styling the Navigation block.
I want the other file to be just "overlay" stuff specifically.
Is there a better option? Do you think I should move it and if so why?
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.
If we want to make an agnostic component, Dave's idea is correct, but we do want to separate things that are specific to the navigation if they pertain to the wider viewport or to the collapsed version of it. Where that should live is another matter.
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 about this some more. This type of overlay may well be specific to the Navigation block. I still think it's helpful to extract the overlay styles from other behaviour that handles sub blocks and things.
This code is unlikely to end up being a standalone <Overlay>
component because it's heavily tied to a specific responsive behaviour which shows and hides specific pieces of the overlay depending on an arbitrary breakpoint. That is unlikely to be portable to other scenarios.
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 think you might be right. We can refactor again if we feel like we need to, and it will already be way cleaner than it was anyway
Let's keep an eye on the e2e tests, they might be relevant to the changes |
|
||
// ******************************************************** | ||
// TOGGLE BUTTONS | ||
// Alias: |
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 like the agnostic classes. We could use @extend to keep backwards compatibility with the old classes
@include nav-breakpoint { | ||
&:not(.hidden-by-default):not(.is-overlay-open) { | ||
display: block; | ||
width: 100%; | ||
position: relative; | ||
z-index: auto; | ||
background-color: inherit; | ||
} | ||
} |
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 assume this code exists so that if the overlay is open and the screen size changes then the overlay becomes hidden?
I'm wondering. If in the future we want to allow the Nav breakpoint to change dynamically based on measuring the width of the Navigation block, then we might like to look at moving all the responsive behaviour to JavaScript with something like matchMedia
similar to what I did in #45274.
The only issue is then we'd need to find a way to do a similar thing with directives on the front of the site.
I believe taking such an approach would make this code a lot simpler.
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.
yes, I was thinking on using a class that will be added or removed once we reach the correct viewport width
Do you feel like we should keep working gon this? I can make time to have a look at the tests and check if we are breaking something with the changes |
Probably not a priority. I'll close it out. |
What?
WIP
Why?
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast