Autoscaling/sizing Block previews

[jasmussen]

This PR is a work in progress. It starts work on improving the preview component to be way more useful. GIF:

The key thing that makes this work, is to calculate what the scale value should be, and the way to calculate that is relatively trivial.

In fact, the component itself can be reauthored to receive a source width and a source height attribute, and it will take care of itself.

For example, if you want a landscape preview, you could do this:

<BlockPreviewContent srcWidth={ 400 } srcHeight={ 300 } ... />

and we could create JS to fill in the blanks. Specifically that math is outlined here:

https://github.com/WordPress/gutenberg/compare/try/better-previews?expand=1#diff-15792e4bd87a6bedb42355c3fd500733R67

Imagine the block you're previewing is an SVG. It has to have an explicit width and height, and then it can be scaled down perfectly according to the intrinsic aspect ratio that creates. In the code shown above, we use a 4:3 landscape aspect ratio, so the block is rendered at 400x300.

The next step is to calculate the scale value based on where the thumbnail will be shown. Right now the style variation previews are 124px wide, so the math looks like this:

Math.min( 124 / 400 ), which comes to 0.31. And sure enough, when we apply transform: scale(0.31) the preview looks perfect:

The only missing piece here is that the container needs some responsive magic as well. It's here:
https://github.com/WordPress/gutenberg/compare/try/better-previews?expand=1#diff-15792e4bd87a6bedb42355c3fd500733R41

The height is 0, but a padding-top: 75% is applied. This padding provides the aspect ratio of the div to scale as a responsive container (see also this for more details). Where does that value come from? Simple: srcHeight / srcWidth * 100. So for our case, it's 300 / 400 * 100 = 75.

So for example if you wanted a portrait 9:16 preview thumbnail, you might provide these dimensions:

<BlockPreviewContent srcWidth={ 450 } srcHeight={ 800 } ... />

This would provide a padding value of 177%. And if shown as a 200px wide thumbnail, the scale factor would be 0.25.

@youknowriad does the above make sense? If you have time feel free to take a look at the PR. Otherwise I'll explore improving the component as my next step. Right now the most difficult piece for me is that the padding-top has to be applied to the container of the preview, and the dimensions and scale factor has to be applied to the child of the container. So I might end up creating additional markup inside the preview component to make this happen.

Terminology

The following screenshots helps to disambiguate some of the terms used to identify the different types of preview.

To Demo

Show Quote style before and after (big padding and large typography makes it overflow now)

Todo

• Test @jorgefilipecosta e2e test fix and implement here
• Get more input on Unit tests and fix
• Review Riad's comment about buttons and fix as required

[senadir]

@jasmussen I'm working on an unreleased PR that handles some bugs in the preview scrolling or panel on general (see issue #16028), those styles will affect the overall structure of the element (a new div has to be created) also I'm switching the alignment of preview panel from absolute to using flex on the parent, I will try to test your changes with mine later this day and see how we can incorporate them both

[jasmussen]

Worth noting that next steps for this PR likely includes adding an additional wrapper regardless, because we need 1 outer wrapper for container aspect ratio padding, and an inner wrapper that holds the content and is scaled down. So that might be fine.

[jasmussen]

Alright, I've pushed a fair bit of polish to the component. The PR is now 95% complete.

What's happened:

• The CSS has been moved to the appropriate places, i.e. to the preview compoment rather than the block switcher where it was before.
• Lots of comments, lots of code cleanup.
• New variables for srcWidth and srcHeight that can be passed to the compoment — these are the dimensions at which the item to preview would be rendered at 100% size.
• A new destWidth variable, which indicates the dimensions of the size the thumbnail should be shown at. I'll get back to this in a minute.
• The scale factor necessary to scale down the thumbnail perfectly based on its source dimensions and destination dimensions.

It works pretty well:

The missing piece here is to refactor away the destWidth variable. It is necessary in order to calculate the transform factor necessary to scale the thumbnail correctly. Rigth now it is hardcoded, but it would be really nice if we could calculate this, since we're already in the JS doing things.

[jasmussen]

I tried applying your patch, but must've mangled it somehow, so I wasn't able to verify whether it worked as it should. Would definitely appreciate some code help. @gziolo my favorite :D do you have time for some feedback there?

[mtias]

Thanks for looking at these. They are a central piece for the experience.

[jasmussen]

Alright friends, I think this is ready for review!

The code that was added by @getdave (thank you and props) works great. I added a few tweaks, some cleanup, and a stub README. As it stands, this now works well.

Remaining tasks are:

• Code review
• Figure out why the tests fail
• I could use help with the README

[jasmussen]

Here's a little GIF as a tease:

[getdave]

@jasmussen I'm struggling with how best to manually test this in browser. Might sound silly but do you have a nice workflow to test?

[jasmussen]

For now I've simply just verified that every piece of the editor that uses this component looks right. That is, open the block library and hover over a reusable block, or open the switcher or styles panel for a block that has variations, such as Quote or Button.

[mtias]

Can we address the pending comments and get this in?

[retrofox]

@retrofox Ok - thanks for experimenting here. Is this based on any further information from @mtias as to why that would be a good idea?\

No, any extra information from Matias. What I did were learning and experimenting with shadow DOM for a short time since I hadn't clue how it works. After reading and playing with this, conclude that although it could be a very powerful resource to handle components previsualization it's clearly out of the scope of this approach.

I'm unclear as to why that would be desirable. We want to display the styles that come with the Block.

Being able to apply global and specific styles in a solid way to components.

The idea behind using this approach is selecting specific styles to visualize each component. Generally, need to use global styles for all components (current one), but sometimes it could be useful to isolate specific styles for each component. Shadow DOM handles this case in an extremely safe way.

Sorry by my mistake to not being 100% clear about experimenting around the shadow dom. Next time I'll create another branch.

[obenland]

Seems like there is a unit test failing currently:

FAIL packages/block-editor/src/components/block-preview/test/index.js (14.755s)
  ● BlockPreviewContent › renders a preview with suitable default dimensions

    Method “props” is meant to be run on 1 node. 0 found instead.
      26 | wrapper.update();
      27 |
    > 28 | const previewAspectRatioStyle = wrapper.find( '.editor-block-preview__container' ).first().prop( 'style' );
         | 		                                                                                           ^
      29 | const previewTransform = wrapper.find( '.editor-block-preview__content' ).first().prop( 'style' ).transform;
      30 | const previewScale = parseInt( previewTransform.match( /\d/ )[ 0 ], 10 );
      31 | 

[getdave]

The direction of this has pivotted and is now running over at #16873

[obenland]

Closing in favor of #16873.