Fixed / Sticky position follow up tasks

[andrewserong]

Related:

• This issues follows on from: Fixed Position Header and Footer Template Parts #30121
• Discussion in: Design for Position UI #46032

An initial implementation of sticky position block support was added and enabled on the Group block in: #46142. This issue lists follow-up tasks now that the initial PR has landed. Some of these could be split out into their own issues depending on complexity.

Current state of sticky position support

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

Follow-up tasks

• Re-enable sticky in non-root positions. Once this has been resolved, we can then close out Sticky positioning: nesting a sticky group block doesn't remove the sticky positioning #49903 and Position "sticky" - Gutenberg 15.1.0 killed sidebar option #47892 — WIP PR
• Explore opting the Columns block in to sticky position
• Update List View to flag in the UI when a block has a position value set (WIP PR)
• Update z-index approach to remove hard-coded z-index values and replace with presets in theme.json.
• Look into enabling fixed position on the Group block, and what other controls are required (e.g. width or more fine-grained position controls as described in Fixed Position Header and Footer Template Parts #30121)
• Look into position UI for top/left/right/bottom positions and offsets, in particular support for fixed/sticky footers
• Improve the experience for setting a sticky or fixed header, e.g. is it possible to achieve without having to wrap the header template part in a sticky Group block? Related issue: Add support for Position setting to Template Parts for Sticky Headers #50617
• Explore whether there needs to be a control to lock the position settings to just desktop or mobile viewports?
• Explore outputting scroll-padding-top for fixed / sticky headers to ensure that links to parts of a page scroll correctly without being cut off: Make sticky positioning work with internal links and scroll padding #48656
• Position Panel: Open by default if a position type is set #49151
• Sticky Position: Add a "Make sticky" action to the Template Part block #49085 (Note: reverted in Revert: Make sticky block action on template part block #49219)
• Open up a PR in wordpress-develop to enable position CSS values in core (PR | Trac ticket)

Related tasks and issues

These tasks might not be immediately related, but in terms of UX and features, there could be some overlap to explore in the implementation:

• Negative margin in dimension controls #32644 (this would likely require some kind of z-index controls)

[jameskoster]

e.g. is it possible to achieve without having to wrap the header template part in a sticky Group block?

I've said this elsewhere, but I don't think this is something to be avoided. My opinion is that the document should decide the position of its blocks rather than the blocks themselves. Otherwise it prohibits things like template parts or reusable blocks from being conditionally sticky, unless we build a complex position over-ride UI which probably is something to avoid.

We can still simplify the process though. Perhaps there's an option in the template part toolbar (ellipsis menu?) to make it sticky, which is essentially a shortcut to wrap it in a container with position: sticky applied.

Which leads me neatly to:

Update List View to flag in the UI when a block has a position value set

It might be interesting to try a simple prefix (or suffix) added to the block name, denoting non-default position values. "Group (sticky)", for example. We could even consider surfacing this as a variation in the Inserter to enable quick creation of sticky regions in a document.

[priethor]

I've said this elsewhere, but I don't think this is something to be avoided. My opinion is that the document should decide the position of its blocks rather than the blocks themselves.

That's good reasoning. On the other hand, it could also be applied to settings like width and height, as a reusable block will have a different width within a full-width container vs. when placed inside a column. For now, I think we might want to not open that can of worms because if we want the position to be set at the document level, we would need to review what other settings should follow the same logic.

[jameskoster]

The challenge we face with any such setting is clarity around where/when they will be applied. For example we used to have a background color option for template parts. This constantly tripped people up, because they'd edit a template, select the Header, change the background, and expect that change to be applied to the template part globally.

We'd run into that problem again here. That's not to say it's insurmountable. Just that we'd need to consider a 'local overrides' UI with resetting, or some foundational changes to the inline editing experience that draws clearer lines between document + template part / reusable block (#43608 might help).

[apeatling]

My vote would go for allowing block supports on template parts, because:

• This follows the most logical path for a user based on how everything else works. Select the template part like a block, set to sticky.
• It allows a user to decide which templates a template part is sticky on.
• It avoids any extra UI, wrapping it in a group block will be unexpected, muddy block selection, and users will wonder how it got there.
• You can be super selective on which block supports a template part utilizes -- just leave out things like background color that have confused in the past. (Edit: this doesn't solve the global vs local confusion)
• Maybe there could be a way in the future to set the default supports values (like sticky) by a pattern author when being inserted within a template part?

I'm probably missing some important details and nuance. :)

[andrewserong]

Great discussion here, folks! I love the idea of exposing the position controls at the template part block level in terms of making it that accessible / discoverable to a user. However, @jameskoster makes a good point that this runs into issues to do with the local versus global nature of editing template parts. That is, the position value will only be set on the particular instance of the template part within the template being edited, and won't be applied globally to the header template part across all templates. Figuring out the desired UX there (and technical implementation if we went with document-level attributes) might be quite tricky, too... 🤔

To give us a little more to play with to come up with a direction forward, I've opened up a PR to opt the template part block in to the position support over in #47133 — this PR isn't intended to land, but I thought I'd open it up to hopefully have something to aid the discussion about how we should proceed. My first impression is that it feels pretty good to use, but as in the reasoning behind the earlier removal of styles from the template part block (in #36571), I can definitely see how a user would expect their changes to apply across templates, and be confused as to why it isn't. I could imagine that being a blocker.

[fabiankaegy]

I was just playing with the position control and struggled to figure out how to make my header template part sticky. So the current flow is creating a bad experience for someone that doesn't necessarily understand the technical details.

I really like the idea of exposing the position controls on the template part as well. I think that would help a lot. Additionally, it might be a good enhancement to hide the sticky position setting in areas where it doesn't do anything. If we know that setting it on the wrapping group inside of a template part it isn't ideal that the setting is even available.

[andrewserong]

Thanks for the continued feedback, everyone! As another potential idea for how we might improve the UX here, I've opened up a PR to explore adding a warning notice next to the Sticky position control if the group block is at a non-root level (a little bit like how we have contrast checker warnings). The PR is here: #47207

Using Sticky positioning for things that are not site-wide headers and footers can be quite useful (I see this a lot on real estate websites, or on some sites with contact info areas that scroll for only a particular section), however it's likely not the common use case (which we're imagining to be sticky headers). I'm wondering if the additional notice when the block is not at the root level could help nudge users in the right direction / help with the UX there, irrespective of whether or not we wind up enabling sticky support for the template block.

Another option could be to hide the Sticky position controls altogether if the block is not set to the root of the document — personally, I'd prefer to avoid this if possible, since it's quite cool to be able to create sticky areas within a larger document, and it'd be nice to make that available if we can. Happy for any feedback / ideas / discussion over in #47207 if folks are interested.

[richtabor]

I was just playing with the position control and struggled to figure out how to make my header template part sticky. So the current flow is creating a bad experience for someone that doesn't necessarily understand the technical details.

I agree. It's not intuitive and also buries the Header template part in List view.

And if buried, the template doesn't show up in the "Template" inspector sidebar.

[richtabor]

Ideally, you'd edit the template part, add sticky positioning, and the stickiness would be applied to the parent template part across the site.

Kind of a tall order, but is there way to detect and apply the positioning to the template part, if the stickied block is a direct child of a template part block?

[jameskoster]

And if buried, the template doesn't show up in the "Template" inspector sidebar.

I'd say that's a bug. Edit: I opened #47213

[andrewserong]

I've opened up a PR to explore adding a warning notice next to the Sticky position control

Based on feedback, I've closed out that PR and opened up an alternate PR that explores a simpler change that updates the hint text for Sticky Position to be aware of whether or not the block currently has a parent. It's a subtle change, but hopefully will improve that part of things a little bit: #47230

[richtabor]

Now that #47334 is merged (and the position is only available on root blocks), we can punt these follow-ups post 6.2.

[fabiankaegy]

• Open up a PR in wordpress-develop to enable position CSS values in core

I believe this would still be required to happen before the code freeze in order to land the feature in core at all for 6.2

[andrewserong]

The sticky block was sticky all right. But should it have been?

Thanks for raising the question. The sticky position is fairly naive, like all other block supports, so it isn't contextually aware of where it is being displayed when it's rendered. So in this case, I think that's to be expected.

[andrewserong]

Small update: I have an open PR to try to improve the experience of dealing with wrapping a template part block in a sticky group. In #49085, a "Make sticky" button is added to the block menu for the template part block — when clicked, it'll wrap the block in a sticky group block, and the button only shows if the template part is at the root of the document. Happy for any feedback over on the PR!

[annezazu]

👋🏼 Some feedback that came in through the FSE Outreach Program around a use case for using sticky positioning that I thought would be helpful to pass along. Sharing in case it helps ground future work -- someone wants to create a site where the left hand side is sticky and doesn't scroll whereas on the right side photos/posts scroll by:

scrolling.mov

Because sticky positioning can't be added to a columns block, this isn't currently possible.

[andrewserong]

Thanks for sharing @annezazu! That'll be a good test case for us to use when we explore re-adding the sticky position support to non-root positions, and will make a solid argument for its inclusion. Along with opting-in for the columns block (I've added this to the list of tasks). Cheers!

[apeatling]

These real usage examples are great and help keep the development grounded. Also gives good ideas for demoing the new functionality. :)

[andrewserong]

I have a PR open in #49321 to explore re-enabling non-root sticky position, and adding a visualizer to define the sticky area visually. It's a little experimental, but very happy for feedback and/or ideas on the PR!

[ndiego]

@andrewserong can I remove this from the 6.3 Project Board, or would you prefer we keep it? Just trying to tidy up the board 😅

[andrewserong]

Thanks for the ping @ndiego! I've removed this from the project board now as the PRs for 6.3 have all been merged (e.g. #49321 and #49122) 🙂

[apeatling]

Nice work so far on this @andrewserong, lots of good changes for folks upgrading to 6.3. 👍

[miklb]

Ideally, you'd edit the template part, add sticky positioning, and the stickiness would be applied to the parent template part across the site.

Kind of a tall order, but is there way to detect and apply the positioning to the template part, if the stickied block is a direct child of a template part block?

Seems like there should be a way using:has but I haven't dug in deep. Just experienced this issue and the counter intuitiveness. Editing every template that uses a header if you want it sticky site wide seems a bit much.

[SporeProductions]

Still not working in Twenty Twenty-Five