Open mrwweb opened 4 years ago
Thanks for your perspective @mrwweb. Personally, I am not against having the color options. A cover block could be a block of text with a background color, or an image, there are use cases for both of those. One potential split could be between a 'cover image' and a 'cover text' block, however, it's called cover, so I am not sure we need that split.
@karmatosed I don't quite understand the distinction between a "Cover Image" and "Cover Text" block.
I am trying to operate off how the block is defined in the editor:
If that is right, then the colors and gradients would seem to be for tinting the image, not serving as the primary background.
If that is wrong and the purpose is broader, then the description needs to be updated and gradients should become a first-class background option. Further, if the purpose is broader, it still needs to be constrained sufficiently that there is a meaningful difference with the Group block. Otherwise, what's the point of having both?
My concern is that there is a confusing overlap between the Cover and Group block. Once the Group block gets gradient support, it seems like that will almost certainly be the best way to put color/gradient backgrounds behind one or more text blocks. If users sometimes use Cover blocks and other times use Group blocks for the same purpose, it will be hard for themes to support both.
That all said, I will go back to my initial problem and "alternatives considered": Either the Cover block should feature all background types equally on the initial screen (add gradients) or it should focus the user on media since that is the stated purpose of the block. Any of the in between options seem to muddle the intended usage.
Big picture: I think blocks are really analogous to semantic HTML. Obviously, many of them implement semantic HTML too, but beyond that, we want to help steer users to selecting the most appropriate block for the communication and design purpose. That's important because themes make assumptions around what type of content a block contains and why people want to use each block. If the editor can't clearly communicate those purposes, then there will always be more mismatches between the blocks editors select and the intent of themes.
@mrwweb I think your idea to iterate the description is great. As the block has evolved it doesn't fit that and this feels like a great option to me of something to start with.
My concern is that there is a confusing overlap between the Cover and Group block.
That's an interesting perspective. So for you this would result in the cover block being distilled back to just an image one?
My concern is that there is a confusing overlap between the Cover and Group block.
That's an interesting perspective. So for you this would result in the cover block being distilled back to just an image one?
Yes. That very much feels like the core essence of the block, and I don't see why it needs to go beyond that given the features provided by the Group block.
The options specific to the Cover block for vertical alignment, min-height, default font size, etc. all feel aligned with that purpose of text over image. That's why I feel like the default placeholder should reinforce the text-over-image purpose of the block.
To further clarify it's essence, I recently selected the Cover block for a "Knockout" block style variation:
Is your feature request related to a problem? Please describe. When gradients were added to 5.4, I was very confused that they weren't included on the Cover Block placeholder along with background colors. Upon further reflection, I think the problem is that colors are there, not that gradients are missing.
The Cover block is explicitly for putting text over images. The background color support updates the color tint, and gradients can do the same now.
The group block is for putting sets of blocks in a container that can have a single background color, gradient in 5.5+, and text color.
To distinguish these purposes, I think it makes sense that a user must first select an image in the cover block and only then be able to update the background color or gradient options. Including the background-color on the placeholder settings muddles the implied purpose of the block and causes confusion.
This change has the added benefit of putting background colors and gradients on equal footing in the cover block.
Describe the solution you'd like The Cover Block only shows the image options in it's default state:
Describe alternatives you've considered I wondered about adding gradients, but, as mentioned above, I believe that showing any type of background options beyond image confuses the purpose of the Cover block and encourages it's use over Group blocks.