-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Bring colors by the block for some blocks #20197
Comments
This has to be intentional based on the role they play for the block and should not be generalized. In the case of a Paragraph block it should not be considered a primary interaction. For a Cover block, on the other hand, it should be easy to access from the toolbar. Another case in point: the cover block shows colors in the placeholder while paragraph does not. |
Thanks for feedback @mtias. Happy to be wrong about paragraph block. My personal feeling was moving more styling closer to where it happens helps context. As a ponder, how do you feel about a styling section by the block to include over clutter with more options there? Just putting this out there as an idea. For me, the sidebar is a place this is lost and whilst it might not be a primary action I do feel it's a handy thing to have by the block. I keep coming back to having consistent styling in one place could be a benefit. Happy to explore where that could be a wrong turn though. Let me list where this then could happen to be sure that has some clarity:
I put a '?' beside navigation and table, as unsure if this now falls into the division between primary and secondary. |
Oh, yes, the tabbed interface is something we should try to combine. It gets a bit tricky when you also have a tabbed interface for solid / gradient on the background tab. |
Totally agreeing it gets tricky. I'll explore a little more on that then. |
Noting changed the title to be 'some blocks' so we can collate and work through a list where the right ones for this are. |
But at the same time, having different locations for the same controls could be quite jarring to folks - regardless of the selected block. Especially if they're as foundational as changing a design/color. |
I already opened a similar issue: #20070. Should I close it? |
Agreed. I can't seem to come up with logical reasons for why color controls exist in one place for one block and a different place for a different block; It seems random. I'd imagine most people will not understand, and just assume that a paragraph block doesn't allow color customization. |
It depends, as the color tools do different things depending on context. For example, these mockups are placing block color after the rich text controls, which are based on inline selection (they don't affect the whole block at once). And paragraph already has support for inline color in the "more tools" of the toolbar: |
@mtias I think the (not-inline) color control should definitely go before the RichText tools, in order to keep with the currently-established pattern of putting the controls that affect the entire block first in the toolbar. |
Yes, definitely, but that's also why I don't think block color belongs in a paragraph's toolbar, because it gives more prominence to color choices than to rich text tools (bold, italics, etc), which are the most important controls on paragraphs, while making the toolbar as a whole busier. The paragraph block is the most basic text unit we have and should be clear of incidental distractions. That results in the following clauses for block color:
|
@mtias Good point. I think the Paragraph and Heading blocsk can keep the block-level color controls in the inspector. I do think the block-level color controls belong in the toolbar of other blocks like Group or Columns, though. (I also think it would be good if we could make the inspector more easily accessible and more clearly attached to the selected block somehow.) |
Somehow related, there's #22700 to track the progress of adding style controls to the blocks. |
Let's handle this on a per block basis where it makes sense, like Cover. |
This has been explored in navigation and other blocks, I would like to open the discussion on bringing colors by the block for all blocks. By unifying their place we can start on a path that could see styling out of the sidebar completely.
The problem
Look at how far away and lonely the color options are:
I joke a little, however it is a weird experience having to have the sidebar option for this. Shouldn't all these just work right by the block itself?
Existing solutions
I am going to first link what was explored in columns #16660 and similarly in navigation.
This is a pretty intense UI and just more or less puts what we have in the sidebar into a drop-down. This is a different space, so that could be iterated leaning on new styling coming in.
Moving into new exploring
I have been doing some thinking around this and how we could perhaps simplify. I came to an iteration feels still forming, but maybe good to share. This isn't meant to be a final design as much as a feedback discussion starter.
A picker would either drop-in/down/or appear, that's not set yet but this does simplify. It could also show more than just theme colours, but there is more space with this tab.
Maybe it also looks like this on hover:
There is some work on iterating the color picker so wanted to note that here as I am in this looking to align #19785.
The more I explored this, the stronger I felt moving other options from the sidebar is worth exploring (more to come on that later). If we start though, colors feel like a great starting point.
I will add that unexplored here is what it looks like with both colors 'on'. I will do that in later iterations should we decide this is a great route. My thinking is the circle could show both colors, however, this needs exploring.
Next steps
I would love some feedback around:
The text was updated successfully, but these errors were encountered: