Image Block: Add "full width" control option

[aduth]

Related: #310
Related: #416

This pull request seeks to add a new "Full width" option to the image block controls, intended for cases where the image is to break out of any constraining container.

Open questions:

• Label name? There's some heated debate in the original issue.

Testing instructions:

Verify that the full width option can be toggled like other image alignment controls (#416), and that it visually breaks out of the editor container.

Future considerations:

• Currently I'm using an align-center icon, as there's not a Dashicon yet which fits well for the intended action. @jasmussen has committed to incorporating one.
• As a new option, existing themes are unlikely to support this. We'll need to consider some hooks by which a theme can define its support and conditionally show the control.

[BE-Webdesign]

Should we center the image as well?

&[data-align="full"] {
    img {
        margin: 0 auto;
    }
}

Not a huge fan of over nesting selectors but YOLO!

[BE-Webdesign]

The formatting and application of the attribute works 👌, however when the image goes full width on a larger screen it is not centered, like I would expect it to be. Not sure what the expected behavior should be. Other than that, it looks good to me.

Also totally 👍 on data-align=full, I saw somewhere else where it was brought up that full-width was not an alignment. Maybe that is true, but I am pretty sure most people will understand and this works a lot cleaner than having all sorts of names.

[BE-Webdesign]

Any context to this change for this PR?

[aduth]

Any context to this change for this PR?

To preserve the common max-width of 700px across blocks while still allowing blocks to escape out of it, the responsibility of assigning the max width was moved from the listing to the block itself. Without the changes here, the inserter would be shown to the far left of the editor canvas since it's not a true block, but should respect alignment with the rest the blocks (effected with the container).

[BE-Webdesign]

Ah makes perfect sense.

[ellatrix]

What's 90% here?

[BE-Webdesign]

I think it is trying to go full-width but not too full-width. 100% would probably make more sense though.

[aduth]

It was a number pulled out of the air 😄 But yes, specifically it's a value close to 100% while still allowing space for the block mover.

[jasmussen]

Added a new full width icon in #521

align-full-width

[mtias]

Maybe just wide as attribute name?

[aduth]

however when the image goes full width on a larger screen it is not centered, like I would expect it to be.

Good catch on this @BE-Webdesign . I guess there's a question of: Do we want to force the image to take up the full width of the canvas? Its natural width (with margin: 0 auto)? Some arbitrary "expanded" width (like max-width: 900px instead of 700px)?

[BE-Webdesign]

I would say natural width to prevent images from overly distorting. If you want an image to fill up more space, use a bigger image. On super hi res screens, if we go full width of the canvas, images will look really silly compared to the text content. The arbitrary "expanded" might work the best, I would go with 1130px for the max-width for a nice ratio between the two. Whatever works really, I wouldn't over think it too much, the 0 auto at least will guarantee the image is centered setting the width of the image might make more sense though and a theme can change how full width looks for that theme.

[jasmussen]

Good catch on this @BE-Webdesign . I guess there's a question of: Do we want to force the image to take up the full width of the canvas? Its natural width (with margin: 0 auto)? Some arbitrary "expanded" width (like max-width: 900px instead of 700px)?

I meant to respond to this previously, but clearly missed out on this one too.

Full-width, née "full bleed", is close to my heart. I feel strongly that it should be truly full width. Edge to edge. Definitely in the editor, and depending on technical implementations, also in the theme itself.

Try viewing the example post, and scroll down to this image:

That's the look that we're going for with this one. Big and bold. If we are too concerned about it being mega huge, we could add another option which is could be the "wide", but I still think there's a case for going edge to edge.

That being said, there are some technical challenges. The UI prototype used this trick to go edge to edge, despite any max-widths applied to the main content colum:

.align-full-bleed {
    margin-left: calc(50% - 50vw);
    width: 100vw;
}

The problem with that one is that the vw unit does not account for scrollbars, which means any browser that doesn't have fancy mac auto hiding scrollbars will also get a horizontal scrollbar. In my mind that is a blocker for this method of full width images. The example post referenced above explicitly avoids this implementation by not having a max-width on the main column.

This suggests that we may want to leave it up to the theme itself to decide what to do, and simply apply a CSS class to the image.

[aduth]

This suggests that we may want to leave it up to the theme itself to decide what to do, and simply apply a CSS class to the image.

Yeah, I think it really depends on how the theme authors would use this attribute. The class already exists with the changes here, it's just deciding how to display it in the editor. The problem with the prototype version is that there's no way to move the block up and down, hence the 90% here.

[jasmussen]

Yeah, I think it really depends on how the theme authors would use this attribute. The class already exists with the changes here, it's just deciding how to display it in the editor. The problem with the prototype version is that there's no way to move the block up and down, hence the 90% here.

Yep. We had some ideas for this, and I'm still thinking about that. Right at this moment, I think it's okay that you can't move it when full bleed (because the controls are off screen). If you need to move it, you can temporarily pick a different alignment, or move the blocks before and after, or use drag and drop.

However if in practice we find that this is annoying, let's revisit and perhaps we can move the position of the mover for this look.

[aduth]

Rebased to address feedback and incorporate the new icon.

But there's a hiccup now in that floated images no longer respect the block maximum width. Will have to poke at this a while longer to see if there's another way to "escape" the container.

[jasmussen]

I've noted down a few articles on how to escape the container, perhaps worth looking at: https://css-tricks.com/full-width-containers-limited-width-parents/

There was also this one, which I thought was particularly promising: https://css-tricks.com/hassle-free-full-bleed-not/

[aduth]

@jasmussen Thanks for the links. That first one was particularly great in breaking down considerations; for us, the "non-% Parent Width" case. Inevitably this includes the viewport width unit which, as you've mentioned, doesn't account for the presence of the sidebar. I still went down this path in a2d8372, using overflow: hidden; on the editor container to prevent the horizontal scroll. This also means there's likely ~25px of the image clipped when a scrollbar exists. Also, as can be seen in the CSS, managing offsets for varying sidebar collapsed / folded / hidden states is quite cumbersome. Ugly as it is, it should all be accounted for now.

To the other link: The issue is that if we move the burden of managing max-width and centering to the block itself, it becomes equally difficult to come up with a solution for the floated images to be aligned to the invisible left and right barriers of adjacent blocks.

[jasmussen]

To the other link: The issue is that if we move the burden of managing max-width and centering to the block itself, it becomes equally difficult to come up with a solution for the floated images to be aligned to the invisible left and right barriers of adjacent blocks.

Yep, I learned of this in the example post with the left floated quote.

👍

[aduth]

@jasmussen How do you feel about the solution using vw units, since I know you tend to have opinions on its usage 😄

[jasmussen]

@jasmussen How do you feel about the solution using vw units, since I know you tend to have opinions on its usage 😄

Haha yes indeed.

I personally find the unit completely useless as it presumes there are no scrollbars, and especially for Windows users, there are. However I'm also pragmatic enough to swallow that pride when presented with something that works. If it works, and works well, ship it! (And just to be clear, "works" means that there are no horizontal scrollbars, when Mac has them set to always show.)

I'm assuming themes can still choose not to use vw units for the frontend rendering, correct?

[aduth]

I'm assuming themes can still choose not to use vw units for the frontend rendering, correct?

Theme styling in general needs more thought, but it would be my assumption that this would be entirely up to the theme to implement based on the presence of the class, yes.