Spacer Block Not Responsive, May Lead to Unexpected Results

[mrwweb]

Describe the bug
The Spacer block is quite simple in that it applies a fixed height in pixels set by the editor.

To quickly take a step back, one general problem with WYSIWYG editors is that they encourage editors to overly optimize for the environment they're currently working in. This can lead to unintended consequences of editor decisions, often without the editor's knowledge.

Back to the issue, I think the Spacer likely will lead to unexpected results for editors when using this block on a large screen and not considering small screens. Arguably worse, even if editors want to consider small screens, there's no easy way to do so.

The screenshots below illustrate the issue. On my current monitor with a browser not even filling the entire screen, this spacer filled roughly 40% of the screen height. On an iPhone 7-size screen, it was 55%. It's not that hard to imagine a user making spacers that approach 100% of a smaller phone's screen.

I'm not sure of the best solution for this, but my first instinct would be that the spacer should be calculating a height as percentage of width and then implemented with a pseudo-element in the classic aspect ratio box technique. I'm sure there are other possibilities both for the behavior and implementation.

To Reproduce

1. On a large screen, separate two visible blocks of any type with the largest reasonable spacer block you'd consider.
2. Preview the page.
3. Resize screen to a "phone" size

Expected behavior
Spacer adjusts to be reasonable on and screen size.

Screenshots
If applicable, add screenshots to help explain your problem.

Full Post on large screen

One screen's worth of the post on large screen:

Full Post on Small Screen

One screen's worth of the post on a small screen

[karmatosed]

'If' this can be done without any interface in phase one, I would prefer that. I can see a need once we enter site building to have more granular control but for now having something 'just work' seems like the best step.

[mrwweb]

Completely agreed. In fact I don't think there should be interface. It strikes me as a fairly reasonable assumption that users inserting a spacer are defining the height they want at the current document width, so a ratio-based "just works" solution makes sense.

If users wanted to optimize heights at different breakpoints, I would think that's plugin-territory for a "Show only on [mobile/desktop]" feature (unless/until core added standardized responsive options for blocks).

[chrisvanpatten]

I wonder if there's any way to re-use or extend the CSS used in the responsive video feature? Maybe similarly calculating the aspect ratio on the fly somehow…?

[karmatosed]

Removing the design feedback as we are opting for no interface so it's just a matter of a pull request on this now. I say that knowing 'just' involves some 'fun' maths.

[DancingPigeon]

Isn't the core issue here that using PX as the primary/only unit type is guaranteed to lead to issues related to changing viewport size? Why not allow something based off vh or em?

[mrwweb]

@DancingPigeon That's certainly another way to put it. In trying to think about the ideal "just works" experience, something close to maintaining the aspect ratio of the sizer feels right, though I also think that it might be even better if there were min- and max-heights to "cap" the changes. Something similar is usually done when using vw units for type sizing.

ems wouldn't maintain aspect ratio and only be responsive if the theme resizes typography, but vh units seem like a reasonable path forward. I didn't think the browser support was there, but reviewing that now (IE9+), makes me think that could be an even cleaner solution than the pseudo-element aspect ratio hack.

[DancingPigeon]

I can see arguments for either. Personally, I think dragging by PX is the least valuable way for the 'standard' user to use the current control, and its certainly at odds with the current trend in how white space should be handled with respect to content. I can see an argument for either vh or em, depending of course whether we're talking about space as it relates to typography or viewport. I can see value in either, for different purposes of spacing.

[melchoyce]

Maintaining aspect ratio and scaling down proportionally, IMO, is key. It should feel proportionally like the same amount of space, despite your screen size (though I agree we need a min/max cap).

Pixels are easier to visualize when deciding how large something is — but the actual output should probably be something more flexible, like vh.

[dweidner]

I would love to be able to customize the available spacer-heights, similar to how it is possible with the editor font sizes. For example:

add_theme_support( 'editor-spacer-sizes', [
    [
        'name' => __( 'Small', 'acme' ),
        'size' => 27,
        'slug' => 'small',
    ],
    [
        'name' => __( 'Medium', 'acme' ),
        'size' => 54,
        'slug' => 'regular',
    ],
    [
        'name' => __( 'Large', 'acme' ),
        'size' => 108,
        'slug' => 'large',
    ],
]);
add_theme_support( 'disable-custom-spacer-sizes' );

Resulting in the following markup:

<div class="wp-block-spacer is-large" aria-hidden="true"></div>

[mrwweb]

@dweidner seems like a good suggestion. I'd encourage you to make a separate ticket for that request as the direction of this ticket right now is probably UI-less.

[rafafields]

I would love to be able to customize the available spacer-heights, similar to how it is possible with the editor font sizes. For example:

add_theme_support( 'editor-spacer-sizes', [
    [
        'name' => __( 'Small', 'acme' ),
        'size' => 27,
        'slug' => 'small',
    ],
    [
        'name' => __( 'Medium', 'acme' ),
        'size' => 54,
        'slug' => 'regular',
    ],
    [
        'name' => __( 'Large', 'acme' ),
        'size' => 108,
        'slug' => 'large',
    ],
]);
add_theme_support( 'disable-custom-spacer-sizes' );

Resulting in the following markup:

<div class="wp-block-spacer is-large" aria-hidden="true"></div>

I think we all would love that solution. Until they implement something like that, I have coded a simple vanilla lightweight solution which you can configure with breakpoints. I hope it helps :)

Source -> https://codepen.io/Wondermochi/pen/YbGQdW

Edit: It looks like Gutenberg overwrite my javascript (even when I render it on head omg). Can someone tell why?

Finally I decided to set an !important height value to all spacer blocks which I can control from my css to optimize space in every breakpoint. In case of needen more space, I will add the block twice. Not clean but functional.

[webprom]

At lest using more units options would help a lot, i.e. vw, wh, em, % etc.

[Preen]

Any news on this?

[Mamaduka]

The Spacer block now supports different units for height, not just pixes, so I think we can close this issue. See #36186.

[mrwweb]

I'll just throw out that I think until the default value of the spacer block is changed to a responsive value (5vh?), the usability concerns expressed in this ticket—default usage leads to unresponsive bad results on small screens—are still valid.

[Rockstar907]

Please lock my account that is not me changing it.

…

On Fri, Jan 14, 2565 BE at 7:40 AM Mark Root-Wiley ***@***.***> wrote: I'll just throw out that I think until the default value of the spacer block is changed to a responsive value (5vh?), the usability concerns expressed in this ticket—default usage leads to unresponsive bad results on small screens—are still valid. — Reply to this email directly, view it on GitHub <#10081 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AU6ET4SMH4EHNTHJTZYTDDLUWBGZPANCNFSM4FWL5P3A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jordesign]

I'll just throw out that I think until the default value of the spacer block is changed to a responsive value (5vh?), the usability concerns expressed in this ticket—default usage leads to unresponsive bad results on small screens—are still valid.

@mrwweb - I'm seeing vh values being supported by the spacer block now - does that resolve the kind of thing you're talking about (for now)?

[mrwweb]

@jordesign I would not say that the addition of vh units resolves the problem since px units are still the default.

I think until vh is the default unit or the spacer switches to an aspect-ratio approach, most users are still unlikely to change the default value and will still experience these problems.

[jordesign]

@mrwweb Having that value as the default is likely a much bigger conversation to have - in terms of consistency with other blocks etc. I'll leave this open - but add a label for Design Feedback 👍

[mrwweb]

Having that value as the default is likely a much bigger conversation to have

Totally agree. The original concern with the ticket is that any user that doesn't have a strong grasp of px vs. other units (probably most users) or who isn't thinking about responsiveness (probably most users) and inserts a spacer and drags it to be larger is likely going to create a sub-par experience for their mobile visitors.

I don't think that has changed, so I agree we should leave the ticket open. I'd love design feedback!