Design Tools: Add a Position block support (including sticky), decoupled from layout #46142
Conversation
andrewserong
added
[Status] In Progress
|
Size Change: +2.4 kB (0%) Total Size: 1.32 MB
ℹ️ View Unchanged
|
|
Update: based on discussion over in #46032, I thought I'd have a go at using a 2022-12-01-custom-select-control.mp4 |
|
Update: based on discussions over in #46032 (reply in thread), I thought I'd have a go at moving the control over to a separate
|
|
Thanks for working on this feature Andrew! I am not updated on the discussion but my initial thought is that it would be nice to have this in a toggle. |
|
Took this for a spin, it's not bad:
Of course if the split tabs experiment isn't enabled, the list can grow a bit long. Is it possible to show this position panel above the "advanced" panel?, i.e. at the end of the stack?
@paaljoachim We did consider a toggle. There's a longer discussion in #46032. One of the hopes here is we can start with an interface that can grow into supporting "Fixed" also. @jameskoster @mtias could this serve as a starting point, that grows in the future as the position panel potentially becomes a toolspanel, and fixed is added? |
andrewserong
force-pushed
the
try/position-support-decoupled-from-layout
branch
from
8b8cd9c to
338d16b
Compare
Good catch, and thanks for taking this for a spin! I've pushed an update (338d16b) that explicitly places the
|
|
Thanks for your patience with this one. Current status:
Some thoughts on launchability.
That makes this a pretty low-footprint feature addition, that could probably only be made simpler by moving it to the "Advanced" panel, postponing the conversation on a "Position" panel. I think the question then boils down to: is it useful to start with just sticky, or do we need fixed from the get-go after all?
I personally think we can iterate (land things step by step) so long as we have some confidence in the end result. And so to answer the question: can we land "sticky" as the first step, it might be useful to ask some theme designers: how could you see yourself using it? Would it be useful in a pattern? CC: @WordPress/gutenberg-design @WordPress/theme-team |
|
Thanks for the recap and thoughts about next steps @jasmussen! Just a couple more things to add:
|
andrewserong
force-pushed
the
try/position-support-decoupled-from-layout
branch
from
338d16b to
3bb4f9f
Compare
|
I'm wrapping up for the year now. To keep this a working snapshot of the current progress toward a sticky position support, I've given this a rebase and rolled in one of the proposed fixes for the positioning of the block selection toolbar (#46565). While there's still things that need to be tweaked in this PR I'm sure, this should be an accurate representation now of where we're currently at. Here is a quick demo of the current state, and how to set a Header to be sticky by wrapping it in a Group block that is set at the root of the site, and then switching it over to "sticky": convert-header-to-sticky.mp4In the above video:
Some of the limitations of the current approach:
I'll pick this up again when I'm back in the new year, but very happy if anyone wants to hack on this PR, branch from it, and/or help out with the related PR to look into block selection toolbar fixes (#46565). No worries if not, I'll happily resume from where I left off once I'm back. Thanks again for all the feedback and collaboration on this one! |
Imo this is fine. It should always be the template that defines stickiness, not the part itself. Otherwise we'd need to design a UI to override the inherent sticky behavior per template, and that starts to get very complicated. The flexibility can be useful too – on some templates you might want to include additional blocks in the sticky region (sale banner on a product category archive for example). It's a shame that you have to wrap the template part in a Group as that isn't particularly discoverable, but we can probably solve that separately. It may only require something simple like a "Sticky Group" variation. |
Can't it be a group inside the template part? |
|
I don't think so, because sticky.mp4 |
|
Oh, I forgot that. Does the template part always output a container? I may have mentally grouped it with RBs. If yes, then if need be we could bring sticky to the template part itself, if it turns out succesful. |
|
It gets tricky if we do that. We learned before that folks expect template part edits to be global, but block properties are local to the parent document. This is why we had to remove background color options on template parts back in the day, it just gets way too confusing when you mix global / local settings. |
|
Indeed. I don't think it's the end of the world to wrap the template part in a group. |
|
Agreed, especially if we decide that a "Sticky" Group variation makes sense. |
|
If we are to have a single interface for sticky and fixed, potentially absolute in the future, and possibly an interface that might even expand beyond just the group, wouldn't that make a "sticky group" variation redundant? |
|
I don't think so. I see the variation serving two purposes:
That said, it doesn't deserve the same prominence as other variations like Row and Stack, especially as Rows and Stacks can be sticky too :) So perhaps it's less of a variation in the traditional sense, and more of a treatment conditionally applied to containers based on Definitely not something to worry about here/now though :) |
|
Thanks for all the reviews and collaboration on this one, everyone!
Agreed, I think we've honed in on a good initial set of features for now. I've opened up an issue in #47043 to list follow-up tasks, which should be a little easier to implement now that we've got the foundation in. Feel free to add / edit the list if anyone has other items to add! |
|
Hi folks, I missed the introduction of this block support but I have some high-level questions/thoughts about this. At first, I'd agree that setting a layout and setting a position is two different things but there are strong relations between the two:
Are these things you've discussed, what's the current approach and do we have a "plan" to go there? |
I agree, but the 'safe start' element is why we restricted this to Groups for now. It also enables the creation of sticky headers which was one of the driving forces in adding this functionality.
I believe so, yes. There's lots of back-scroll on the design discussion here. We explored how the control can support other position values (absolute and fixed), then rowed back to the simplest execution for sticky as a starting point. |
|
Thanks for adding the thoughts and questions @youknowriad!
Yes, this gives us a much safer level of scope for testing and making further changes — once we've got a stabilised and fully fleshed out suite of features, we could look at switching over to more of an opt-out approach. For the moment, it's been very helpful being deliberate about the opt-in approach, especially with feedback on how
There's definitely a close relationship between layout and position, but after previous PRs that explored tying the implementation of position to layout, it became clear that it's helpful for there to be at least some separation between the two, which is how we settled on having it be its own support. It gives us more flexibility in being able to open up controls outside of layout (e.g. relative/absolute) in the future. However, it also doesn't box us into a corner in that we can always roll the controls into the Layout UI in the future if we need to. But one of the other concerns is that Layout has already grown quite a lot in complexity, so to manage that, it's helpful to have a position support that uses a similar approach, but sits just off to the side.
Yes, we considered that and it informed the shape of the position object. Absolute would be represented in the same way as the current sticky position, using So, we don't yet support relative/absolute output, etc, but the shape of the data will support it.
The plan for the moment is to refine the controls for sticky positioning, with the objective to land it as part of 6.2. The work is being tracked in a follow-up issue of tasks here: #47043 For future exploratory designs, there is discussion over in #46032, with some UI controls being explored further down, too. In terms of next steps, I think once we're past the 6.2 feature freeze and have sticky positioning polished to the best place we can, it'd be good to start with a design-led approach to how the UI/UX should work for the other kinds of positioning, and then we could look at breaking down the tasks from there. In terms of the data model for attributes / structure of where the code lives, I think we landed on a pretty good approach in this PR that should set us up well for exploring those follow-ups. |
Adds support for the following CSS properties considered safe for inline CSS: * `position` * `top` * `right` * `bottom` * `left` * `z-index` References: * [WordPress/gutenberg#46142 Gutenberg PR 46142]. Follow-up to [54117]. Props andrewserong, mukesh27. Fixes #57504. git-svn-id: https://develop.svn.wordpress.org/trunk@55184 602fd350-edb4-49c9-b593-d223f7449a82
Adds support for the following CSS properties considered safe for inline CSS: * `position` * `top` * `right` * `bottom` * `left` * `z-index` References: * [WordPress/gutenberg#46142 Gutenberg PR 46142]. Follow-up to [54117]. Props andrewserong, mukesh27. Fixes #57504. Built from https://develop.svn.wordpress.org/trunk@55184 git-svn-id: http://core.svn.wordpress.org/trunk@54717 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds support for the following CSS properties considered safe for inline CSS: * `position` * `top` * `right` * `bottom` * `left` * `z-index` References: * [WordPress/gutenberg#46142 Gutenberg PR 46142]. Follow-up to [54117]. Props andrewserong, mukesh27. Fixes #57504. Built from https://develop.svn.wordpress.org/trunk@55184 git-svn-id: https://core.svn.wordpress.org/trunk@54717 1a063a9b-81f0-0310-95a4-ce76da25c4cd
bph
added
the
Needs Dev Note
Dev notes for 6.2Note: if there's room, this dev note could potentially be combined with other design tools in a larger dev note. There is a bit of information to convey, though, so alternately it could be its own standalone note. Draft below: Sticky position block supportWordPress 6.2 adds a new position block support feature, beginning with support for sticky positioning, with the Group block opted-in by default. For themes using the The sticky positioning feature follows the CSS behavior for This is just the beginning of the position block support feature, and there are ideas for future enhancements, including rolling out sticky to non-root blocks, and improving the UX surrounding building sticky site headers. There is an open issue in the Gutenberg repo to track progress beyond 6.2. How to add sticky position support to a themeThere are two ways to add support for sticky position to a blocks theme. The simplest is to opt in to the For themes that wish to have more granular control over which UI tools are enabled, the sticky position support can be opted into by setting How does it work?When a user sets a block to the sticky position via the drop-down list in the inspector controls, styling rules are output for To support the output of these position properties, the The styling rules are output when the block is rendered, and a classname Why was support for non-root sticky blocks removed in Gutenberg?While the feature was being developed in the Gutenberg plugin, sticky positioning was initially enabled in all hierarchies of blocks. However, in manual testing, feedback indicated that without additional UI or UX work, it could be confusing for users attempting to create sticky headers if they accidentally set a non-root block to sticky, or for example, a block within a header template part to sticky. The decision was to scale back the feature to just the root blocks for 6.2 to allow more time to explore a good solution for nested blocks. See the discussion in this Gutenberg issue for more context. Why is positioning not available in global styles?The position block support has been designed to be set within individual block attributes, as positioning is typically set for an individual block, rather than globally for a particular block type. Therefore, within Further reading
@bph for visibility, here's a draft dev note for the sticky position block support. |
bph
added
has dev note
|
Thank you so much @andrewserong I think this should be a stand-alone dev note, as it's a pretty neat feature. Would you have bandwidth to post it as a draft on the Make Blog to get it into the publishing queue for the field guide? |
|
Thanks @bph, a stand-alone dev note sounds good to me! Here's a draft on the Make blog for sticky position block support: https://make.wordpress.org/core/?p=103009&preview=1&_ppp=7494b4dec7 |
|
Thank you! @andrewserong |
Adds support for the following CSS properties considered safe for inline CSS: * `position` * `top` * `right` * `bottom` * `left` * `z-index` References: * [WordPress/gutenberg#46142 Gutenberg PR 46142]. Follow-up to [54117]. Props andrewserong, mukesh27. Fixes #57504. Built from https://develop.svn.wordpress.org/trunk@55184 git-svn-id: http://core.svn.wordpress.org/trunk@54717 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Related
What?
Fixes: #30121 (note this PR is still a WIP, so the "fixes" label here is simply to associate this PR with the open issue)
This PR is an alternative to #44723, and adds support for sticky position, decoupled from the Layout panel and whether or not a block has layout support. It explores ideas from the discussion in #46032
Why?
Sticky / fixed position will be valuable for sticky headers and footers, and creative pattern applications. However, it is likely to be used infrequently, and needs to be de-emphasised in the UI. This PR is an exploration of the ideas in #46032, to see what the most minimal version of the feature might look like.
How?
Testing Instructions
Note: sticky position will stick to the top of the direct parent block. If at first it appears not to be working, ensure that the parent block is tall enough / has enough content to be scrolled.
Screenshots or screencast
The position control situated under Position:
A screengrab of selecting the control from the Position panel: