Add supprt for line thickness/Circle size in separator block

[senadir]

Description

follow up to #16784 & #16925
tackles a point from #16483

this PR adds size control to separator block (thickness of line & size of circle)

How has this been tested?

using Gutenberg starter theme
create separator components in master
switch to this branch
no problems happens

Screenshots

Problems

• while this doesn't deprecate anything, I'm feeling like it's a bit fragile and need some testing, I've done some testing but I didn't have time to test on other themes.

Changes

• it moves dots style from the :before element to the parent element, for eiser overriding
• it uses getActiveStyle function introduced in BlockStylesI just copied & past it since I can't reference it directly and it's not exported.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[youknowriad]

Can't the thickness be the same thing for all style variations (same as dot size), why specific options for each style variation?

[senadir]

@youknowriad I interpreted as that they don't scale in the same way (a 20px line is too wide, and 2px circle is barely visible if not). and because conditional option was required when we want to adjust the spacing since spacing doesn't make sense in line.

I could argue against myself here and say that we can use spacing & size as one value and it would make sense.

I can refactor them to use the same option, this should, in theory, reduce a lot of redundant code, but the scaling thing will still persist, but I don't believe it's that of a big a deal.

what's your call Riad?

[youknowriad]

I don't like having specific options per style variations. Like their name suggest, style variations are CSS classes that changes the design but shouldn't affect the behavior.

I'd love thoughts from others @mtias @kjellr @jasmussen @mapk

[senadir]

it's mostly a fundamental problem in how the dots style & line style are built, while most other blocks styles change in a small way, the way they're built is the same.
but for the separator, it's just a cosmetic block, and the dots style variation, doesn't change change style only but also introduce a new element via the :before, it's still an element that is styled and targeted in a different way, so I feel it's really hard to keep it consistent with the general vision of styles.

I feel like I'm missing something maybe, I would love any thought on this one

[jasmussen]

I really appreciate this work, and the demo is impressive.

However I think the way we add these features should be generic to the separator block, and not any of the individual styles. As Riad alludes to, any theme can redesign the separator to be completely different, and are likely to, and if they go further they can even redesign each variation.

There are some efforts underway on a dedicated "Shape Divider" block here: #16351, which add somewhat similar features, but in a way that is less likely to be completely coopted by a theme. Do you think the efforts here are better applied there?

[senadir]

Do you think the efforts here are better applied there?

I'm having a hard time understanding the difference between a Divider block & a Separator Block, why should we limit the separator block while augmenting a new block that is essentially Separator++

I'm not against moving those styles to the Divider, but how will that solve the style inconsistency?

I would love some feedback from @mtias as well, since he's the one that created the issue and has a vision for it.

since you're much more senior than me @jasmussen, I trust that you guide me to the correct way to implement it

[jasmussen]

I'm having a hard time understanding the difference between a Divider block & a Separator Block, why should we limit the separator block while augmenting a new block that is essentially Separator++

This is a good observation, and one that normal users are likely to struggle with also. This is something we should keep top of mind as we continue with the separate Divider block. But there is a semantic difference which reinforces the idea of separate blocks for this. One is essentially an <hr /> tag with optional CSS classes, and can serve an HTML semantic purpose even for users that load a page without a stylesheet for accessibility purposes. The other — the divider — is purely decorative, which carries with it its own accessibility best practices.

I can see some of the confusion alleviated by a user browsing the block library and seeing previews for both the separator and the divider, and picking the parent style based on that. In some future it would be fun to offer pre-built sections that contain multiple blocks pre-configured — this would likely help further.

Thank you for your kind words, and of course, ping me any time and I'll help to the best of my ability. Your contributions are delightful!

[mapk]

Thank you for this wonderful work!

I'd agree that having separate settings for separate style variations is getting a bit too meta for me. I love the explorations and I think they've helped me realize that in relation to the Shape Divider PR, we may want to limit settings here in the Separator.

I like the settings that allow me to change all the style variations at once, like the color settings. Anything beyond that feels like plugin territory.

[BinaryMoon]

I feel the same here that I felt on the width setting (#16925 (comment)) - I think this would be better as a global setting rather than a per block setting.

I also worry that all of these settings will make theming blocks more difficult since we will need to override/ accommodate these custom things, which could be hard or involve adding many !importants.

[senadir]

@BinaryMoon I always felt that themes should respect the choices made in the editor, not vice versa, theme should provide a default, backup option, but the final visual design should be up to the author, this is just my way of thinking, not Gutenberg way of thinking as far as I know, I guess this could stay open until there is a consistent feedback into how should I shape this (mostly divider) but yeah, I totally convinced that a seperator shouldn't need those things.
as for global settings, there isn't any of them now
I will not merge this PR until further notice

[BinaryMoon]

@senadir

I always felt that themes should respect the choices made in the editor

I agree, but I don't think the editor should have too many choices. I like the WordPress philosophy of 'Decisions, not options'. You choose a theme because you like the design so overriding the design and breaking the carefully considered aesthetics doesn't sit well with me.

as for global settings, there isn't any of them now

I know, but I've seen them mentioned a few times recently, which suggests to me they will be coming.

Either way, I'm just expressing my thoughts/ voicing my concerns :)

[senadir]

@BinaryMoon Absolutely I agree with that philosophy, as for global settings, no one is working on it as far as I know, there has a been a lot of talk, I'm doing a lot of research into it, but since there is no consist way yet to to implement it, it's on hold, the idea is there since the first day of gutenberg, read here #1224

[ChemicalSailor]

This is a good observation, and one that normal users are likely to struggle with also. This is something we should keep top of mind as we continue with the separate Divider block. But there is a semantic difference which reinforces the idea of separate blocks for this.

I think that "normal" users will struggle knowing that there is a semantic difference between separator and divider blocks. Presenting two different blocks that appear to do nearly the same thing is only going to increase confusion.

What about if the separator block is deprecated in favour of the shape divider block (possibly keeping the separator name) and a boolean setting is added for inserting the <hr />. I think this would help to expose the semantics in a nicer way to those who don't know any better.

[jasmussen]

I think that "normal" users will struggle knowing that there is a semantic difference between separator and divider blocks. Presenting two different blocks that appear to do nearly the same thing is only going to increase confusion.

Worth mentioning that there hasn't been any actual testing done here, so we are simply sharing personal opinions on what might work the best.

In this case, I hear you, but there are some benefits to having highly differentiated blocks that, while they can solve the same problem, can also solve different problems. In the case of the separator, it feels to me like a very basic typographical tool to most literally separate sections of content. Additionally, it is an element (hr) that many themes have already styled quite delicately, which means adding additional features to it should be done both deliberately and carefully. By being just that element, it also suggests what type of style variations the block can come with — which is quite a bit: anything you can attach to before or after. But probably not SVG separators, or waves that can be uniquely positioned, resized, recolored. Heck, even animation.

If the goal of the editor is to enable rich layouts for anyone, without having to learn how to code, then you have to have a variety of blocks. If we focus only on the semantics of a separator for classic text, there's an opportunity cost in ideas not explored. Whereas if we open up the landscape to enable the user to explore more blocks, even some that overlap, it can enable creativity without necessarily making the life harder for themers: because it is a new block. For example you could imagine an animated wave in a Divider block, that was even resizable:

Here's another take from theoutline.com, where it coexists with additional versions:

The above is not proof that we have to have a separate block. I share it only to expand on what we could do with a dedicated Divider block, things that would likely give theme developers major headaches if they were wedged into the existing hr tag.

Finally, a change has just been merged to the editor, which provides a preview for every block:

This preview hopefully can help implicitly inform why you might want to use one separator, vs. the other.

[ChemicalSailor]

@jasmussen Thanks for the additional insight. I'm definitely a fan of the shape divider and agree there are separate use cases. I'm just trying to reinforce the sentiment, based on working with non-technical users, that some people will find it hard to know what the difference is. With a two block approach, as you said, we need to make it highly differentiated; I'd say we need to make it super-duper abundantly clear why you'd use one and not the other.

But I also wonder, if I used the shape divider because I wanted the extra visual stuff, how would I also indicate the separation of content semantically at the same point if required. A separator block nested in the divider block would do the trick, but then I'd probably need a visually hidden hr as a style.

[jasmussen]

But I also wonder, if I used the shape divider because I wanted the extra visual stuff, how would I also indicate the separation of content semantically at the same point if required. A separator block nested in the divider block would do the trick, but then I'd probably need a visually hidden hr as a style.

That's another good point to keep in mind.

It would also be nice if there was a transformation from the separator to the divider and back.