FSE Outreach Round #12: Building a Site Header With Blocks

On Wednesday, Anne McCarthy announced Round #12 of the FSE Outreach Program. As always, everyone is free to join by testing features and providing direct feedback on problem areas with the design tools in WordPress. Anyone interested should respond by March 16.

For this round, volunteers are tasked with testing some oldies but goodies. Early in the program’s history, anyone who joined did a lot of site header and navigation work. Round #12 asks that users revisit some of these essential tools.

This was an exciting call for testing for me. In early 2021, I had my fair share of frustrations with the FSE experience. There were so many designs I wanted to tackle, but I far too often fell short of creating what I wanted.

Therefore, I hopped back in time and revisited a header design from Round #4 of testing in March 2021. At the time, the WordPress leads were weeks away from deciding whether some FSE-related components would land in WordPress. My conclusion of the tools at the time was:

I came to the realization that attempting to do anything remotely advanced with the site editor was simply not going to happen…As someone who prides himself on near-infinite patience, Round #4 sought to crack me.

I had wanted to recreate elements from the UK-based Pho Cafe page header during testing. It was a tall order that could not be filled.

Screenshot of the Pho Cafe website page header.
Pho Cafe header.

However, almost a year later now, how much has changed? Is it possible to create an exact replica of the site’s header from the block editor?

Yes and no. As usual, it depends.

As a developer and designer, I am confident that I could do it with custom code. Considering this would likely be a one-off design for a paying client, I would be comfortable with that.

Creating this as a part of a publicly-released, general-purpose theme would have a ton of roadblocks with that level of customization. However, it would be possible to capture much of the character, the essence, of the design.

As for building it directly from the block editor, there are still some severe limitations. However, that is what I challenged myself to do. I wanted to get a feel for where the site editor was at without writing CSS code.

The following is the result:

Pizza restaurant header with a logo, menu, and buttons at the top right. In the middle is a demo slogan followed by another button-like menu.
Pizza restaurant header.
Pizza photo credit: Jennifer Bourn

Technically, I did write a little code to load the KG Happy font. Outside of that, I just forked a block theme I had on hand and changed the “wide” size. I created everything else 100% from the site editor.

Here is a screenshot of the design from the editor itself:

Pizza restaurant header within the site editor.  The current view of the header template is selected.
Custom header template part in the site editor.

On the whole, this went surprisingly well. In a year, the site editor has become far more powerful.

As I said, it still has its limitations. Anyone who has worked with block themes will likely tell you the issue with the layout in the above screenshot. The problem area is the Columns block used for the Site Logo, Navigation, and Buttons across the top. You might as well hang up any hope of that working well on smaller screen sizes.

Mobile view of a restaurant header. Menu area is out of alignment.
Mobile view of header.

Is it entirely unusable? No, but it is not anywhere near close to ideal.

Without responsive controls on layout-type containers like the Columns block, designing anything complex with the site editor can sometimes feel like one giant hack. At this point, this is not a revelation of any sort.

There are tons of improvements with block design tools in comparison to last year. The core block gap, margin, and padding controls are a godsend for adjusting vertical and horizontal spacing. Back then, even the thought of having any control over this was a headache-inducing affair. Except for a few blocks still missing these options, it is now [mostly] stress-free.

I hit no spacing-related problems in this experiment. That feels gratifying to say after over a year of testing FSE features.

However, I did hit some other roadblocks. The Navigation block may be my least favorite thing about the site editor. I have yet to see how it will offer a universal system that plays well with the 1,000s of design variations that theme authors will want to employ. Classic nav menus are still vastly superior for custom design.

I ran into two primary issues with this experiment. One of the problems I had a year ago with FSE Outreach #4 was creating a menu that had button-like links. This basic design is still impossible with the Navigation block, at least with the core design tools:

Four button-like links with red backgrounds and white text.
Button-like navigation items.

Users can add a background to the entire Navigation block but not to the individual menu items. How did I do it? I used a Buttons block instead.

The more I think about it now, the more I like the Buttons block alternative. However, there is no way to wrap this in a <nav> tag to define it as a navigation element.

One missing piece of the header I was attempting to replicate was a mobile menu at the far right of the layout. WordPress’s mobile Navigation menu icon provides no customization options. Users can customize the overall background and text color but not target the button directly. I faked it a little by narrowing down the column:

WordPress site editor with a mobile-only Navigation block highlighted.  It is aligned to the right of a Buttons block.
Mobile Navigation menu icon next to Buttons.

There was no way to make the mobile icon larger or give it any padding to align its size with the Button blocks next to it.

The Navigation block, despite its progress, is still one of the weakest links in FSE. It only covers a handful of simple use cases out of the box. Anything beyond that requires a deep level of customization and the hope that an end-user does not break the delicate balance struck to make it work.

Twice during testing, my Navigation block disappeared on the front end. I suspect it had something to do with me trying to adjust the outer Column block’s width. However, I was unable to replicate the issue at will.

Testing is all about finding problems to solve. I did not run into any crashes or the types of bugs that I would have seen long ago. The experience of designing from within the site and template editors feels pretty smooth these days. The holdups are more about missing capabilities than anything. Making the leap from an impossible header layout to an almost possible one in 11 months is significant.

5

5 responses to “FSE Outreach Round #12: Building a Site Header With Blocks”

  1. Hi Justin,

    Love reading all of your insights on FSE and all things WordPress. In regard to having your navigation menus disappear in the site header, I have also seen that issue often in the last few weeks.

    It appears that, in my use cases, any adjustment to the site header after having added the navigation menu to the header (like readjusting columns of the header) makes the underlying navigation code disappear. If I go into the nav revisions, it shows that the latest update was to delete the existing nav all together.

    I’m able to go one revision back on the nav menu and restore it, but this is definitely a major bug that needs to be addressed.

    I must say, I was worried about FSE, but other than the navigation issues (and traditional menus being a much easier interface, as you’ve mentioned) I have actually had a positive experience with FSE.

    Thanks again for all of your great insights and recommendations.

    • I feel like my nav issues were slightly different. Everything appeared correctly in the editor but disappeared on the front end. It just felt so weirdly random.

  2. Absolutely love that you threw it back to your previous header design. That was the hope in this test – that folks would revisit what they once tried and feel the differences. It makes me excited thinking about what things will feel like a year from now :) Now to address your various items of feedback as is our ritual!

    The problem area is the Columns block used for the Site Logo, Navigation, and Buttons across the top. You might as well hang up any hope of that working well on smaller screen sizes.

    For anyone following at home, you can follow along with the work being done around responsiveness for these exact problems in the following issue: https://github.com/WordPress/gutenberg/issues/34641 The screenshots in the issue nearly match what you show above.

    I hit no spacing-related problems in this experiment. That feels gratifying to say after over a year of testing FSE features.

    Woohoo! Most recent addition on this front is having margin support added into the Group block: https://github.com/WordPress/gutenberg/pull/37344

    The Navigation block may be my least favorite thing about the site editor. I have yet to see how it will offer a universal system that plays well with the 1,000s of design variations that theme authors will want to employ. Classic nav menus are still vastly superior for custom design.

    While not everything will be solved ahead of 6.0, I did want to note this tracking issue for the navigation block items currently: https://github.com/WordPress/gutenberg/issues/38275 In particular, I like seeing what the priority items are vs what will need more time to mature (to better set my own expectations). I agree that the navigation block has a ways to go to catch up to the many, many designs we’ve grown used to.

    Users can add a background to the entire Navigation block but not to the individual menu items. How did I do it? I used a Buttons block instead.

    I added this excellent feedback to an issue around adding separator options to the navigation block: https://github.com/WordPress/gutenberg/issues/23293#issuecomment-1055680205 I also want to note the desire to have the buttons block in navigation block as yet another way to accomplish some designs we’re used to: https://github.com/WordPress/gutenberg/issues/35924 I imagine you could “hack” it with the row block but that means it wouldn’t show up in the responsive menu among a host of other issues.

    WordPress’s mobile Navigation menu icon provides no customization options. Users can customize the overall background and text color but not target the button directly. I faked it a little by narrowing down the column.

    Noted in this issue around both having options to style the responsive icon and to use your own/have a few options: https://github.com/WordPress/gutenberg/issues/37930 This is one I’m particular interested to see since I use FSE on my personal site and find the current icon doesn’t feel distinguished enough (want to mess with it heh).

    Twice during testing, my Navigation block disappeared on the front end. I suspect it had something to do with me trying to adjust the outer Column block’s width. However, I was unable to replicate the issue at will.

    I haven’t noticed or heard anything like this but will now keep watch for more/similar reports. I appreciate you noting things like this even when you can’t fully replicate. There have been quite a few times now where hearing about items like this have led to discovering very real issues so know it helps!

    The experience of designing from within the site and template editors feels pretty smooth these days. The holdups are more about missing capabilities than anything.

    Hear, hear. Now that the building blocks (pun intended) are in place, I find myself regularly ready for more options along with wanting more intuitive flows. Things have come a long way and still have a long way to go.

    • Thanks for the detailed response, Anne. Now, I have even more tickets to subscribe to. :)

      In particular, I like seeing what the priority items are vs what will need more time to mature (to better set my own expectations). I agree that the navigation block has a ways to go to catch up to the many, many designs we’ve grown used to.

      If I’m being honest, I’ve been reluctant to try and push the nav block from a dev/design perspective. I am pretty simple to please. I just want a basic slide-down mobile menu like I have on my personal blog:

      JustinTadlock.com slide-down nav menu.

      That takes 11 lines of JS code and just a small amount of CSS. The HTML structure is also very different.

      One of the things that is problematic — and this is coming from other theme devs, too — is that nav menus changed from just being data that we could manipulate to a very specific HTML structure with its own CSS and JS tied to it. And, this can also literally be stuck anywhere on the page (wondering if some template/block locking will help here…). That makes it extremely complex to get the design right in some cases.

      Also, I’m just not a big fan of the default overlay mobile design. WordPress had to pick one of my least favorite implementations. :)

      I’m going to try and take a crack at creating a custom nav menu design soon. It’s something I need to explore more. I think it’ll help me explain things better, too.

      • Managed to miss this reply somehow. So sorry for the delay. I found it while jamming away on the summary post today.

        One of the things that is problematic — and this is coming from other theme devs, too — is that nav menus changed from just being data that we could manipulate to a very specific HTML structure with its own CSS and JS tied to it.

        This has definitely come up a ton with the nav block implementation. I do think, in time, expanded options with theme.json will help fill these gaps but we have a ways to go there:
        https://github.com/WordPress/gutenberg/issues/39052
        https://github.com/WordPress/gutenberg/issues/34514
        As you mention, it’s also a mental switch to manipulate menus in this way!

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: