Fixed Position Header and Footer Template Parts

[critterverse]

There has been a little talk already about adding background image support for Template Parts. This would likely include an option to set the background image in a fixed position, similar to the option currently available for the Cover block. However, I think it would be useful to extract this option from being specifically tied to background settings, and make it a more general option.

Based on conversation in this thread, here's a mockup:

• Layout panel becomes a ToolsPanel where the position toggle can be a non-default option for Group
• As a starting point, just two options, Default and Sticky

When a group has been set to sticky, the list view is segmented into sticky and scrollable categories:

As needs emerge, we can explore adding additional options, including placement.

---

Issue updated Nov 3.

Initial proposal

There has been a little talk already about adding background image support for Template Parts. This would likely include an option to set the background image in a fixed position, similar to the option currently available for the Cover block. However, I think it would be useful to extract this option from being specifically tied to background settings, and make it a more general option that’s available to Header and Footer Template Parts whether or not they have a background applied.

I can see this option working well in the “Advanced” settings for the Template Part in the Block Inspector, alongside potential new icon options for setting a Template area as shown in PR #30005:

For a working example, Invision prototypes have a similar option allowing you to lock elements to the top or bottom of the browser window:

[mtias]

Definitely something we need to get to! (I think this should also be available for the Group block.) I'd consider this to be part of the layout / alignments panel to which we recently added this:

[aristath]

In my experience, fixed is a bit... troublesome, especially in a responsive world 😅 Maybe we could use sticky instead?

[carolinan]

I temporarily created a custom block style for a sticky header in a theme, but I had to make it available for all template parts and not just the header 😬 #31171

[andrewserong]

Just assigning myself to this one as I'd like to have a go at coming up with a solution for it. Nothing to see yet, but I'll be hacking away over in #38039 (I thought I'd try sticky support to begin with).

[andrewserong]

Update: while I've made a start on exploring this issue in #38039, I'm switching over to focusing on helping move forward the styles engine (#38167) in the shorter-term. My aim is to get back to this fixed/sticky position support once the styles engine has progressed a little further. (If anyone else wants to pick up this issue and explore it, don't let that stop you, though!)

[mtias]

@critterverse another thing I'd like to see us address is how we present these things in the list view. For example, at the root level of the document, fixed / absolute positioned elements could be grouped as its own tree. This would allow easier management of non-flowing elements. Not sure how we should represent absolutely positioned elements within another container down the tree.

[beafialho]

Just came across this and chiming in to say how this would be really neat to have.

Some aspects worth considering for this functionality would be:

• The ability to control the opacity of this sticky element background
• The possibility of it shrinking its height on scroll
• Being able to have an element be fixed not only at the top or bottom: here's an example of what I mean

[bradhogan]

Definitely +1 on this. All of the other major CMS platforms have this and it would really help us designer / developers to stay competitive :)

[jasmussen]

Relative can probably be default, right? It doesn't have to translate 1:1 to CSS. As far as absolute, I think it could be a bridge to cross when we get there: the free-form layout use cases that come to mind seem like they might require some separate design thoughts altogether.

[jameskoster]

It really depends on whether we want to support the full expression of CSS. There may be situations where you want child blocks to be positioned absolutely relative to the viewport, in which case position: static would be required on the parent.

Relative can probably be default, right? It doesn't have to translate 1:1 to CSS

It's not a strong feeling, but I'd lean towards making static the default and providing relative as an option, only because it does match CSS and that may be helpful to those who are familiar with the syntax.

I agree that it's probably fair to cross the bridge later like you say, but still good to keep in mind.

[andrewserong]

Update: I've added some notes on next steps for the WIP PR here (#44723 (comment)) along with a couple of comments on the current blockers — still a fair bit more to be done before it'll be ready for testing. I'll be AFK off and on for the next couple of weeks, but will pick up the PR again once I'm back.

A few thoughts / things that might be good to get some design input on:

• I think it'll make most sense to work on LayoutPanel: Switch to using the ToolsPanel #44560 prior to attempting to stabilise the sticky positioning PR, as it'll need the ToolsPanel in place so that we don't create UI that's too prominent
• In addition to the Default / Sticky / Fixed controls, we'll still need a way for users to at least select Top / Bottom positioning so that we can support sticky footers as well as headers. The original designs in the issue description had an Area section, but perhaps there's another way to go about it?
• What is the desired behaviour across desktop and mobile? E.g. should the user be able to flag the setting for one of desktop or mobile, or both? I'm mostly thinking of big headers that would be too big for mobile, or sites that want a sticky header on mobile, but not on desktop. Would something like the Overlay Menu of the Navigation block work — only instead of Off / Mobile / Always, have something like Desktop / Mobile / Both?

I'll just add the Needs Design label — I think the controls for selecting position, and the desired mobile behaviour probably need a little more exploration prior to working much further on the WIP PR. In the meantime, I'll be happy to pick up the Layout -> ToolsPanel task once I'm back if no-one beats me to it 🙂

[jasmussen]

In addition to the Default / Sticky / Fixed controls, we'll still need a way for users to at least select Top / Bottom positioning so that we can support sticky footers as well as headers. The original designs in the issue description had an Area section, but perhaps there's another way to go about it?

I'm not in love with the following mockup, but for now it can maybe serve as a general idea of how it might work:

Outside of compression to a single row, the dropdown would theoretically scale to relative and static positions, if we chose to include those at some point. What do you think?

What is the desired behaviour across desktop and mobile? E.g. should the user be able to flag the setting for one of desktop or mobile, or both? I'm mostly thinking of big headers that would be too big for mobile, or sites that want a sticky header on mobile, but not on desktop. Would something like the Overlay Menu of the Navigation block work — only instead of Off / Mobile / Always, have something like Desktop / Mobile / Both?

It is likely that we will need to tackle something along the lines of #19909 to enable this and similar cases, but for the near future I'd keep it simple and just have the behavior be the same across all breakpoints.

[jameskoster]

It seems important not to conflate position: sticky and position: fixed.

Do we need the "Placement" control? It appears that making something sticky relative to the bottom of the viewport is a bit hacky. It also doesn't solve the fixed-footer use case.

[jasmussen]

I like to start with as little as possible, and only add controls when we know for sure they are needed. I'd love to start with just the segmented control if we can.

[jameskoster]

+1.

Position

• Default
• Sticky

Feels like a good place to start and a very neat enhancement on its own.

[jasmussen]

I've updated this issue with the latest mockups and ideas from the comments. It was already assigned a dev, so hopefully this just adds clarity!

[andrewserong]

Thanks for updating the designs! Just to double-check, so in the initial implementation we are only allowing sticky to the top position, and not footer positions (the issue title still flags footer)? The way I've implemented how we store the data for it in the WIP PR, we can support more positions (e.g. footer), but I agree with the idea here that we'd expose only the minimal control to begin with. It also very much helps us explore building this feature incrementally. Though I do really like the additional placement control in this comment: #30121 (comment), perhaps for a follow-up?

[jasmussen]

so in the initial implementation we are only allowing sticky to the top position, and not footer positions

Yes, purely to keep the implementation as simple as possible, and I would consider it mainly a UI thing. I'm sure we'll follow up, it might also allow us to refine the placement control a bit; even if it might work, it's a little complex.

[andrewserong]

Update: there's been lots of great discussion on this feature lately, so I thought I'd try to recap where things currently sit, as the discussion is spread across a number of PRs:

• Active discussion is underway to explore options for the design of the UI controls over in: Design for Position UI #46032
• The original PR exploring the feature, which generated a lot of discussion is in: [WIP] Layout: Explore adding in sticky position support within the layout support #44723
• Out of that PR, the idea was to look at converting the LayoutPanel to use the ToolsPanel so that the Position controls could be hidden by default. Exploring this unearthed a number of challenges and complexities with the LayoutPanel, making the conversion look not quite as straightforward as first thought. There is some discussion that the panel might need to be rethought in order to support such a conversion over in the WIP PR: [WIP] LayoutPanel: Update to use ToolsPanel and ToolsPanelItems #45833 — for the moment, it might be worth seeing if we can park that PR as a requirement
• Based on the more recent design discussion surrounding the UI (Design for Position UI #46032), I've had a go at exploring how the position support might look if the controls were placed under the Advanced panel over in this alternate PR: Design Tools: Add a Position block support (including sticky), decoupled from layout #46142
• Whichever direction we go in, there are some other things that will need to be tweaked in order for sticky/fixed blocks to be properly usable in the editor. The main task at the moment is to ensure that the toolbar positioning is correct in the editor, so that sticky / fixed blocks are not obscured by the toolbar. I have an open PR that looks at exploring a solution over in Block Selection Toolbar: Support fixed blocks by flipping toolbar when block goes out of view #46085 — this does deviate from behaviour on trunk so will likely require feedback / adjustment to find the right balance

---

Quick links for active work:

• Design Tools: Add a Position block support (including sticky), decoupled from layout #46142 (main current PR)
• Design for Position UI #46032 (main discussion)

[jasmussen]

I created mockups in #46032 (reply in thread) that try to take a near-term/long-term look at it.l What do you think? Thank you for the update 🙏

[andrewserong]

I'm wrapping up for the year now, so just a quick update on the current WIP work exploring a solution for this (with discussion still ongoing over in: #46032)

• I've rebased and updated the current WIP PR that implements the sticky block support feature. This one has the Position controls under its own collapsible panel in the sidebar, and rolls in some experimental fixes for the block selection toolbar positioning. For a screengrab / short video of the current state of the work, see this comment: Design Tools: Add a Position block support (including sticky), decoupled from layout #46142 (comment)
• To fix issues with the block selection toolbar and how it is positioned in relation to a sticky or fixed block, there are currently two WIP PRs. I first started 46085 as a potential solution, which would have switched over the popover strategy for the toolbar to fixed. However, this introduced some subtle issues that were difficult to detangle, so I have since opened up a new PR that explores an alternate (and slightly simpler) approach of forcing a re-render whenever the block canvas is scrolled. It might not be the most performant approach, but it's the closest fix I've come up with so far: Block Selection Toolbar: Support fixed and sticky blocks by flipping when there is not enough space above the block #46565

If anyone is keen to jump in to any of this work while I'm away, feel free to hack away at any of the open PRs, take them for a spin, or offer feedback on the discussions. In particular, any feedback on the usability of the current WIP (#46142), and accessing the position UI from within the sidebar will be helpful, along with any insights or suggestions for how to resolve issues with the block selection toolbar (#46565). No worries if no-one has a chance to look at it, though, I'll pick all this up again when I'm back! 👋

[andrewserong]

Update: we've merged in the initial PR to implement this feature in #46142. To recap where the feature currently stands:

• The initial implementation adds a position block support, via a Position collapsible panel that appears in the sidebar inspector controls, just above the Advanced panel, and only for the Group block.
• Initially, "sticky" is the only position type that is opted into.
• The only position that is support for now is 'top' and this is automatically set when you set a position on a block.
• Setting a Group block to "sticky" will stick it to the top of the viewport when the user scrolls down the page, but only to the area of the block's parent. This means that for a fixed or sticky header in a site template, the sticky position should be set on a Group block that sits at the very top of the block hierarchy — the header template part would then be placed inside this Group block.
• Sticky / fixed footers are not yet supported.
• I've opened up a separate issue for follow-up tasks and for us to continue exploring / improving and enhancing these features. The issue is here: Fixed / Sticky position follow up tasks #47043

There's a fair bit more to do to improve on the feature and build out some of the remaining features, tasks and use cases. As flagged in reviews in #46142, there is a discoverability issue in setting up a site with a fixed header, given that it's a bit fiddly to do with 'sticky' alone.

For any ideas, suggestions, improvements, or thoughts on direction for the feature, let's add to the tasks over in #47043 — feel free to edit / add to that list as anyone sees fit!

Thanks again for all the collaboration on honing in on an MVP for the feature within the plugin 🤗

[andrewserong]

Just including a screengrab of the current state of this feature, for quick reference. The screengrab below demos wrapping a header template part in a group block, setting that group block to full width, then setting that group block to "sticky":

header-wrapped-in-sticky-group.mp4