Gutenberg: Image block wrapper div breaks alignments

Created on 21 Sep 2018  路  6Comments  路  Source: WordPress/gutenberg

Describe the bug
Since the markup structure of the image block has been changed to

<div class="wp-block-image>
  <figure class="alignmentclass">
    <img src="http://..." >
  </figure>
</div>

in a recent release, float-based alignments no longer work properly.

example of broken image alignment

Because the alignments are placed on a child element, the parent is unaware of the float, and has no context for where it belongs.

This markup change also causes issues with custom classes because scoping has changed now that there is an extra element between the parent block and the image itself.

To Reproduce

  1. Create a post or page.
  2. Add an image block and left or right align it.
  3. Add some arbitrary text
  4. Publish or preview the post (it will look fine in the editor, but goes awry in the published post).

Expected behavior
Preferably, dump the wrapping extra wrapping div. It's bloat that doesn't need to be there. If dumping the div isn't an option, add alignment classes to the parent div.wp-block-image.

Screenshots
See above.

Additional context

  • Gutenberg 3.8
[Feature] Blocks [Type] Bug

All 6 comments

cc @jasmussen

Thank you for the ticket @carrieforde!

The reason we have the wrapping div is, ironically, to give themers and developers more control, rather than less. The details are in this doc: https://github.com/WordPress/gutenberg/blob/master/docs/extensibility/theme-support.md#wide-alignments-and-floats, but the short of it is that with the new figure & figcaption based markup and the addition of wide image support, the extra wrapping div can be helpful in achieving a responsive layout that supports all of the above.

However we obviously need to address the issue at hand, so I have assigned myself this, and have a few ideas for how to address it, the plan B being to assign the alignment class to the div itself, as you suggest.

However first I'd like to understand why the layout isn't working. I can obviously see it in the screenshot, but I can't reproduce it myself. Here's a Codepen I wrote, to try and replicate the issue: https://codepen.io/joen/pen/ePBEOM?editors=1100

As you can see from that codepen, the markup is the same, with an aligned figure inside a div that collapses. So I'm wondering which additional steps I need to take in order to replicate the issue you're seeing.

Because the alignments are placed on a child element, the parent is unaware of the float, and has no context for where it belongs.

I understand this, but at the same time this should cause the additional div to collapse to zero height, and be invisible on the page. It shouldn't cause the layout issue you're seeing.

In #10394, I created a potential fix for this issue. Depending on the full context, what it does is as suggested, to move the classnames to the div instead of the figure.

Hi @jasmussen, thanks for looking into this. I realized for one of the instances that this was causing issues, it was my fault because I was flexing the parent container. So the instead of collapsing as expected, the div actually stretched or maintained some height. Therefore, total developer error on my part. 馃檴

I think the other issue I had was more related to the "Advanced Settings" custom class getting added to the parent container, rather than the figure itself. Nothing that couldn't be fixed with some rescoping of classes (though I'd personally prefer to just target the class, and not .class figure).

Thanks again for looking into this, and now that I've wrapped my head around it more thoroughly, I'm happy with either keeping the current solution, or trying your new one.

Thanks so much for getting back to me.

I will do some more testing on my PR, hear with a few of the other devs, and go with the solution they recommend. I'll be sure to update this ticket with what we end up with.

Per my comment in https://github.com/WordPress/gutenberg/pull/10394#issuecomment-429018522, I'm going to close this one as _addressed_. Basically we can revisit this if the issue surfaces again, but given the fundamental structure works, I'm wary of making too big changes at this juncture.

Thank you again for the ticket and feedback!

Was this page helpful?
0 / 5 - 0 ratings