Closed draganescu closed 3 years ago
Make the navigation block do some work behind the scenes and transform its inner link blocks depending on the situation. The wrapper of the navigation block is a NAV element. the user should be able to add a Link block which would be rendering an A element. This link block allows the user to add a "submenu" from he block toolbar like it does today. That is when we transform the Link into a Links List and move to an UL > LI markup just for that tree. This way the movers work and the markup is the same in the editor and the front end and we use the most accessible and semantic option we have.
I personally quite like this approach.
For the situation where the user will add a few adjacent links we'll end up with a nav and some anchor children, a good pattern for navbars. If the user creates nesting we'll end up with a nav and some ul children plus other elements from the other blocks.
What is the difference between using a navigation block or to build a complex menu (complex meaning a menu that contains more than links) compared to building it with group, columns and a navigation block that only supports nested lists of links?
Using patterns removes some options such as:
Regarding the power of the navigation block, I believe it might be helpful to take a step back and reevaluate what we are trying to achieve with a single block. Do we want a single block to handle all those use cases and the complexity you mentioned above?
What is the difference between using a navigation block or to build a complex menu (complex meaning a menu that contains more than links) compared to building it with group, columns and a navigation block that only supports nested lists of links?
Given that Gutenberg already supports semantic template parts, I think we could try exploring a semantic Navigation template part approach, similar to how Header and Footer work, as groups can be converted into reusable blocks but lack semantic meaning. This would reduce the complexity of the Navigation block to a list of links, and would allow building more complex navigation layouts with a better UX to handle them while keeping them semantically meaningful.
I think there's a few things to clarify because we are going a bit in circles!
Gutenberg encourages separating three dimensions for how content is presented: how it's rendered, how it's edited, how it's saved. Block authors need to make nuanced decisions for each dimension. We should save the most ergonomic and clean representation of what a users has created. In the case of navigation, the list markup is a detail of rendering, not of the data structure. The same way a spacer is an indication of intention but should not force us to render a spacer on the front if we can turn it into margins of the sibling elements.
We don't want to overtly complicate block APIs because we need to allow our block builders to create simple blocks that could be used in navigation structures, with or without lists. (For example, a WooCommerce Cart widget.)
Do we want a single block to handle all those use cases and the complexity you mentioned above?
I don't think this is the right frame of mind because we are already employing various child blocks. The important part is how users would experience it vs how it works. It's already a bit confusing from a user perspective to see so many options without much context on which one is right to use.
So far I believe from a user perspective we need to make it simple to understand — if a user needs to choose among various navigation types in the inserter, we would have offloaded a design problem onto the user because it's easier for us to reason and develop as separate blocks.
We should embrace the flexibility that we can optimize the three contexts (render, editing, saving) for what we need them to accomplish, and to have flexibility in the future to alter markup decisions, improve accessibility, etc.
In view of this discussion, I've updated #30551 as it seems the best way forward for now.
If I understand correctly, we're aiming for a solution where:
Did we rule out https://github.com/WordPress/gutenberg/pull/31827 as a possibility? For me, the main question there was if ULs needed to be used for accessible navigation links.
The approach in https://github.com/WordPress/gutenberg/pull/30551 would be my next preference if we don't mind diverging the editor and published view representation, which as noted in this discussion is an ideal but not a hard rule.
diverging the editor and published view representation
Yes. This whole discussion was started to make sure alternatives to diverging the two representation have been explored as much as possible. I think this is the most important direction that this thread has boosted:
Gutenberg encourages separating three dimensions for how content is presented: how it's rendered, how it's edited, how it's saved. [...] We generally want to have markup in the editor and the front be the same but this is not a requirement nor a design guideline.
In light of the above both #31827 and #30551 should move forward and:
cc @tellthemachines @ellatrix
The change of the blocks editor markup will affect the navigation editor and it will require great consideration for making the creation and editing accessible without relying on the affordances of the markup.
cc @getdave @talldan
In light of the above both #31827 and #30551 should move forward
I'm confused. These approaches are incompatible, so we can only move one of them forward, not both. The first removes the list markup altogether, while the second removes that markup in the editor and adds it only in the front end. Which is it to be?
Taking into account @mtias' insightful comment above, I believe we should move forward with #30551 and handle the frontend representation on render time, clearly differentiating how the block is rendered, how it's edited, and how it's saved.
As @tellthemachines points out, once we head in this direction we won't need to remove the list markup as in #31827 but generate an appropriate, valid markup depending on the inner blocks added: this could perfectly be a <ul>
wrapping links, followed by a <div>
wrapping a search block and a spacer, and another <ul>
wrapping more links, as discussed in #29036.
Yes, I missed that #30551 ALSO removes the editor markup :) So in this case #31827 should be closed in favor of #30551 .
This is a solved overview / discussion so closing.
We have a few competing problems around the navigation block’s markup, structure and use cases and it seems that it’s hard to find a good implementation.
Here is a list of the problems in no special order.
I think all these things together are putting the block in a bad place. Let's try to advance the work by taking some unbinding decisions.
Discussion 1: the block's markup (1, 2)\
The problem with the wrapper element for the navigation block stems from how block html works plus the expectation to be able to insert a link as a top level element. If we default to showing menu items as LI elements then the default wrapper should be an UL, but if this wrapper can contain other blocks we'll end up with invalid markup, for example the wrapping FORM of a search block as a direct child of the UL wrapper element of the navigation block.
To mitigate this a few paths have been proposed so far:
Discussion 2: the power of the navigation block (3, 4, 5)
Here is a list of questions that always come up and have not had a clear answer:
That's about it for a summary of the problems that keep the navigation block, well ... blocked.