class is no longer added to Navigation Block when choosing orientation

[nick-novak]

What problem does this address?

I am really disappointed in the new layout for the Navigation block. I see how the new navigation block utilizes the layout functionality, but it was nice to have a class I was able to target for CSS styling. Specifically when you select a navigation to be vertical it used to add a .is-vertical class to the navigation. This was great for themes where there were unique styles for the vertical and the horizontal navigation.

What is your proposed solution?

Place the functionality back into the block that attaches the class back to the navigation when you select a vertical orientation layout.

[paulwilde]

Agreed. I found this to be an issue too. This is a step backwards for sure.

For vertical navigations I would style nav items to have a smaller gap (about .5rem), whilst now with the horizontal version I'm stuck with each navigation item having a gap around the same size as a space so it's no longer viable.

This change has ruled out me using the full-site editor in the future.

[talldan]

cc @tellthemachines @jasmussen. This seems like good feedback, I know there were recent changes to the way layout works, it this still a problem?

[tellthemachines]

Thanks for bringing this up!

Layout doesn't output these classes because we no longer need them to hook the styles to; the CSS is added dynamically. This is meant to save themes from having to create styles for all those classnames, but as always there are unintended consequences 😅

I'm thinking this is something that could change, but it would be good to have some more concrete use cases for the classes. What problems are we absolutely not able to solve without them? What could instead be a configuration under global styles?

For vertical navigations I would style nav items to have a smaller gap

This is still possible by setting row-gap in the theme styles; it will override the gap only for vertically aligned elements. On the other hand, the global styles interface might benefit from a gap control that allows custom values to be input for row and column.

What I'm trying to understand is what kind of styles themes might want to customise their navigation blocks with, and if there might be any opportunities for improving global styles based on your feedback.

[paulwilde]

This is still possible by setting row-gap in the theme styles; it will override the gap only for vertically aligned elements. On the other hand, the global styles interface might benefit from a gap control that allows custom values to be input for row and column.

What I'm trying to understand is what kind of styles themes might want to customise their navigation blocks with, and if there might be any opportunities for improving global styles based on your feedback.

One issue that the blockGap setting has is that you cannot tweak it for different breakpoints. This is a big problem with Gutenberg in general as it has no proper grid system or breakpoint specific settings, whereas with a CSS class you have full control in how that navigation will look based on the area of the page it's actually located or the current breakpoint you are viewing it at. A horizontal navigation in the header can be styled different than if it were in the footer.

Also unless I'm mistaken I see no option to set a blockGap based on which orientation the navigation actually is, or the context of the navigation (editor area vs widget area). I'm not a fan of giving the client control of manually tweaking such a setting as it will likely break things on different breakpoints.

[kmarcy724]

Whether or not Gutenberg requires a conditional class that exposes the orientation to the front end; Gutenberg USERS need it.
I need to be able to determine the front end layout and tweak custom CSS accordingly, and I'm going to have to add a block style to shim the conditional class for orientation into the front end now.

Seeing this CRITICAL entry-point to writing custom CSS for blocks completely overlooked because it's not "needed" to style the base-level of CSS shipping with Gutenberg is a RED FLAG.

Contributors; you need to view classes like this like the body_classes() hook. WE NEED THESE CLASSES TO DEVELOP OUR THEMES.

[chthonic-ds]

What I'm trying to understand is what kind of styles themes might want to customise their navigation blocks with, and if there might be any opportunities for improving global styles based on your feedback.

I'm currently trying to apply the following when navigation is set to vertical:

• rotate the sub-menu icon in a different direction
• add a left border with a thick stroke and extra left padding per sub-menu element
• different interaction fx on the left border

At the moment I need to filter for the orientation attribute value and apply it to the rendered markup, but without something like the menu_class in wp_nav_menu() this is a pretty hacky process. An orientation class included by default alongside wp-block-navigation__container would make this easy to target.

On a side note, a navigation block set to vertical orientation remains horizontal in WP 5.9beta1 without Gutenberg running. All of the generated --layout-* properties are undefined and the initial fallback is used. Addressed by #37009.