-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Block: Image #310
Comments
About the Image Alignment, we had a discussion with @jasmussen and it looks like these alignments could be relevant to all blocks (float alignment), Should we consider adding them in a global way or a block should add them explicitly? Edit: I also think the image can have a |
@youknowriad This was one of the thoughts with |
I imagine we would have generalized controls, but a block needs to opt in specifically, because alignment can mean text-align, floating, or some flex-magic for other blocks. |
Can you use a different term for "full bleed"? As a user, I have no idea what that is. It doesn't sound like a type of alignment. |
"Full-width"? |
Is that what "full bleed" is? How is a width an alignment? Kind of like "justify" is with text? |
Basically. |
I say that's not alignment. I would leave out that "option" entirely from core. Let plugins add it if they want. The existing alignments cover the bases: none, left, right, center. |
I think the "Alignment" name here is probably not suited because it creates ambiguity with text alignment. The "Alignment" attributes here refer to block "positioning" instead of "alignment". To get a sense of what these buttons do, you can try on one of the prototypes (here for example https://wordpress.github.io/gutenberg/tinymce-per-block/) And I think these are really important to have to compose the different blocks together. I think they can be added automatically to all blocks. Even Text blocks can be "floated" or "positioned" left/right etc... |
Specifically here, on the image block, is what I'm talking about. "Alignment" is perfectly suited and is already used in core for images. What is not suited is the extra one that isn't really alignment. It's more like "size". And it wouldn't really apply to other types of blocks. Images(videos) are the only thing that is really a monolithic block where the full-bleed would apply. Simpler blocks have formatted text where text alignment comes into play, but full-bleed does not make sense for the simple block. And the same goes for the more complicated blocks like a map or gallery. The left, right, center would apply to the block, but full-bleed makes no sense for a block with multiple parts to it. |
I think we may be over emphasizing on labels, which we can change right up until the last minute, as unless you use a screen reader or rest your cursor upon the button, you won't see the label at all. What we have to work with here — and yes these labels and terms are open to suggestion — are block level layout alignments and text alignments. For text, left, center, right are alignments you'll use on paragraphs. For images, left, center, right are alignments WordPress supports currently, and these are very different from text alignments as left and right lets text float around it. The key difference is they can be additive: you could theoretically right align text inside a box that was floated left, not that we'd surface buttons for these. But a full-width button (agree, full-bleed is a anachronistic print term that doesn't fit here) to let you make images, video, galleries, maps, embeds, custom fields, could all benefit from new layout features that haven't existed in WordPress to date.
Agree, there are many blocks for which full-width (née full-bleed) makes no sense. We've discussed blocks and what features they should have also in #16. |
I removed the "alignment" label, it's inconsequential since we don't show it. |
Well, not really. I asked about the label used so I could understand what we were talking about. I thought this was about what attributes go on what blocks as well as what controls show up for those blocks. To that end, I still think you need Clear to round out the alignment set. And Clear would be additive to Left, Right, Center. And image width attribute is missing on this block (images). I still think that max-width is not appropriate in the same control box as alignment is. It belongs in a higher level "layout" context that takes window size into account, so while it would be related to the block, it is really the default value for blocks, and not something that needs to be stored as an attribute. Your prototype is deceiving because you limit the width and then let it be the default when you click the button, but that is not how it would be on the front end. Discussing this detail brings up the point that even Left, Right alignment could benefit from being conditional, meaning that Right alignment for big windows and None for small windows is a common pattern. What I would like to avoid is micro-management. This is not desktop publishing. It is the web. The browser is really good at presentation if you don't give it too many instructions. Users notoriously design for one size and don't think about the rest. That is the theme's job. I am in favor of having fewer controls, rather than more, for the simple reason that users will overuse them. And that's why I advocate that core limits what it supplies in the editor. Let plugins add the fancy blocks, and let the themes do the "layout". Just do the basics well.
And why leave out justify for text? (even though it's not that great to use) Actually, justify can be a really good way to align inline-blocks, like for a gallery, so it's not just about text. But that should be up to the theme, and not the user. In my mind, that brings up the fact that images are actually inline elements by default, so text alignment applies (and affects how the alt text is shown). |
We should expect to do many tweaks as we enter the plugin phase and get a feel for how users will use it.
This is a past decision that this project should not overturn without good reason. |
Can you clarify the two markup variants, i.e. with and without |
@aduth I'd like to highlight concurrent work being done on the core Image Widget, which is nearing merge into PHP: https://github.com/xwp/wp-core-media-widgets/blob/master/wp-includes/widgets/class-wp-widget-image.php You'll note that the widget is able to represent all of the properties that the media library returns from the select frame and the image details frame. The naming of the properties has undergone some normalization for storage in the widget instance, so I want to make sure that we are in |
@westonruter Very relevant given #379, thanks for the pointer! I agree it's sensible to keep property names consistent as much as possible. I'll seek to rename |
I vote for only having |
Attributes
Markup
With caption:
States (see all)
The text was updated successfully, but these errors were encountered: