Skip to content
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

Merged

Conversation

ntsekouras
Copy link
Contributor

@ntsekouras ntsekouras commented Jun 9, 2020

Description

Resolves #22073

In this PR:

  • Transforms are shown as a vertical list, so as to help with familiarity with other editors.
  • Transforms and Block Styles are combined in a drop down menu and arrow navigation is supported.
  • Styles have been moved below transforms.
  • Previews have been implemented with a Popover and changed style.
  • Added support for role attribute in BlockStyles component.
  • Enhanced Styles Preview at smaller viewport ( 782px ), when admin bar goes big

How has this been tested?

Screenshots

Types of changes

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.

@youknowriad youknowriad added General Interface Parts of the UI which don't fall neatly under other labels. Needs Design Feedback Needs general design feedback. labels Jun 9, 2020
@youknowriad
Copy link
Contributor

Cool stuff here Nick.

I'm testing on safari and I noticed two small things:

  • There's some kind of border under the first item.

Capture d’écran 2020-06-09 à 3 47 49 PM

  • Feels like the padding around the whole dropdown is bigger than the other popovers?

@ntsekouras
Copy link
Contributor Author

ntsekouras commented Jun 9, 2020

There's some kind of border under the first item.

I will fix that. It's the focused style I see.

Feels like the padding around the whole dropdown is bigger than the other popovers?

Yes, That was the padding from before (grid). I will change it to match the other vertical lists padding.

Thanks @youknowriad!

@ntsekouras ntsekouras changed the title WIP: Show transforms as a vertical list Show transforms as a vertical list Jun 9, 2020
@ntsekouras ntsekouras force-pushed the fix/show-transforms-as-vertical-list branch from ff52030 to abb3cc9 Compare June 10, 2020 07:00
Copy link
Contributor

@youknowriad youknowriad left a 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.

@youknowriad youknowriad added the Needs Accessibility Feedback Need input from accessibility label Jun 10, 2020
@jasmussen
Copy link
Contributor

This is nice! Thanks for working on this. Here's what I see:

after

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:

	.block-editor-block-switcher__label {
		margin-bottom: $grid-unit-10;
		color: $medium-gray-text;
	}

to this

	.block-editor-block-switcher__label {
		margin-bottom: $grid-unit-15;
	}

That would get us very close even just with the list.

@ntsekouras
Copy link
Contributor Author

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.

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?

@ntsekouras
Copy link
Contributor Author

Designwise, I think we should try to move closer to the mockup shown in #18667 (comment):

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.

@jasmussen
Copy link
Contributor

jasmussen commented Jun 10, 2020

I thought that was preferred to move Styles below, as mentioned in the issue. Should we revert them as they were before on top?

Ah, thanks for surfacing that:

Screenshot 2020-06-10 at 11 01 58

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:

  • Increase the padding inside both menus to be larger. Let's try 18px for now — ideally we should use variables that adhere to the 24px grid, but there's some overlap with the inner padding of menu items, and 18px seems like a good start.
  • Separator should be $dark-gray-primary
  • Preview should be spaced better — top: -$border-width;, and left: calc(100% + $grid-unit-15); seems to work well
  • .block-editor-block-switcher__preview-title should be color: $dark-gray-primary
  • .block-editor-block-switcher__popover .components-popover__content .block-editor-block-switcher__preview should have 18px padding instead of 10 to match what we're trying above
  • .block-editor-block-styles__item-label should also have zero left padding.

That gets us this, which I think is a good start:

Screenshot 2020-06-10 at 11 11 39

Let me know if you'd like me to push some changes directly to your branch.

@ntsekouras
Copy link
Contributor Author

I think it's fine to try with the styles below for starters. I do think we lost a little bit from this mockup:

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?

other vertical

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.

Let me know if you'd like me to push some changes directly to your branch.

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 ?

@jasmussen
Copy link
Contributor

Pushed polish that addresses the feedback I left:

Screenshot 2020-06-10 at 12 31 45

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.

@jasmussen
Copy link
Contributor

jasmussen commented Jun 10, 2020

I noticed an error in the console:

index.js:138 Uncaught TypeError: Cannot read property 'style' of undefined
    at Object.onFrame (index.js:138)
    at update (web.cjs.js:516)

That was testing the quote block.

@ellatrix
Copy link
Member

@jasmussen I think that's caused by another PR recently merged with master. I'll have a look.

@ellatrix
Copy link
Member

When I arrow navigate, the main scroll container scroll up/down.

@ntsekouras
Copy link
Contributor Author

Would be good to make this consistent across all three, with the same gray color.

@jasmussen do you mean changing the borders here to the same color as Block Switcher?

Screenshot

@ntsekouras
Copy link
Contributor Author

ntsekouras commented Jun 10, 2020

When I arrow navigate, the main scroll container scroll up/down.

It doesn't happen to me. Can you please share your browser info @ellatrix ?

@ellatrix
Copy link
Member

@ntsekouras It's in chrome. The admin menu on the left side goes up and down as you navigate.

@jasmussen
Copy link
Contributor

do you mean changing the borders here to the same color as Block Switcher?

I did not, but we should. Pushed a fix:

Screenshot 2020-06-11 at 10 23 26

Important to only do it for the dark popovers, so we still have the light ones here:

Screenshot 2020-06-11 at 10 23 30

@ntsekouras
Copy link
Contributor Author

Thank you @jasmussen! It's great that you share some details about the design decisions. It's really valuable!! :)

@jasmussen
Copy link
Contributor

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.

@ntsekouras ntsekouras force-pushed the fix/show-transforms-as-vertical-list branch from 9b52347 to 39391ed Compare June 11, 2020 09:12
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
@ntsekouras ntsekouras force-pushed the fix/show-transforms-as-vertical-list branch from 9e434bf to 2a2b2c8 Compare June 20, 2020 20:03
@ellatrix
Copy link
Member

Great work! Let's merge and iterate if there's some remaining issues. It has some time in master for testing.

@ellatrix ellatrix merged commit 2ec236b into WordPress:master Jun 22, 2020
@github-actions github-actions bot added this to the Gutenberg 8.5 milestone Jun 22, 2020
@ntsekouras ntsekouras deleted the fix/show-transforms-as-vertical-list branch June 22, 2020 12:41
return (
<MenuItem
key={ name }
className={ getBlockMenuDefaultClassName( name ) }
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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 ) ) {
Copy link
Member

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?

Copy link
Member

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?

Copy link
Contributor Author

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..

Copy link
Member

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:
Screen Shot 2020-06-23 at 12 55 49

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?

Copy link
Member

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?

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository General Interface Parts of the UI which don't fall neatly under other labels. Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Show transforms as a vertical list rather than a grid
8 participants