Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add documentation about floats, and possibly expand method #9189
This branch was started with the intent of porting the float improvements we recently made to images, to other blocks that can be floated, such as Cover Image, Gallery and Embeds.
However as I started doing that, I noticed a lot of different hard-to-genericize aspects of those other blocks. For example, Gallery, Cover Image do not have intrinsic widths, so we have to apply a width to them when they are floated.
For many embeds this is the same, some are resized to their minimum dimensions, such as a tweet that's embedded. Videos are respnosive, however, and rely on an aspect ratio to scale a percentage, so even if they might have an intrinsic width (like 1920px for HD) we scale that down based on the aspect ratio. Which means we have to treat those as if they do not have intrinsic widths either.
Mostly the big change is that the new floats require an extra wrapping div in order to work. I.e.
It doesn't have to be a figure, and the
But if we are to use the same float technique, regardless of intrinsic widths, I have to add an additional containing element when the block is floated. Right now this is done for the image: https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/image/index.js#L227
However if the "floats" should be truly generic and work for any block that opts into the float mechanic, we can't implement that wrapping element on a per-block basis.
What are your thoughts on how to generically add this wrapping element for all floated blocks?
Also this PR does two other things:
You are SO FAST HOLY GUACAMOLE!
It's clearly not ready for review. But I would like your opinion on it. I seem to recall in the past that you asked me to flag you for review rather than at mention you in comments because those had a tendency to be lost? I'd be totally fine with un-requesting you for reviews if that's better :D
Great to see this being discussed! I thought things are set in stone in terms of block HTML by now…
I think Pullquote is another one to be added to the list.
This is fine with me. I think there is no other way around. Themes can always tweak those floated widths with their CSS too.
But why not modifying the markup of the extra wrapping div by additional
<div class="wp-block-image align-wrap align-wrap-left"> <figure class="alignleft"> <img src="..." alt="" width="200px"> <figcaption>Short image caption.</figcaption> </figure> </div>
That way we would be able to target the wrapping div with the CSS if we (or theme) need to do so for whatever reason.
Alignment class on parent wrapper?
I think we should leave the actual alignment class (such as
The reason for this would be that if a theme styles alignment classes generically, and then some of the blocks break the expected alignment class application by adding it on a parent wrapper, the theme would need to provide also styles like
Leaving the align class applied on an element that should actually float prevents this issue and the theme can simply style
Besides, here comes the wrapper class advantage as we can simply use
That's my 2 cents :)
I made a few tweaks but this makes sense. First pass seems good; feel free to flag me for another review when you think this is ready for another look
@webmandesign Thanks for your thoughts.
We might retire the pullquote, though: #5947
I also think I'd need advice on how to actually proceed with this PR, I don't know that I have the skill to take it that much further. Notably:
Great to see the quotes blocks getting some polish!
If I understand correctly, that's exactly what I would like to avoid. It would produce inconsistent alignment classes styling which wouldn't even be 3rd-party-blocks-proof.
Using the image example, I would like to have this:
<div class="align-wrap align-wrap-left"> <figure class="alignleft"> ...
<div class="alignleft"> <figure> ...
(Note that I've omit the
At this point, in order to ship this documentation along with the new markup in 3.7, I'm tempted to shelve (and open for separate pull requests) the idea of expanding this markup beyond images. I'd still like to see it, but given other things on my plate I don't think I personally have the bandwidth to make this happen.
One question about a comment, but feel free to tweak that and