Block: Try adding the left/right block hover areas #6101

youknowriad · 2018-04-10T15:24:32Z

For unselected blocks, we only show movers the movers when we're close to them and same for the block settings menu.

Testing instructions

Add several blocks
Try hovering next to the left and the right area of the blocks
When you're close to the left the movers appear
When you're close to the right the settings menu appear

Show movers on the left and settings on the right

youknowriad · 2018-04-10T15:31:34Z

editor/components/block-list/with-hover-areas.js

+		constructor() {
+			super( ...arguments );
+			this.state = {
+				hoverArea: null,


I can easily add an isHovered state to this component to remove it from the block.js component but it seems that this state is slightly more complex than just keeping a boolean on whether the block is hovered or not. Might be good to do but I'll defer to @aduth here. I think you have more knowledge about the edge cases there.

jasmussen · 2018-04-10T16:28:21Z

Too cool.

It seems like it would be worth trying a few things to tweak this further. That is, always hide the mover and ellipsis, even when the block is selected. Perhaps combined with the hoverable area left and right being wider, so they invoke more easily, that will strike a nice balance.

Can we also add a transition? Something alongthe lines of transition: opacity .4s linear, so they side UI fades in when you enter the hover area?

We want to make sure this works well on mobile also. That is, on mobile, these shouldn't fade out at all, as the side UI sits below the block in the mobile breakpoints.

mtias · 2018-04-10T16:41:50Z

Thanks for trying this. It's feeling rather nice to me and greatly reduces the UI weight. If adding this also for the selected state we have to make sure things can be targeted with keyboard.

youknowriad · 2018-04-11T09:32:27Z

Updated the PR. It works also for selected blocks, but the elements are tabbable even if hidden so it works fine using keyboard.

jasmussen · 2018-04-11T09:39:05Z

Here's a GIF:

This seems to work really well for me now, very very nice.

I feel like we should make the hoverable area to reveal the side controls bigger... It feels like it's below 20% now, but it could be between 25 and 33% the width of the whole block, I feel like.

Or is it measured in pixels right now? If yes, then the breakpoint where we switch between mobile side UI and desktop side UI is 600px, and so if we can't use percent, it might be worth trying to make it 200px left side, 200px neutral center, 200px right side. There's no reason not to go pretty big with this stuff, at least for a start, we can always pull back.

Nice!

youknowriad · 2018-04-11T09:42:36Z

@jasmussen So right now the hover area is 120px and when the block is smaller than 2* 120px the hover area is 50% of the block. I can increase it to 200px or use a percentage, your choice :)

jasmussen · 2018-04-11T09:45:45Z

Let's try, and if to make the areas min-width: 160px, max-width: 240px. Or width: 30%. Either of those, I think, would be good to test as a start, and then we can tune as we go. Sound good?

mtias · 2018-04-11T20:15:59Z

I'm really liking this, let's get it in. :)

mtias · 2018-04-11T20:18:39Z

edit-post/assets/stylesheets/_animations.scss

@@ -17,4 +17,16 @@
 	animation: slide_in_right 0.1s forwards;
 }

+@mixin fade_in {
+	animation: fade-in 0.5s ease-out;


I think we can make this slightly faster, 0.3 or 0.4.

jasmussen · 2018-04-12T08:03:59Z

Dig it. This really lightens the cognitive burden on the UI, while still allowing powerful tools to be present. To echo Matías, we should definitely try this. And this fixes #3044.

Also appreciate bundling the hover label with the side hover, I think that's perfectly good to try. 👍 👍 from me.

aduth · 2018-04-12T12:22:25Z

editor/components/block-list/breadcrumb.js

+	}
+
+	onFocus( event ) {
+		this.setState( {


Why was this needed?

In the breadcrumb component at the moment no because it's not shown at all when the block is selected, but I didn't want to write the implementation depending on something not in the component itself. If tomorrow we decide to show this breadcrumb even on selected blocks, this will become necessary.

aduth · 2018-04-12T12:25:29Z

editor/components/block-list/with-hover-areas.js

+		}
+
+		onMouseMove( event ) {
+			const { width, left, right } = this.container.getBoundingClientRect();


What forces layout / reflow

[...] This is also called reflow or layout thrashing, and is common performance bottleneck.

Box metrics

[...] elem.getBoundingClientRect()

https://gist.github.com/paulirish/5d52fb081b3570c81e3a

And in a mousemove, it's likely being called hundreds of times 🙁

I guess I can look for alternatives to getBoundingClientRect

Can't think of any alternative without browser reflow

aduth · 2018-04-12T12:29:07Z

editor/components/block-list/with-hover-areas.js

+		}
+
+		componentDidMount() {
+			// Disable reason: We use findDOMNode to avoid unnecessary extra dom Nodes


Was this the main reason for using mousemove instead of some floating invisible elements which trigger on mouseenter?

No, the main reason is that mouseenter doesn't trigger on areas with lower z-index, since these areas would need a lower z-index to allow writing in the editables etc...

Yeah, I see what you mean. I played with some ideas for creating an inverted hover area "hole" to trigger the unhover while still allowing the contents to be interacted, but it's certainly more complex. Maybe worth exploring, but I struggled to get it working perfectly (particularly for the "hole" to be interacted with, and capturing all unhovers with various layering contexts).

Diff: https://gist.github.com/aduth/d08fe307491f641f333fcd362ef38bf5

aduth · 2018-04-12T12:41:05Z

editor/components/block-list/with-hover-areas.js

+ */
+import { Component, findDOMNode } from '@wordpress/element';
+
+const withHoverAreas = ( WrappedComponent ) => {


Should we have used @wordpress/element's createHigherOrderComponent ?

aduth · 2018-04-12T12:42:52Z

editor/components/block-list/style.scss

@@ -699,3 +699,11 @@
 		padding-top: 6px;
 	}
 }
+
+.editor-block-breadcrumb {


Aside: I applied an invalid class name per standards; this should be .editor-block-list__breadcrumb

jasmussen · 2018-04-13T11:05:27Z

Wanted to note that the use of a keyframe animation can cause some jumpiness. I will, in an incoming PR, refactor this to use just a transition, which should fix that.

ellatrix · 2018-04-26T19:50:19Z

editor/components/block-list/block.js

 					<BlockSettingsMenu
 						uids={ [ uid ] }
 						rootUID={ rootUID }
 						renderBlockMenu={ renderBlockMenu }
+						isHidden={ ! isHovered || hoverArea !== 'right' }


@youknowriad Why does the toolbar only hide? Why not prevent rendering? If there's a reason, it's not immediately clear from this code.

Because it should stay tabbable. When it receives the focus it's shown.
There's a comment above (with a typo :P)

We render block movers and block settings to keep them tabbale even if hidden

Oh, thanks, I didn't read that far up. :)

youknowriad self-assigned this Apr 10, 2018

youknowriad requested review from mtias and jasmussen April 10, 2018 15:24

Block: Adding the left/right block hover areas

4d5fa38

Show movers on the left and settings on the right

youknowriad force-pushed the add/block-hover-areas branch from b218932 to 4d5fa38 Compare April 10, 2018 15:25

youknowriad commented Apr 10, 2018

View reviewed changes

Extend the hover areas behavior to the selected block and add animations

63e4c81

Make the hover areas a little bit bigger

fc2efa4

mtias reviewed Apr 11, 2018

View reviewed changes

youknowriad added 2 commits April 12, 2018 08:59

Show breadcrumb only when we're close

3d4a22d

Fix small bug where the movers are stuck

bf2731f

youknowriad added 2 commits April 12, 2018 09:09

Show the breadcrumb when it's focused

667905e

Fix keyboard navigation to movers and block settings menu

f614065

youknowriad merged commit 503ddba into master Apr 12, 2018

youknowriad deleted the add/block-hover-areas branch April 12, 2018 08:20

youknowriad added this to the 2.7 milestone Apr 12, 2018

youknowriad mentioned this pull request Apr 12, 2018

Show side UI on selected blocks #6139

Merged

aduth reviewed Apr 12, 2018

View reviewed changes

ZebulanStanphill mentioned this pull request Apr 12, 2018

Refine side UI #6141

Merged

youknowriad mentioned this pull request Apr 12, 2018

Hover Areas: Small improvements #6148

Merged

afercia mentioned this pull request Apr 19, 2018

Reconsider the left/right block hover areas, at least for the selected block #6272

Closed

ellatrix reviewed Apr 26, 2018

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Block: Try adding the left/right block hover areas #6101

Block: Try adding the left/right block hover areas #6101

youknowriad commented Apr 10, 2018 •

edited

Loading

youknowriad Apr 10, 2018

jasmussen commented Apr 10, 2018

mtias commented Apr 10, 2018

youknowriad commented Apr 11, 2018

jasmussen commented Apr 11, 2018

youknowriad commented Apr 11, 2018

jasmussen commented Apr 11, 2018

mtias commented Apr 11, 2018

mtias Apr 11, 2018

jasmussen commented Apr 12, 2018

aduth Apr 12, 2018

youknowriad Apr 12, 2018

aduth Apr 12, 2018

youknowriad Apr 12, 2018

youknowriad Apr 12, 2018

aduth Apr 12, 2018

youknowriad Apr 12, 2018

aduth Apr 12, 2018

aduth Apr 12, 2018

aduth Apr 12, 2018

jasmussen commented Apr 13, 2018

ellatrix Apr 26, 2018

youknowriad Apr 26, 2018

ellatrix Apr 26, 2018

Block: Try adding the left/right block hover areas #6101

Block: Try adding the left/right block hover areas #6101

Conversation

youknowriad commented Apr 10, 2018 • edited Loading

Choose a reason for hiding this comment

jasmussen commented Apr 10, 2018

mtias commented Apr 10, 2018

youknowriad commented Apr 11, 2018

jasmussen commented Apr 11, 2018

youknowriad commented Apr 11, 2018

jasmussen commented Apr 11, 2018

mtias commented Apr 11, 2018

Choose a reason for hiding this comment

jasmussen commented Apr 12, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

What forces layout / reflow

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasmussen commented Apr 13, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad commented Apr 10, 2018 •

edited

Loading