Add support for device previews

[timelsass]

Is your feature request related to a problem? Please describe.
It would be nice to finally get some device preview support inside of the editor. I would image something similar to the customizer's device preview, with some filters to allow custom sizing for breakpoints to be added by devs. This could also pave way to a standard for allowing viewport based controls in core. In looking at various plugins - and even in core code - the approach has pretty much been all over the place as to how to handle this. Core's Media & Text block is an example of the current flexibility provided for viewport based controls:

There may be documentation about the media & text block and instructions for theme developers to add support for the mobile breakpoint out there, but this seems like something that should encompass more than just one block, and potentially set a standard moving forward for blocks and themes to better provide a fluid experience for users.

Describe the solution you'd like
Ideally I see something like this being useful:

1. Developers can register viewport sizes they wish. Most useful for theme developers who have different breakpoints set in their themes, but I could see plugin developers adding way to interact more in depth with various screensizes as well.

2. Device preview selections available to ALL devices.

3. The ability to zoom in/out on devices that are smaller than registered viewport widths. This would allow for accurate previews to occur for the editor regardless of a user being on a smaller device.

4. Detection of the device previewing the editor (based on viewport width). This would set the initial state when the editor is loaded, so any controls/blocks relying on the viewport sizes can properly display. If core or plugins wanted to set a default state to always a particular viewport on entry - then appropriate resizing/zoom could happen in the initial load of the editor as well. This is something missing from the customizer's device previews.

5. Core implementation to support large, desktop, tablet, and mobile by default - instead of just desktop, tablet, mobile (customizer). Large displays have become more common, and many CSS frameworks hit these four breakpoints, allowing developers implementing them that flexibility - so I would expect core to mirror the common use cases in that sense. It would also be nice to have a new dashicon to better fit interfaces for themes that do provide large viewport support in the customizer, and other places where it's been a common interface element for themes/plugin developers.

6. A uniform approach to controls that allows users to preview and make changes to different viewport sizes. This is a very common problem for WYSIWYG - and often times it's left to a developer to decide what the best fit for the content is based on what they had envisioned since there's no way for a normal user to interact with different viewport sizes easily. Developers, designers, and end users don't always have the same vision for content - and it's very common for an end user to ask after building a website how to hide a particular block/section/column on mobile/tablet/desktop. We should give them this power.

Describe alternatives you've considered
In terms of alternatives - the only alternative I've thought of is to not provide support for device previews, and leave this work to theme developers and/or plugin developers to handle. I don't think this is a very good route because it provides an inconsistent UI for end users when switching between themes/plugins. I also think it's a good indication that if core provided the media & text block, and saw in the initial implementation that they need to provide a "stack on mobile" option - that a better/consistent way of handling device previews needs to be available and implemented.

[jameskoster]

I think your third point is one of the most challenging here, from a design perspective. We're looking into something like this for some WooCommerce blocks we're working on and I keep going in circles on this particular point...

Should it really be possible to preview "desktop" mode when editing on a mobile device? It sounds highly unintuitive, even with zooming.

But you must also consider the idea that certain blocks might have different settings for different devices. As an example our Products blocks will allow authors to configure a layout for their product grids and that will likely vary depending on screen size. So it should still be possible to at least modify desktop-specific settings while editing on a mobile phone. But that is also awkward because you'd be editing settings without a visual preview which goes against what I consider to be a core Gutenberg concept.

I'm curious whether you had any mockups of how desktop preview would look on a mobile device?

[timelsass]

I agree --- I think it can be awkward, but it's also pretty awkward to edit and modify the appearance of content on mobile in general. I do agree with you in saying that this seems like a core Gutenberg concept to be able to visually see what things you are changing, so some way of adding previews seems necessary. I don't have any mockups inside of Gutenberg really, but I did implement something similar in a theme for the customizer to behave in this manner. The main reason was the breakpoint differences between desktop and large for me. Using a laptop at standard screen resolution with the customizer sidebar - often put users in the tablet view for the page, instead of the desktop view which they would typically see when viewing on the frontend without the customizer controls open. We also added some device specific customization options, and it became weird not seeing changes visually when editing those. We would get various bug reports for this because users didn't understand that the changes they made for these controls could only be viewed if they were to resize or view from a larger device.

This is the concept we went with in the customizer:

Basically the four devices at the bottom toggle between the different preview sizes. The screenshot above is viewed from the "mobile" display, but editing the "large" display.

In terms of the UI there - the margin control displayed can be adjusted for each of the viewport sizes. When the user clicks on one of the sizes to edit - it triggers the same zoom out or resize that the buttons at the bottom do, so the user sees what they are changing for the specific viewport while customizing.

We included an "all device" display icon in these controls (seen to the far left in the icons for the margin control ) - so a default can be set and managed which applies to all viewport sizes. Inside of the controls in the popup that's shown in the screenshot, the user can select if it uses the inheritance from all devices, or overrides for the specific device they selected by clicking to link/unlink it.

One downside I see with the zoom out option was the text becomes very hard to read, and images can become slightly distorted. Overall though - this worked out best for us - and no complaints. I implemented an alternative method to resize the iframe to allow scrolling left/right for the various devices sizes, but scroll syncing and resources became an issue as it was a pretty resource intensive implementation. The zooming covered our target browser support, and eliminated the other issues in trying to get the iframe to behave the way we desired and efficiently cross-browser.

[jameskoster]

and it became weird not seeing changes visually when editing those

That's exactly my fear. I've seen existing Gutenberg block plugins employ a similar pattern (desktop / tablet / mobile toggles for specific settings) with the lack of visual preview makes the whole experience feel disjointed.

This is the concept we went with in the customizer

Thanks for sharing this. Initially the duplicated icons confused me, but it makes sense as you explain it.

I'm keen to test the zooming to get a feel for it. Is the theme publicly available at all?

[iandunn]

Related #13203

[youknowriad]

I'm closing this as a duplicate of #19082 which has a bit more discussion. This is being explored here #19082