search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.48k stars 4.18k forks source link

Fixed / Sticky position follow up tasks #47043

Open andrewserong opened 1 year ago

andrewserong commented 1 year ago

Related:

An initial implementation of sticky position block support was added and enabled on the Group block in: https://github.com/WordPress/gutenberg/pull/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":

https://user-images.githubusercontent.com/14988353/211697403-f9f80970-c51f-4684-92d0-7dbfe03d56c6.mp4

Follow-up tasks

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:

jameskoster commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 (https://github.com/WordPress/gutenberg/issues/43608 might help).

apeatling commented 1 year ago

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

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

andrewserong commented 1 year ago

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 https://github.com/WordPress/gutenberg/pull/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 https://github.com/WordPress/gutenberg/pull/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 commented 1 year ago

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 commented 1 year ago

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: https://github.com/WordPress/gutenberg/pull/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 commented 1 year ago

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.

CleanShot 2023-01-17 at 15 48 23@2x
richtabor commented 1 year ago

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 commented 1 year ago

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

I'd say that's a bug. Edit: I opened https://github.com/WordPress/gutenberg/issues/47213

andrewserong commented 1 year ago

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: https://github.com/WordPress/gutenberg/pull/47230

richtabor commented 1 year ago

Now that https://github.com/WordPress/gutenberg/pull/47334 is merged (and the position is only available on root blocks), we can punt these follow-ups post 6.2.

fabiankaegy commented 1 year ago
  • [ ] 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

jeflopodev commented 1 year ago

IMHO it should work for template parts too.

I dislike having to create an inner block to be able to set sticky positioning.

I've just ended using (as workaround):

.site-header {
    position: sticky;
    top:0;
}
andrewserong commented 1 year ago

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

@fabiankaegy yes, there's an open PR for this over in https://github.com/WordPress/wordpress-develop/pull/3865. Assuming that lands in time, I'll put up a PR this week for the remaining pieces. I've updated the issue description with a link to that PR and the related trac ticket, thanks for the reminder!

It'll work on template part elements ?

For 6.2, sticky positioning will not be available on template part elements directly, it'll just be the Group block that's opted in to sticky positioning. To create sticky headers, it's possible to wrap the template part in a sticky group block with a template (the video in the issue description captures the current state).

courtneyr-dev commented 1 year ago

I thought I almost had a weird workaround going through Template Parts, but it doesn't display on front of site this way. https://user-images.githubusercontent.com/5519705/221712563-a65e8c1f-6466-45e5-9fdc-49aeff3dccee.mp4

andrewserong commented 1 year ago

@courtneyr-dev for it to work with template parts, the template part itself needs to be wrapped in a Group within the template, at the root level, as sticky sticks to the immediate parent. If the sticky block is set within the template part, then it will only stick to the scope of the template part itself (which is to say, it won't appear to be sticky at all).

robglidden commented 1 year ago

I would like sticky to work fully with smooth scrolling (scroll-behavior: smooth, scroll-padding-top).

Canva web pages do this out of the box.

Like putting sticky on a header template part, then creating a new css variable that would contain the height of the sticky header template part.

andrewserong commented 1 year ago

That sounds like a pretty cool feature idea @robglidden. If you have time, would you mind opening up an issue for it, with a little more detail about how you'd expect it to work? Currently the sticky position support is fairly naive, in that it doesn't really know anything about what it's been applied to, and whether or not it should affect things like scroll-padding-top globally, so there could be some nuance in trying to come up with a reliable solution for it.

robglidden commented 1 year ago

Sure, @andrewserong

See #48656 "Make sticky positioning work with internal links and scroll padding"

A starting point: currently, an internal link scrolls to the wrong place when sticky positioning is set on a group.

A modern-Web-first design review would help.

andrewserong commented 1 year ago

Thanks so much for the extra detail @robglidden! I've added that issue to the list of tasks in this issue's description.

bobbingwide commented 1 year ago

I have a question about sticky blocks in posts.

I just created a post with a sticky block and then displayed this post in a query loop on an archive page that displayed the posts using post content.

The sticky block was sticky all right. But should it have been? My view is "Yes, That's fine. It's the documentation of the limitations of sticky position that doesn't cater for this edge case."

PS. I had the same problem as Rich Tabor noted in https://github.com/WordPress/gutenberg/issues/47043#issuecomment-1384956555 But I figured it out while watching the 6.2 Live Demo.

andrewserong commented 1 year ago

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 commented 1 year ago

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 https://github.com/WordPress/gutenberg/pull/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 commented 1 year ago

👋🏼 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:

https://user-images.githubusercontent.com/26996883/233431043-65c111c7-79cd-4856-8a1e-6ab9fd0c76dd.mov

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

andrewserong commented 1 year ago

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 commented 1 year ago

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

andrewserong commented 1 year ago

I have a PR open in https://github.com/WordPress/gutenberg/pull/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 commented 1 year ago

@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 commented 1 year ago

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. https://github.com/WordPress/gutenberg/pull/49321 and https://github.com/WordPress/gutenberg/pull/49122) 🙂

apeatling commented 1 year ago

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

miklb commented 6 months ago

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.