Proposal: Extend Separator to include Spacer capabilities

[iamthomasbishop]

As I am thinking ahead to when we start building the Spacer block, I am surveying the current state of these blocks on Core and my experience of using Separator/Spacer blocks regularly while writing posts/pages. This proposal is based on a work-around I’ve found myself repeatedly doing, and lays out what I think might be a nice solution.

Use Case

I’m not sure how common this is for others, but I often finding myself adding section breaks or white space to a post or page. When I do this, I usually want a visual divider element and some additional white space because I find that more often than not Separator blocks are too short (depending on theme’s styling, type rhythm, etc), so I end up repeating this flow regularly:

1. Add Spacer blocks above/below Separator to add additional spacing (these blocks default to 100px)
2. Preview
3. Adjust spacer heights to approx. desired dimensions
4. Preview again
5. Rinse and repeat until it looks good

Proposed Solution

My proposed solution is to extend the Separator block to include the capabilities of the Spacer block.

With this, the user would be able to:

• Use the Separator block as-is (choose a style)
• Adjust the height of the block by dragging the edges of the inner block, or form inputs
• Toggle visibility of the divider (this would be an addition)

Bonus enhancements to consider might also be:

• Allow the user to choose from some standard vertical alignments (top, default (middle), bottom)
• Allow the user to fine-tune the margins above/below the divider

Feedback?

Would love to hear some thoughts on this idea. We’ll still obviously have to build support for both blocks in the long-term because folks will continue to use both on other editors, but I think in terms of mobile GB creation-side this would work. // pinging @koke @hypest @pinarol for feedback, but obviously any and all feedback is welcome!

Note

I double-checked to see if there was anything on Core GB Github related to this, but haven’t found anything. If we try this and find it’s useful, it might be worth proposing this upward to Core. // @jasmussen

[jasmussen]

My proposed solution is to extend the Separator block to include the capabilities of the Spacer block.

That seems like a great extension. You could even make transforms, so you can transform a separator into a spacer, and vice versa. I would suggest this has value to the web-project as well, and not just the mobile version!

[koke]

More than transforming, I wonder if it makes sense to combine the two into one block. I think one could consider a spacer to be just a separator with a style that uses whitespace, so it makes sense to me. In any case, something worth proposing in core.

[jasmussen]

I had the same thought, but I believe there can be value in them being separate. Primarily in terms of each being available as separate search items — even if you can search for "spacer" and find "separator", it might be simpler to just find the Spacer. Secondarily because you could imagine additional features coming that go in separate directions. A spacer migth work horizontally as well.

[koke]

each being available as separate search items

I can see that, but also feels like a more general problem: should blocks be able to define keywords for searching other than their block title? (Aside: I always get annoyed when using Gutenberg in Spanish because the block names are translated, and I search for the wrong thing)

A spacer migth work horizontally as well.

A separator too 😁 Although some of the styles for vertical separation might not work great horizontally.

[jasmussen]

Coblocks has this, called "Dynamic HR":

[SergioEstevao]

@iamthomasbishop now that we have the spacer block, do you think we still need this?

[iamthomasbishop]

@SergioEstevao While I think I'd adjust the proposal slightly based on what we've learned over the past year or so, I think the use case is still very much relevant so I would keep it open.

In terms of solutions, I think something like the Dynamic HR block that @jasmussen mentioned is pretty close to what I would like to see. I'm curious if there has already been any interest in adding this type of functionality to the core Separator block on the web side? If so, we should just utilize that.

If there hasn't already been any interest in extending the core Separator block, we have a few options:

• Propose it on the web and help get it across the finish line so we can utilize it — this would probably be the least fragile of the options (note: we obviously do not support third party blocks on mobile yet, otherwise I'd propose using the Dynamic HR block as-is)
• If there is no interest in adding to core, we could extend the Separator block on mobile-only to add a height setting — I imagine we could architect it in a way so that mobile setting is unaffected by updates to the core block, but it might be hard to foresee every possible consequence
• Alternatively, we could create a fork of the core Separator block for mobile-only and add a height setting to it — obviously this would mean if the core Separator block ever changed we'd need to decide how to iterate on our side, but in theory, nothing would "break" per se

I think my vote would be to extend the Separator block on the core side, but if there is no interest to adding at the source and we're unable to get that through, I would vote for forking and creating a mobile-specific "Dynamic Separator" block that keeps the Separator block as-is but gives us freedom and flexibility.

Another thing worth mentioning is that at some point, I imagine spacing settings/properties such as padding, margin, etc. may be added on the core side, although I have no idea when or if it's actually going to happen. If this were to be added, in theory, as a user I could manually add margins to a separator block and that could be enough. IMO, simply allowing the user to adjust a single height slider would be the most straight forward and expected interaction here.

[jasmussen]

I think the separator can grow greatly in features, both in visual styles and such, but perhaps it could even include an editable field to insert a typographic element to use as the separator "graphic". There might even be a place, also, for the dynamic separator mentioned, for more graphic elements, resizable and so on. I'm also hoping for controls to adjust margins and spacing on individual blocks, as part of the global styles efforts.

However all of those are features that are perhaps best explored and added to the core project itself. I would also caution against adding mobile-only features on a per-block basis. I'm crossing my fingers that true wysiwyg is still in the cards for the mobile editor at some point in the future, but even if it isn't and the mobile native editor will be locked to a "writing mode" of sorts (see also https://github.com/WordPress/gutenberg/pull/22494), the published result should still share DNA with what's seen in the editor.