Initial implementation of <details> block #23940
Conversation
|
Size Change: +551 B (0%) Total Size: 1.16 MB
ℹ️ View Unchanged
|
|
@enriquesanchez I have some questions about a11y with this. Ideally I'd like to use the native I think I can disable the spacebar toggle, but will keyboard users still be able to toggle the visible portion? If not, would adding a block toolbar button for toggling be a usable workaround? |
ZebulanStanphill
added
Needs Accessibility Feedback
|
The term "accordion" should probably be added as a keyword so this block shows up when searching that term in the inserter. |
|
Hi @georgeh, thanks for the ping! 👋
Oh, this is a tricky one. Knowing that we want as much fidelity as possible between the editor and the front-end, I think users should be able to toggle expanded/closed in the editor as well. An idea I can think of is to use the toggle arrow as the only means to expand/collapse the section in the editor? And ignore any spacebar/enter key presses while the summary text is focused?
Another thought is to mimic the functionality already found in the Navigation block, where submenus are hidden by default but are shown if the parent block receives focus. Could that maybe also work here? The user would not need to toggle anything, just focus on the block to see the expanded section.
I'll bring this up during the next accessibility team meeting this Friday so we can get more folks chiming in and providing feedback. One thing I also noticed while testing this PR, is that the summary text is missing the toggle arrow that indicates this is an expandable/collapsable item.
I think having it there is important to let users know how they can interact with it. |
|
@enriquesanchez I think the reason the summary arrow-thing is missing in the editor is because the editor is using a |
|
@ZebulanStanphill - you're right, I initially was using @enriquesanchez I'm going to try it with the |
|
Hi @georgeh 👋 As promised, we discussed this PR in the accessibility team chat, and left our feedback on the issue. |
|
Thanks for the pointers @enriquesanchez, I was hoping that this would be a quick way to get a basic accordion knocked out but now see that I still think there's value in having a |
|
Glad to hear that, @georgeh! Please let us know when/if we can help test your PR. |
|
@ZebulanStanphill I pushed up a version that opens/closes entirely based on the block selection. What I like about this approach is that it's simple. What I dislike is that there's no way to see how a page looks with multiple Also, when you use the keyboard to move into the details from the bottom, I would want the last hidden block to be selected instead of the |
There was a problem hiding this comment.
@ZebulanStanphill I pushed up a version that opens/closes entirely based on the block selection. What I like about this approach is that it's simple. What I dislike is that there's no way to see how a page looks with multiple
detailsopen (e.g. "what does this look like when everything is pushed down the page").
Yeah, I'm not sure if this is the right approach or not. The big issue here is that we need to be able to edit the text of what would normally be a clickable element, while also wanting to be able to use the clickable element in the same UI. I'm not entirely sure what the best approach is in this situation.
Also, when you use the keyboard to move into the details from the bottom, I would want the last hidden block to be selected instead of the
summary, so I'm going to try to figure out how to tell when that happens. If you want to try what I'm talking about, add adetails, then add some InnerBlocks to it, then add another block after thedetailsblock. That last block, when focused, will close thedetailsblock. Now press "up" on the keyboard and it takes you to thesummarypart ofdetails, not the last InnerBlocks. That feels weird to me.
I think from an accessibility perspective, the current behavior makes the most sense, but I'm not certain. It would be good to get some accessibility team feedback here.
georgeh
force-pushed
the
add/details-block
branch
from
a5e9010
to
aa89f97
Compare
| category, | ||
| edit, | ||
| save, | ||
| // details and summary are not translated because they are the HTML tags |
There was a problem hiding this comment.
| // details and summary are not translated because they are the HTML tags | |
| // "details" and "summary" are not translated because they are the HTML tags. |
| /* You may be wondering why we don't just use a <details> element here. | ||
| * The problem we are trying to solve is that a <summary> is basically a | ||
| * button, and when it has focus, it eats the space key. | ||
| * | ||
| * That's a problem if you want to use a <RichText> component inside your | ||
| * <summary>. Each time you press space, it toggles the rest of the | ||
| * <details>, and it doesn't even add a space to your <RichText>. | ||
| * | ||
| * Then there's the fact that the space exists for a11y reasons. If you | ||
| * catch the event and preventDefault() then you've remove the way for | ||
| * keyboard users to toggle the <details>. | ||
| */ |
There was a problem hiding this comment.
Come to think of it, maybe we can use a details + summary element in the editor after all. Why not just catch the event and preventDefault() in the editor? Combine that with the current expand-on-focus behavior and nothing would change except we could use the actual HTML elements and avoid the CSS simulations, right? We might also have to set a different value for the HTML role attribute if using the RichText component doesn't already do that.
We already can't click-to-toggle the simulated details in the editor, so why not just go ahead and use a real details?
There was a problem hiding this comment.
It's worth noting that a "browse mode" as proposed in #23328 would allow the user to interact with the details the same as they would on the front-end.
There was a problem hiding this comment.
I started with summary and I ran into issues with RichText getting the space key event when I preventDefault(). Even if I stopped the space key event on summary, the event wasn't getting to RichText for some reason so mytextwouldruntogether.
I'll spend some more time with it though, in case I missed something.
There was a problem hiding this comment.
I made some progress on <summary> with @vcanales's help and now it works in Chrome and Safari. I'll see what I can do about Firefox
There was a problem hiding this comment.
@vcanales and I got details and summary to work in the edit view in Chrome and Safari by putting RichText as a child of summary. However, Firefox seems to have an issue with contenteditable inside summary that prevents it from seeing the space key. I've created a simple test on JSFiddle showing the issue. This is probably due to summary's role as Button.
I can't update the value in the Edit component because I don't know the current caret position, so the only other way forward I see is to add some way to trigger a keyboard event in RichText.
There was a problem hiding this comment.
Hmmm... this is a tough one. Pinging @ellatrix for technical help.
|
Btw here is the issue for the accordion block which is still in the design phase. #21584 |
|
@paaljoachim I thought that |
|
Thanks for the PR. I wanted to share some high level thoughts on this PR, and the idea of a "Details" block. The thing that I like about keeping it just a simple details block is that it really is quite simple, but could conceivably be used by users in a number of creative ways. I picture one that is as minimal as can be, inherits theme colors, and just works well. It would make it easy for themes to embrace the block, and for patterns to use it in useful ways. With various global styles introducing visual features, even moreso. Accordions, on the other hand, is a bigger undertaking than it might seem. I imagine it can be useful just like a details block, but in order to be an accordion worth including, it also comes with a great deal more complexity. It likely also needs to be more opinionated, in that it may need to come with icons or graphics, and certainly borders and a more elaborate behavior. Outside of the increase in scope, and especially until global styles are further ahead, this will likely make it harder for it to inherit theme styles and ensure contrast in arbitrary background colors (currently the only safe bet here is to use It also opens many questions that a Details block does not:
All of that is fixable. I can definitely see someone tackling an accordion block some time in the future, and I can personally see it being a delightful block in core. My larger point with the above, though, is that there is a simplicity and utility to the Details block that doesn't easily translate to an Accordion block. For that reason, I don't think the two should necessarily be perceived as analogous. And I could definitely see both coexisting in core. I'd love to use the Details block for hiding spoilers, for example, but I wouldn't use an accordion for that. |
| </InspectorControls> | ||
| <details className={ className } open={ showInnerBlocks }> | ||
| <summary ref={ summaryRef }> | ||
| <RichText |
There was a problem hiding this comment.
I wonder, could the tag name of rich text be summary?
There was a problem hiding this comment.
I tried that initially but the summary was swallowing the space key event and so everywordwouldruntogether. Making RichText a child of summary fixed that issue in Chrome and Safari, but not in Firefox.
The other approach I took was to use divs and CSS to emulate details in the editor view, and that worked, but I would much rather use the native elements if possible.
There was a problem hiding this comment.
@ellatrix Do you know if there is a way to tell RichText to insert a [space] at the current caret position? I'm going to poke around the components in @wordpress/rich-text and @wordpresss/block-editor to see if that would allow us to continue using <summary> in Firefox.
There was a problem hiding this comment.
I wound up making a change to the RichText component that fixed it in Firefox and allowed us to use summary as our tagName
|
What are some usage cases for the Details block vs the Accordion block? At present time I do not know what the difference is between the Details block and the Accordion block. |
|
This block is getting closer to ready, but I want to figure out if it's in the project's best interest to merge this or pass on it in favor of the accordion block. A However, if we are adding an accordion block to core, there's some overlap in use cases. Having two blocks with very similar interactions in core may just serve to overwhelm and confuse people. The distinction between an accordion and So the question is do we ship this now or wait for an accordion? The accordion block will probably not use the It's also a question of how much Gutenberg's core block library should focus on making native HTML available to people versus making pre-assembled components. I'm proud of this block and the technical hurdles we've overcome, but I'm more concerned with making sure the editor we ship is the best it can be for people who use it. I'd love to hear any more arguments for or against merging this that I've missed. |
|
I'm currently not sure whether we should ship this block or not; but if not, then I'd definitely recommend releasing it as a plugin. I'd certainly like to use it. |
|
The "Open by default" option is somewhat oddly aligned in the inspector. There aren't any other cases of controls being displayed in the inspector outside of an accordion.
Also, is there any reason we can't just put this control in the toolbar? |
|
Perhaps we should call it a FAQ block. |
georgeh
force-pushed
the
add/details-block
branch
from
7857885
to
ac83185
Compare
|
Pushed the icon:
By the way I see a double shadow inside that panel above 👆 — I think the compoment may be used wrong, and that we need to include a full collapsible panel, in order for it to behave as intended:
You can call it "Settings", as there's only one. |
|
I've been working over on the Accordion block side of things and thought I'd drop in here as well. 👋 The Details block (I prefer "Collapsible block") is so good! I love that it doesn't use any JS and is very simplistic as noted above. But from a user perspective, it basically functions the same as the Accordion block. It's a line of text with an arrow that toggles to reveal other content. Styling alone shouldn't be the only visual differentiator between the two blocks. I imagine we can style the Details block just like we do the Accordion block without a whole lot of effort. I tend to agree with @georgeh's thoughts here:
Both blocks really perform the same function but using different semantics. It's like having a "Bold" option that uses |
|
I think we should avoid adding any styles to a Details block ourselves, except perhaps in the opt-in In the case of an Accordion block, we're forced to have some styles since there are no native browser styles, but even then I think we should limit them to the bare minimum to make the block functional/accessible. Perhaps to the average user, there's no obvious difference between a Details and Accordion block. But the Details block simply cannot be used as a truly accessible accordion. If we're only going to have one of the two, it must be the Accordion, because it will ultimately be more flexible in the long run. Even if this PR doesn't get merged, I think the included fix (or something similar) to allow |
I totally agree here, @ZebulanStanphill. My concern is that the default styling for the Accordion block is nearly identical to the Details block. It is without styling for the most part to make it easy for themes to style on their own. I was planning to add style variations which give the Accordion block borders, more prominent headings, etc. and even provide some block settings that allow further customizations with color. |
|
An FAQ can be created with a good accordion block. The spoiler use case can be filled if the accordion is simple enough. It also seems most of the agreement on this thread is that simple is a key value for the Details block. In that vein, if the accordion block can be built in a truly simple way (no JS), it would avoid the pitfalls pondered previously. Presumably the theme integration can be solved with proper global styles integration. If we were to go that route, we want to make sure to addres @carolinan's feedback here, and @dingo-d (also to Zeb's point) should feel free to take inspiration from the GPL work that transpired in this PR. |
|
Yeah,
I'm pretty sure it's impossible to build an accessible accordion without JS. You need a To reiterate, a |
|
I created #24558 with the |
|
How is the details block coming along? |
|
I would say that given the overall excitement around the accordion block, this one is indefinitely shelved. |
|
@paaljoachim To second what @jasmussen said, we are not looking to get this into core since it's not a great replacement for an actual full accordion. However we did expose a bug with using the |
Description
Adds a
<details>blockHow has this been tested?
Screenshots
Editor:
Rendered:
Closed:
Opened:
Types of changes
Checklist: