-
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
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? |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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
details
open (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 thedetails
block. That last block, when focused, will close thedetails
block. Now press "up" on the keyboard and it takes you to thesummary
part 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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder, could the tag name of rich text be summary
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Perhaps we should call it a FAQ block. |
7857885
to
ac83185
Compare
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: