Add Block: Responsive

[rchipka]

Responsive layout is a challenge that Gutenberg will eventually have to face and ideally the solution is flexible enough that all block types can be made responsive without having to add code to each block.

I think the best way to accomplish this would be to add a "Responsive" block, which you could wrap around anything you want to be responsive (including the entire page/post content).

This would immediately solve the problem of responsive layout across the board and would work on all block types existing now and in the future.

Functional description

The "Responsive" block, when selected, could have a setting in the sidebar to define any number of labelled breakpoints (i.e. mobile, tablet, desktop).

There could also be site-wide defaults for breakpoint settings.

The breakpoint labels would appear as clickable tabs at the top of the Responsive block.

Ideally the tabs would always be visible above the block so that it's easy to quickly switch between breakpoints while editing.

At first, clicking between each breakpoint tab would result in the same content for each tab, but you can edit the content within each tab to change the settings at different breakpoints.

This would allow you to change any block settings/styling you want on any screen size.

So for example, you could have a "Latest Posts" block show 12 posts on desktop in 4 columns, but only show 6 posts on mobile with 2 columns.

Technical description

The responsive block would wrap some other blocks and appear to duplicate the content for each breakpoint tab.

In order for the tabs to stay in sync with the addition/deletion of blocks, the Responsive block wouldn't actually duplicate the child blocks, but would instead save any attribute changes to a modified block inside a responsive attribute.

So the block attributes for the "Latest Posts" block might be:

{
  posts_to_show: 10,
  columns: 4,
  responsive: {
    mobile: {
      posts_to_show: 6,
      columns: 4,
    }
  }
}

Switching between the breakpoint tabs would simply refresh the child blocks with the corresponding attributes.

When saving, the Responsive block would render the child content inside of a wrapping <div> for each breakpoint.

So, if we have 3 breakpoints, we would get 3 copies of the child content, each wrapped in a div that can be media-queried via CSS.

Finally, on the front end, a CSS media query would display: block or display: none the appropriate Responsive block container <div> based on the screen size.

Benefits

• Works with existing and future blocks/block configurations
• Easily and intuitively handles complex layout changes across screen sizes
• Not limited to layout-specific settings (can switch between any attribute or content)

Limitations

• Difficult to use CSS transition: upon changing media queries
• Blocks removed from a single (non-originating) breakpoint view would instead need to be hidden/closed (and ideally toggleable)
• Blocks added to a single breakpoint view would need to be added to other (non-originating) breakpoint views, but be hidden/closed

[ZebulanStanphill]

Interesting! I was wondering how something like a CSS-Grid-based Layout block (see #5351 (comment)) would handle responsive layouts, and I thought a dropdown selection in the block toolbar would be the simplest solution. But having a whole container block for responsive design? Now that is clever! I can see this being a much nicer and much more flexible solution than what I was thinking, as it allows for responsive design settings for not just layouts, but any block.

One thing I would add is that there should be a tab to show the default breakpoint, AKA the one that would be shown if you were on the front-end, so if you resized your browser window, the shown breakpoint would change automatically like it would on the front-end. And speaking of tabs, I don't think that would scale very well compared to a selection dropdown, unless you use an ellipsis menu.

Also, I think the whole responsive design setting thing may be something that should exist outside of any particular block entirely, and be a standard part of most settings in the inspector. Take a look at how Divi handles changing settings depending on the breakpoint, but add in the ability to have custom breakpoints like you are proposing.
https://www.elegantthemes.com/blog/wp-content/uploads/2017/03/change-header-responsive.gif

I think handling responsive design in a way similar to Divi may be the best way to do it, though your block idea is definitely pretty good too, and definitely better than what I initially had in mind.

[rchipka]

@SuperGeniusZeb I agree, a dropdown would be a much better solution than tabs.

I agree with your point that the responsive settings should be a global block setting, but I think having a Responsive block achieves the same thing without cluttering the settings panel.

One thing that I do think should be global settings on every block (in the settings panel) are user defined CSS properties, since they're configured more often than responsive settings.

[karmatosed]

Hi @rchipka I have to say I catch myself in reading this thinking all our blocks need to adapt to different screen sizes. Having just one block do this feels like a step backwards to me. In saying this I absolutely understand things aren't that simple and the adaption right now isn't perfect.

It's interesting you mention breakpoints, I can absolutely see a break point functionality something that either a plugin or phase two may explore with Customization. That's the next phase of Gutenberg after the editor. In saying this I'd caution against having this just on one block. We do have the nesting block, perhaps an argument therefore could be made to adding breakpoints to that. I think we could argue a case in a plugin prototype for a few blocks to have that. I haven't explored this visually but my initial instinct is this could be in settings over tabs.

For now, I am going to labels this a question to continue the discussion.

[rchipka]

@karmatosed Ideally all blocks are responsive in their own way by default, but for each block to implement its own responsiveness configuration mechanism could get messy.

The benefit of a Responsive block is that it would allow the content creator to specify exactly how the view is augmented across different screen sizes for any block.

[ZebulanStanphill]

@rchipka Personally, I think a UI similar to what Divi does would allow for granular control over changing properties based on responsive breakpoints, without cluttering the UI. See this GIF:
https://www.elegantthemes.com/blog/wp-content/uploads/2017/03/change-header-responsive.gif

Additionally, I think having a dropdown in the top bar of the editor to change the width of the editor to match any given breakpoint would be useful. It could be implemented similar to how Divi does it in its Visual Builder.

In the Divi Visual Builder, selecting a breakpoint shrinks the width of the displayed page to match the breakpoint. If your browser window is thinner than the width of one of those breakpoints, that breakpoint will not be available to switch to.

Here is a video of me demonstrating this behavior:
https://supergeniuszeb.com/wp-content/uploads/2018/05/Divi-Visual-Builder-responsive-breakpoint-switcher-demonstration.webm

[rchipka]

@SuperGeniusZeb I like the concept of the viewport size to match the breakpoint, but Gutenberg would need to be a more literal representation of the page in order for that to make sense.

Currently, nested blocks have too much padding and blocks in general aren't guaranteed, required, or even recommended to look anything like the front-end while editing.

This means that the viewport could just be resizing to show a smaller version of something that potentially doesn't remotely represent the appearance on the front-end.

I think it's a cool concept and I wish that Gutenberg was a more literal page representation, but it's not quite there yet.

As far as the inline responsive settings shown in the GIF, I find that to be a counter-intuitive workflow.

Especially if the viewport size were a means of setting breakpoint settings. The inline settings wouldn't be necessary at that point.

Here are the reasons I don't think a per-setting inline breakpoint control is a good idea:

We'd have to wrap the actual attribute controllers

That, or every control that should be responsive would have to be programmed in manually, which would suck.

Right now, it's easy to wrap a block and get/modify child attributes, but we have no way to associate the attribute to the actual control and if we did we'd risk breaking the controller by attempting to auto-wrap it with a responsive config option.

There'd be no obvious UI for breakpoint config on non-sidebar settings

So we'd have no way to easily mess around with content or settings within the actual block div on a particular breakpoint.

That, or there'd be two ways to adjust breakpoint settings at any given time, which will cause confusion and bugs.

It's extra clicking

When you want to adjust the view for a different screen size, you probably want to configure more than one setting, which means clicking into each setting and configuring it for the desired view.

It's easier to just put the Responsive block into the breakpoint context you're interested in and then adjust any settings/content you want.

It'd also be harder to visualize exactly what the breakpoint setting value should be, since the view could be reflecting a breakpoint other than the one you're currently editing.

It's harder to find

This makes it difficult to discover and makes issues less apparent when something goes wrong.

[ZebulanStanphill]

Divi has just announced that they are adding the ability to set styles for when you hover over something, and judging by the look of the UI, it can be used in tandem with the responsive toggle to set the default and hover styles individually for each breakpoint. Regardless of how responsive settings are implemented in Gutenberg, I think hover settings should be included as part of the same system or a related one.

https://www.elegantthemes.com/blog/theme-sneak-peeks/divi-feature-sneak-peek-hover-options

[hansschuijff]

Great discussion. I was wondering if and how Gutenberg would go along adding responsiveness. The wrapper-block idea seems a clever idea to add that functionality, although I still find it a bit difficult to see how it would work out on a content-editor perspective. If I may, I want to add my thoughts on this subject to the discussion, even though I'm just a site owner and not a dev on this project.

In my experience not all persons that edit content will be technical wizards (to say it mildly), so whatever the implementation is of responsiveness, it should be very accessible and dummy proof. The problem with wrapper blocks (as I imagine it), could be that it is something an editor (user of gutenberg's editor) would have to know and find important enough to search for, rather then stumble upon it automatically.

That might also be the reason why we tend to use theme's to automate that sort of things instead of giving much controls to all kind of users. Largely, in my head it is not as much a technical challenge (although it is), as a user/people guiding challenge.

When normal blocks just enable one to set font-sizes and such on a block-level and do not trigger the user to set responsive-variants of settings, they will perhaps not even think of (or look for) that responsive variations. And even when they do, the next question will be if they will think to test those settings when the WYSIWYG editor only displays the full screen-size version of their setting. So perhaps even in Gutenberg it is needed that they can prototype/test their settings like in customizer.

Whatever implementation of whatever solution is chosen, my wish and suggestion would be to have it "guide" the user through this aspect in a way he or she can't forget to think of it. Having it depend on training alone, might not be enough.

Responsiveness (at a least) must be build in the blocks in a way that is either always visible (and as such likely to get attention) or in some way likely of being stumbled upon. Since content editors (the people) are likely to be not developers of theme's and systems, that comes mostly with some challenges for the developers, to make them behave in ways that are likely to result in the best output.

One related basic necessity of-course is to allow theme's and plugins to limit Gutenberg (blocks) in a way that forces content editors to use the settings of the theme rather than allowing users to deviate form that settings (not all flexibility is always good). In that way the theme can handle all responsiveness and the user doesn't have to think of it.

But if Gutenbergs editor allows users to scale images at will and set font-size and other commonly responsiveness-related settings (visibility and such too), then it should implement responsiveness in a way that they will do that knowingly and with knowledge of how their editing will impact the end-users front-end experience.

A wrapper-responsiveness block might be a good idea, but it might also mean the html-output is much larger and there might be potential risks for duplicate content markers in seo if blocks are multiplied in the html for this reason. Seo and speed are the other important subjects for commercial websites, like you already know. I'm not sure how Gutenberg will impact both, but am interested to learn.

Thank you all for the great work! This are my few cents to the discussion. Hope I have made some sense.

[rchipka]

@hansschuijff I think that novice users should figure out why they need the responsive block before messing around with responsive settings anyways.

The responsive controls could be more discoverable, but I think that will actually complicate things more.

In my opinion, responsive settings are inherently going to complicate things and maybe it's best if those settings have to be sought after instead of discovered.

A responsive block would separate complex functionality so that a user who isn't concerned with mobile responsiveness isn't burdened with extra settings.

Good point about the content size and SEO concerns.

Not much can be done about the content size, but honestly I don't think an extra few hundred or even thousand lines of HTML output is a big concern these days, especially considering WordPress HTML isn't exactly concise by default.

As far as SEO, worst case scenario we could have the alternate view content be encoded then decoded and reinjected via javascript. I guess it depends on how big of a concern this actually is.

[hansschuijff]

@rchipka Thanks for your thoughts on the matter. I agree that responsiveness complicates things somewhat, or even a lot. And users tend to complicate that even further and make one have to choose between lean tech or userfriendlyness all the time.

That only means making usage- and user-related choices in how it is implemented and that means having an image about what the user is likely capable of and how likely he or she will screw things up. Also it means choosing which audience to cater for and which not. Not all WP-users are techies. I'm sure the community will find a common ground in that.

Probably the size of the html won't be of great impact, at least not compared to other media and the growing amount of js-scripts. With devs, site-owners and users focused on content being found and delivering with ever growing speed, both aspects should be a serious part in the choices made from the start, especially given the large amount of websites that are build on WP.

These days it seems that mobile phones are the main usage case of websites (at least the websites I know of with structurally 70% of visitors coming from smartphones) and keeping the page delivered lean and fast is of concern of many in the field. Not for nothing, Google and framework builders are pushing their pwa-functionality and other ways to speed up page delivery. Developing for such a large market, comes with great challenges like that.

Having said that, I'm quite impressed with what is already there in Gutenberg, and imagine there will be great solutions for this aspect too. Popular Page Builders like Divi and Beaver Builder have already paved that path, so there are accepted examples in the market to learn from.

[karmatosed]

As we are exploring responsive in the blocks that need this lets close. For reference #6048.

[chrisvanpatten]

Agreed with @karmatosed that managing this per-block is probably a much more effective way to go.

Not much can be done about the content size, but honestly I don't think an extra few hundred or even thousand lines of HTML output is a big concern these days, especially considering WordPress HTML isn't exactly concise by default.

As far as SEO, worst case scenario we could have the alternate view content be encoded then decoded and reinjected via javascript. I guess it depends on how big of a concern this actually is.

To me this is the major reason why this isn't viable. Most of the point of responsive design is that you have one common set of markup that seamlessly adapts based on conditions in the browser (width is a big one, but height, screen type, DPI, etc. are also all viable conditions). If you start duplicating the markup, you might as well go back to the days of separate mobile websites entirely. It's also a lot to ask content producers to manage 3 to 5 versions of their content.

I think letting blocks determine for themselves how they treat responsiveness is much better — it allows blocks to provide their own smart defaults, and gives theme developers more control over what responsiveness means for their particularly theme.

[johnzenaida]

The way I got around wrapping blocks is using post snippets plugin and create a shortcode with the opening wrapper div and another shortcode for the closing div around the blocks I want to group. That way the editor won't mess with the code or throw an error.

[sinanisler]

related to this issue lets continue here
#55619