-
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
[Experiment] Enable customising the Nav block breakpoint #45274
base: trunk
Are you sure you want to change the base?
Conversation
`(max-width: ${ mobileBreakpoint })` | ||
); | ||
|
||
console.log( { mobileBreakpoint, isMobileBreakPoint } ); |
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.
Need to remove
@mikachan From a Theming perspective would you see this feature as being valuable? Every time I create a theme I"m frustrated by not being able to properly control the Navigation block breakpoint. I assume you've run into this also? |
Size Change: +155 B (0%) Total Size: 1.28 MB
ℹ️ View Unchanged
|
Yes, I think this would be extremely valuable. I love the idea of being able to control the Navigation block breakpoint from the UI. Your video looks promising! Going forward, I wonder if this custom breakpoint should be at a higher level so it can impact more blocks. I really love using intrinsic design but there are some cases (like the Navigation block) where the best solution is probably to use a breakpoint, so it would be great to enable this for more blocks. Perhaps the custom breakpoints could eventually replace the |
Yes I agree. I suggest we roll out to the Nav block and then if appetite grows we can consider if/how we extend this outwards to become a system wide tool. I can see other blocks (e.g. Columns) needing something similar to determine when to "stack on mobile" for example. |
I don't think we should be having user set this value. Can we leverage container queries to do it automatically based on space? |
Yeh I did consider taking a look at that. I appreciate we want to go for intrinsic design principles. I may not have fully groked container queries but as I understand it you can query the width of the parent container and then adjust accordingly. However in Navigaiton blocks we care about switching out an entire layout to "mobile" mode based on the number of items in the Navigation itself. As an example:
If there's a way of solving that (without resorting to JavaScript "measuring" the width of the Nav items) which I have missed then I'd be happy to look into it. |
I've had a think about this and left some alternative suggestions under |
Great solution, it's really required! |
Hey :) everyone. Must have. We are already in the future and screens of any size can be an electronic canvas. This is just obvious and should be a standard principle in Gutenberg. |
If you would like to see the PR land then please leave a 👍 emoji on this comment. |
Just came across this and would love to get a solution for this! |
replicated to this issue |
We proposed an alternative to this here: #57587 any feedback is welcome |
🚧 Work in Progress 🚧
What?
Adds the ability to customise when (the breakpoint at which) the Navigation block is in "mobile" mode.
Closes #45040
Related to #42305
Why?
Currently the breakpoint for
Mobile
is hardcoded at around 782px. This is extremely inflexible and given that each Navigation may have a varying number of items can cause menus to overlap and wrap on smaller viewports before the mobile breakpoint kicks in.By allowing users to customise the breakpoint on a per Nav block basis the user is afforded greater control over the display of the their content.
How?
Makes use of
useMediaQuery
hook (which usesmatchMedia
under the hood) to add/remove a class to the DOM. This is then used to conditionalise the application of specific styles that apply when in "mobile" layout mode.This replaces the use of hardcoded media queries within the block's CSS.
I did consider using CSS custom properties but then I remembered you can't use them in media queries rulesets.
Alternatives
As Gutenberg as a project wants to aim more towards intrisic design principles we should consider also:
Todo
matchMedia
on the front of the site alongside thechange
event handler to add/remove the css class from the DOM.Testing Instructions
Screenshots or screencast
Screen.Capture.on.2022-10-25.at.11-50-58.mp4