-
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
Show transforms as a vertical list #23028
Show transforms as a vertical list #23028
Conversation
I will fix that. It's the focused style I see.
Yes, That was the padding from before (grid). I will change it to match the other vertical lists padding. Thanks @youknowriad! |
ff52030
to
abb3cc9
Compare
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.
This is looking good to me overall but there's something I was wondering.
We're not using a DropdownMenu here and instead we use just Dropdown, that's fine cause sometimes you want extra things in the content (like the previews), but we lose some DropdownMenu features like arrow navigation. it makes me wonder if we should wrap the MenuGroups inside NavigableToolbar to enable the arrow navigation.
This is nice! Thanks for working on this. Here's what I see: At the end, instead of using tab to navigate the menu items, I use arrowkeys, which breaks. That feels a bit frustrating, because arrowkeys work, for example, in the ellipsis menu. This would be nice to address. Designwise, I think we should try to move closer to the mockup shown in #18667 (comment): It doesn't have to be part of this PR — but it's worth sharing the source reason for making into a list. One small step towards that could be to change this:
to this
That would get us very close even just with the list. |
Hey @youknowriad! I thought about arrow navigation and although I didn't implement it in this PR, I had seen the Autocomplete component as some reference that implements arrow navigation itself . Could the arrow navigation be implemented with the way you suggest also here? Maybe others share their thoughts too? |
I thought that was preferred to move Styles below, as mentioned in the issue. Should we revert them as they were before on top? At first I implemented the lists closer to the first mockup ( more paddings etc ). But as mentioned from @youknowriad and I believe he is right, this wasn't so consistent with the rest vertical lists. After that I made it more compact and to match the hover styles etc. Also I am wondering if it would make sense to add another level for the user to find out the available Style options, since there is a small number of styles? Thanks for reviewing @jasmussen! I have also made the css fix you suggested. |
Ah, thanks for surfacing that: I think it's fine to try with the styles below for starters. I do think we lost a little bit from this mockup: A few things can probably get us closer:
That gets us this, which I think is a good start: Let me know if you'd like me to push some changes directly to your branch. |
I had it like this in my first iterations but as pointed out it was inconsistent with other vertical "menus": Do you think that as well designwise? Also @jasmussen please take a look to the changes when smaller viewport. Previously they were just not working well with the Styles Preview and I have placed Preview at the bottom.
Feel free to push them if you have already made them to test the UI. Just let me know. Thank you! I am now implementing the arrow navigation but since we have two separate MenuGroups and the focus goes to Blocks, arrow navigation will cycle through Blocks only and not the Styles. Any thoughts/workaround on this @youknowriad ? |
Pushed polish that addresses the feedback I left: There needs to be contrast between menu item section labels (Styles) and the menu items (Default, Large), so I moved from the styling that's present in the global more menu, to the styling used for categories in the inserter. Would be good to make this consistent across all three, with the same gray color. |
I noticed an error in the console:
That was testing the quote block. |
@jasmussen I think that's caused by another PR recently merged with master. I'll have a look. |
When I arrow navigate, the main scroll container scroll up/down. |
@jasmussen do you mean changing the borders here to the same color as Block Switcher? |
It doesn't happen to me. Can you please share your browser info @ellatrix ? |
@ntsekouras It's in chrome. The admin menu on the left side goes up and down as you navigate. |
Thank you @jasmussen! It's great that you share some details about the design decisions. It's really valuable!! :) |
Always happy to help, ping me anytime. I worked on some of the design implementation of #18667, which isn't actually complete yet, so I'm happy to see every little bit getting us closer to completing it! Thanks again for the PR. |
9b52347
to
39391ed
Compare
Create seperate BlockTransformationsMenu component
Removed some unnecessary styles.
A node with skipchildrenfocus can skip its children to be able to get focus, fixing some arrow navigation issues. This is a temp commit to get feedback.
tabIndex must be properly discussed to decide how to handle elements not navigable but focusable
9e434bf
to
2a2b2c8
Compare
Great work! Let's merge and iterate if there's some remaining issues. It has some time in master for testing. |
return ( | ||
<MenuItem | ||
key={ name } | ||
className={ getBlockMenuDefaultClassName( name ) } |
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.
Is this class necessary here?
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.
This class is used in BlockTypesList
( it was used before ). I came across some failing e2e tests that were using the transform
functionality and this class seemed a good idea to preserve, as it might be used by other e2e tests in the future.
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 don’t think that e2e test should shape production code, and I’m sure you can use accessible labels to achieve the same result as block names are unique. It isn’t a big issue but if we can remove unused code with little effort we should always aim for it.
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 don’t think that e2e test should shape production code
I definitely agree with this!
In this specific case though ( MenuItem
) there is not any accessible labels to match, besides the content itself. MenuItem
has an info property but this would end up adding stuff again.
So, would it be preferable to search through the content?
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.
Well, the content is the accessible label, this is what is going to be announced when users depend on screen readers. By using this approach, we also ensure that UI is accessible. It's harder to target elements by content, but there are many existing tests that do it.
@@ -77,7 +92,7 @@ export function find( context ) { | |||
const elements = context.querySelectorAll( SELECTOR ); | |||
|
|||
return Array.from( elements ).filter( ( element ) => { | |||
if ( ! isVisible( element ) ) { | |||
if ( ! isVisible( element ) || skipFocus( element ) ) { |
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.
Should the description of the function be updated to reflect changes applied? Does it make sense to include an entry in the CHANGELOG for the package? Is it a bug fix?
Is it possible to cover it with a unit test to prevent further regressions?
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 missed this comment. Maybe we can create a follow-up PR?
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.
@gziolo It wasn't exactly a bug, more like making DropdownMenu
's arrow navigation work properly by adding the BlockStyles
, which had nested elements. That was causing problems with the declared Selectors
here: https://github.com/ntsekouras/gutenberg/blob/2a2b2c8ce042bc06c220eab6891b0d477b6d9740/packages/dom/src/focusable.js#L20 . Nested elements were also selected as focusables
that caused breaking the navigation.
My first thought was introducing a new attribute in this commit ( focusable.js changes
), but suggested to simplify it..
I would really appreciate any feedback for how to handle this better..
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.
focusable
is the public API on the @wordpress/dom
package: https://www.npmjs.com/package/@wordpress/dom. It has 15k downloads per week. It's used by 3rd party projects:
Using tabindex="-1"
– it's a well-established pattern used with keyboard navigation:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex
A negative value (usually tabindex="-1") means that the element is not reachable via sequential keyboard navigation, but could be focused with Javascript or visually by clicking with the mouse. It's mostly useful to create accessible widgets with JavaScript.
It feels like it was missed in the initial implementation and it would mean a bug fix. @ellatrix, can you confirm?
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 was added by Andrew in #2323. Not sure if iframes were meant to be excluded. I don't really understand the change here. Isn't everything that is tab index -1 already excluded? And an iframe's children can't be queried, so they are also excluded?
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 think that you need to explicitly mark all children at every nesting level to make it work. It's meant to be addressed with inert attribute but it isn't implemented in all browsers yet.
Description
Resolves #22073
In this PR:
role
attribute inBlockStyles
component.How has this been tested?
Screenshots
Types of changes
Checklist: