More intuitive Details block with summary and innerBlocks content #49808
Conversation
richtabor
added
[Type] Enhancement
richtabor
requested review from
spacedmonkey,
ajitbohra,
ryanwelcher,
juanmaguitar and
fabiankaegy
as code owners
|
One thing I wanted to add (if anyone has ideas how) is to make |
|
Size Change: +3.42 kB (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
I like the simplicity this brings.
The main loss in styling capability seems to be around styling the summary (border/padding etc.).
A few blocks have similar challenges where they have distinct elements that can't be styled (e.g. the button and input in the search block), so it might be nice to solve at some point.
|
Yeah I do also like the simplicity of this approach. However I worry the loss of the design options of the summary element are going to really limit the styling options you can create for the block. At least without having to resort to custom css. |
This is a solid point, and it's likely to be relevant for various form controls as well. A comments block is never going to be useful without a "Post Comments" button, and the gained simplicity from a flatter structure is commonly going to be useful for these cases. One idea for how to solve this is in global styles, surfacing the "Summary" element in a theoretical "Elements" panel, a la #47369. CC: @SaxonF |
I understand most of the elements being at the top-level, as they can be shared between blocks, but I wonder if Summary would make sense. I think it's only ever going to be used in the details block. |
|
Yeah it's not ideal, but maybe it's not too far a stretch in light of something like #44671. |
I'd say the design tools we have cover the 90% of styling cases for the most part; just look at the example screenshots above I took of me flexing it a bit. I think it's worth the hefty win in usability for a slight loss in that 10%. |
I agree, doesn't seem like it fits on the elements front. |
I've wrapped the inner blocks in a group and styled from there to get some of the more unique designs up above. It's not 100% ideal, but is sensible—and reduces the conflicting "where is this style coming from" issues from the separate Details, Summary and Content blocks in trunk. |
|
Flaky tests detected in 5f6125f. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4701706914
|
|
I am not sure this is more intuitive (Please note I am not in any way a UX expert!) and would prefer to see some user testing results. But I am also unsure of how we could test both versions to see which is preferred. |
|
( And before a call for testing can go out I would prefer to see this issue solved: #49679) |
|
First of all I am testing Looking at:
I believe this should be addressed more in general, as an UX issue that we need to address likely for all of the Block Editor.
I do not understand the logic here. As what you say here would also have relevance for the Columns block with the individual child columns. As for the Columns block it would be nice to be able to fully style the parent and child columns.
There is also a draft PR by @aaronrobertshaw which mentions column child clipping here: Clipping is an issue, but clipping is a minor issue in relation to giving the user the opportunity to style the parent and child the way they need to. Clipping in general is also something that needs to be addressed down the road. Right now I believe that Aarons draft PR has not been merged because of the clipping issue. Again it is minor compared to allowing the user to style things in the way they need.
To me this is setup the same way as selecting the Gallery block. There is no click the Details block and have the parent first selected and then click the inner blocks, so this is a general issue for blocks that have inner blocks. That all blocks with inner blocks the first initial click should be the parent. Click again to select the inner/child blocks. Styling in importance as I see it when going through this right now.
It works for me. As it gives the user the opportunity to style different levels of the Details block. There are so many different use cases to how someone would like to use the Details block. The only conflict I see is the clippings and that is not a big issue.
This I do not understand. Details the top parent will always be the top. Btw the following could be an example for an artsie site using the Details block. Giving the user a lot of ways to style as they choose. Btw
This is more of a general issue that design will need to look closer at. Because there will be various blocks that one will be able to style in many different ways as well as levels inner and parent. Example from the Columns block to where the parent and inner columns have been styled.
Instead of limiting the expression of a user it is better to help give hints as to what the user is styling. Let me know if there is anything else I should share my thoughts on. |
The issue of clipping when changing the shape of a block might seem minor at first glance however with the current inserter being in-canvas, clipping content can cause substantial UX issues as the inserter button can be hidden. I'd argue not being able to easily insert additional blocks is a greater problem than adding a border radius to the container. I agree we should be able to provide border-radius on more blocks while also better handling the clipping and potential UX impacts there. Joen outlines all this in a more elegant and detailed manner over on the relevant PR (#40925 (comment)). Relative to this PR, I don't have any strong opinion as to whether border-radius should be included in the adopted block supports or not. You can see the block inserter being clipped in the following demo. Demo video of inserter being clippedScreen.Recording.2023-04-17.at.9.45.42.am.mp4 |
|
So this clipping happens no matter which version of the block that is used? 🤔 But not if the border-radius is on a wrapping group block? |
|
Yes, but, there are issues with that solution too. |
|
Not sure how helpful this feedback is at this stage, but I think we should lean on simplicity as much as possible, not on customization. There's value in getting the ability to have content that con be toggle in the hands of users. It should look like regular content, like a paragraph that can be toggled, not a full fledged accordion that has other implications. More customization would be misleading in that case because people use it to make the collapsed section look like a heading, different from the rest of the content, which would be problematic. Can we reduce it to its most simplest and go from there? |
Resolves the space bar issue
I reverted back to wrapping the RichText in a summary element (the original method), which resolves this. |
Also removed border radius support. |
|
I think it's ready for another good look. |
There was a problem hiding this comment.
Code-wise this looks good, but I wonder whether a deprecation should be added now that the details block has been in a plugin release or two.
It is behind an experiment toggle, but it seems to break in a fairly bad way that doesn't allow users to easily fix their content.
What do you think?
I don't think we need the deprecation. |
|
What about using lessons learnt in regards to the Details block and continue with a Tabs block? |
Simplifies the experimental Details block to have the
<summary>as part of the block itself and Innerblocks for the content, suggested by @talldan in #45055 (comment). This is the same method used in the Quote block as well. I'd feel comfortable moving this out of the experiment following this PR.This method makes the Details block simpler by:
What?
Testing Instructions
Visuals
Example, icon, and description:
Empty:
Completed:
Completed with additional styling (to show how it can still be flexed using this method):