Navigation: Try to keep :where just for paddings#42967
Conversation
|
Size Change: +7 B (0%) Total Size: 1.27 MB
ℹ️ View Unchanged
|
I think this makes perfect sens and among the proposed alternatives this here strikes me as the most sensible. |
scruffian
left a comment
There was a problem hiding this comment.
This looks good to me.
It should also be possible to set the padding directly on the blocks themselves rather than just on the links:
"core/navigation-link": {
"spacing": {
"padding" : {
"top" : "10.5em",
"right": "20em",
"bottom": "10.5em",
"left": "20em"
}
}
}
This doesn't work, but that shouldn't stop this PR.
|
Thank you for the review and green check. To me this one feels pretty safe, so I’d like to land it so we can move forward. In the next week, I’d appreciate eyes being kept on the nav block, just in case I missed anything. Notably the click/hover options for opening should work the same. |
What?
Followup to #42964, alternative to #42965.
:wherefor showing/hiding submenus.:wherefor default paddings, fixing a bug where theme.json padding rules wouldn't affect linksThis alternative keeps the
:whererules in place just for the paddings, so that submenus still have some default padding in their boxes, but can still be overridden bytheme.jsonrules such as these:The net result is that default paddings for menus and submenus remain working for browsers that support
:where, and those paddings an be further customized viatheme.json. With custom rules:Without any custom rules, just the defaults:
Why?
The main challenge in #39230 is for submenus to open and close across every browser, remaining functional for older browsers. An argument can be made that default padding rules fall in the "graceful degradation" category, since they are mostly decorative.
Testing Instructions
Please follow testing instructions from #42964, though note that this PR should be safer (if acceptable) than #42965 since navigation block behavior should be mostly unchanged from what it's been for a while.