Try using left borders for hover + selection states (Alternate)

[kjellr]

This PR is an an alternate approach to the one proposed in #14145.

It is designed to address two problems:

1. Our current blue hover state is too prominent. (Consider a subtler hover state for blocks #14095)
2. Our current block selection state is too low contrast. (Make the selected block outline darker  #12254)

For visual reference, here's how our hover and selection states currently work:

This PR removes the blue outline from the hover state and replaces it with a 1px $dark-gray-300 left border. It adjusts the location of the block breadcrumb to match. The PR also adds a dark outline around the block toolbar, to improve accessibility there:

Screenshots

[jasmussen]

This is QUITE nice. It simplifies the hover state to be minimal. But the left border still serves as an "anchor" for the block movers on the left. The fact that these borders then grow into the box itself in the selected state is just lovely. Similarly, the hover label now "grows into" the block toolbar itself. The added contrast will also be welcome.

$dark-gray-300

For text to be legible, there has to be a 4.5:1 contrast ratio against the background. White text on $dark-gray-300 accomplishes that for the hover label. However for the borders, we only require a 3:1 contrast ratio, as that's not text and just needs to be an indicator. So $dark-gray-150 is sufficient there.

In other words, if we'd like to go lighter, and although the contrast is welcome there's also a balance to strike, so it'd be nice if we could. Which suggests we can try two things:

1. We can leave the $dark-gray-300 for the hover label, and use $dark-gray-150 for the borders, and hopefully the two will still "feel like the same material" despite the slight difference in contrast.

2. We can consider removing the hover label entirely 😱 — recent discussions suggest it might not be solving the problem we meant for it to solve. We might want to do this as a separate PR so as to be able to ship this enhancement soonish. In fact we might do 1 first and then 2 separately.

---

On a final note, I'm very happy to see that you've used the opacity colors correctly — that is, the grays we created to work on editor-style backgrounds of various colors. By correctly I mean:

• Used the opacities for the left border, and the selected block border, which need to be able to overlay various color backgrounds
• Used the non-opacity (fully opaque) colors for hover label and block toolbar border
• Even better: made the two match and feel the same, when shown on a white background.

So all of that is correct — this is just a note that if we do want to update the left border, selected block border, and block toolbar outer border to be $dark-gray-150, the left border and selected block border has to be the closest matching opacity variant.

Thanks for working on this, Kjell!

[jasmussen]

Oh, one side-note, we have to remember to verify the new hover label position works for wide, fullwide blocks!

[kjellr]

So all of that is correct — this is just a note that if we do want to update the left border, selected block border, and block toolbar outer border to be $dark-gray-150, the left border and selected block border has to be the closest matching opacity variant.

This is actually pretty close to what I did — I just didn't state it clearly above. 😄

• The hover border & block label are $dark-gray-300 (#6c7781)
• The focused block + toolbar border is $dark-opacity-200 (This works out to ~#7f8790 on white). If we're being conservative about the contrast ratios, I think this is as close to $dark-gray-150 as we can get with our current opacity values.

Here's a quick comparison of these values:

$dark-opacity-100 is definitely closer visually, but it ends up being a tad lighter than dark-gray-150. I went with the darker shade to be safer from a contrast perspective. In any case, when these are used as 1px borders, the difference is really negligible:

---

Oh, one side-note, we have to remember to verify the new hover label position works for wide, fullwide blocks!

Yes! I did look at alignments a bit when I built this.

For both wide + full, I opted to keep the hover labels on the left side. It doesn't swap out exactly for the toolbar in this case, but I like that they felt "anchored" to parts of the screen, rather than floating in the middle:

I probably need to look at left/right alignments again though — it looks like I didn't quite get those right on the first try:

[jasmussen]

Very cool, and slightly mind-bendy. Is that to say that the selected block toolbar border color is $dark-gray-300 or $dark-gray-150? Becuase it doesn't have to be darker than 150 to achieve the necessary 3:1 contrast ratio.

[kjellr]

Is that to say that the selected block toolbar border color is $dark-gray-300 or $dark-gray-150? Becuase it doesn't have to be darker than 150 to achieve the necessary 3:1 contrast ratio.

I think the simplest way to put it is that the block toolbar border color is the opacity equivalent of $dark-gray-200. This is the lightest gray opacity value we have that retains a contrast ratio above 3:1.

[jasmussen]

Okay, took it for a spin. Overall feeling: this can work. It can swat many flies in one PR, and it feels like an improvement on many fronts.

Some GIFs:

Looks good. If we were to dive into teensy minutiae, then the way the left border is painted and the solid block fades in feels "blinky". It's not visible in the GIF, but it feels like what happens is, the left border is painted on hover, and on select that left border is removed and now a border all the way around is faded in, causing a brief blink-and-you'll-miss-it gap in the left border. This is not the end of the world, but if we could "fix" this, perhaps by painting the left border, or the selected border, in a different way, that would be nice.

Then there's the Title. The title is not a block. It will eventually be, but at the moment it's not. And if you look at the GIF, the hover effect almost looks like a text caret. This looks a little jarring. Couple of ways to fix this:

1. Just keep the full border for hovering the title block, all four sides. Pros: easy. Cons, select and hover would look the same, probably not ideal.
2. Add a faux "hover label". The fact that hovering blocks shows the left border AND the hover label actually makes it look like not a caret. Not sure how easy this would be, but it feels like it woudl fix the issue.
3. Different hover style — perhaps highlight the bottom border of the title box? It's not a block, after all.

Other ideas could be good to explote too.

The permalink box when the title block is selected is offset by a couple of pixels. Also not world-ending since that box is likely going away entirely in the not too distant future, but still worth noting.

Overall, the above are little things, and this is my favorite of the bunch. It would be nice with some more design thoughts on this, but for now, stellar work Kjell!

[kjellr]

Looks good. If we were to dive into teensy minutiae, then the way the left border is painted and the solid block fades in feels "blinky". It's not visible in the GIF, but it feels like what happens is, the left border is painted on hover, and on select that left border is removed and now a border all the way around is faded in, causing a brief blink-and-you'll-miss-it gap in the left border. This is not the end of the world, but if we could "fix" this, perhaps by painting the left border, or the selected border, in a different way, that would be nice.

Good call. The hover border actually had no transition property set at all. I've remedied this in f225924. The transition on the hover border is now 0.05 longer than that of the block outline. What this means is:

• The hover state lingers for 0.05s, after the entire block outline has faded in, removing that blink.
• The hover state doesn't "blink" as much in general when you're moving around the document. It now feels a bit more smooth and considered in general.

Here's a GIF, but due to frame rates the effect is better seen in testing:

---

Then there's the Title. The title is not a block. It will eventually be, but at the moment it's not. And if you look at the GIF, the hover effect almost looks like a text caret. This looks a little jarring.

It seems to me that this caret observation effects all text-based blocks, right? At least, the single-line ones, until the hover label shows up. While we don't want this to be confused with a caret, I do think having something that is inspired by a caret sort of makes sense — as in "you can add stuff here". That was something I considered when working on #14145.

In any case, the Title block currently looks like other blocks do in terms of its hover and select states, so I'm not sure if needs something different.

---

The permalink box when the title block is selected is offset by a couple of pixels. Also not world-ending since that box is likely going away entirely in the not too distant future, but still worth noting.

Yeah, this is a somewhat maddening issue. 😄 We're using box shadow here, and it turns out that a 1px inset box-shadow is too far inside the position we want, and a 1px outset box-shadow is too far outside:

Need to do a little digging to figure that out.

[jasmussen]

Really, really really nice. This is 90% there IMO.

The border "blinking" issue is solved. Can we speed up the border initial fade, though, to match that of the movers on the side? Right now it feels like the movers fade in faster, be nice if those two were in sync.

The title box misalignment is not the end of the world, if you can fix it, cool, but otherwise it's okay.

The title/caret thing is probably worth a sanity check. @mapk @karmatosed, any thoughts?

[kjellr]

The border "blinking" issue is solved. Can we speed up the border initial fade, though, to match that of the movers on the side? Right now it feels like the movers fade in faster, be nice if those two were in sync.

Sure! Those are out-of-sync is because the movers usually animate in after a 0.1s delay. I've removed that delay and extended the animation by 0.05s to match the hover border animation timing.

[kjellr]

Based on discussions in #14154, I made a figma prototype of the concept we've been discussing in #9628, to get a sense of how this hover/focus approach might work for nested blocks. Please try it out, and compare it to the approach in #14197 (I created a similar prototype to compare that approach too 🙂). Try it out here:

🖥 Figma Prototype

[jasmussen]

I responded to the latest wonderful Figma prototype in the other branch: #14145 (comment)

Though I do wonder if there are some tweaks we can consider. As I noted on the other branch, the primary feeling I get from the heavy left border version is that it feels like it's leaning leftwards. I wonder if we can have that cake, and eat it too.

Here's a mockup that that combines the relative visual simplicity of this branch, with the bordered "anchor" of the other branch.

Hover:

Spans the height of the block, more or less identical to what you have, but only 2px instead of 3px.

Selected:

Border remains, but a darker overall gray now frames the entire block. It is dark enough that optically it feels like it's still connected to the left border, but it is not so dark as to compete with the icon colors. This helps distribute out the weight of the left border, while still not being overwhelming. What do you think?

[kjellr]

@jasmussen Thanks as always for the thoughtful feedback.

Spans the height of the block, more or less identical to what you have, but only 2px instead of 3px.

I explored this a bit, and it's actually super-easy to tweak, thanks to the width variable used in #14145. I've tested using a 2px border there, but I resolved on the 3px border for the two main reasons:

First, a 2px border could be interpreted as a mistake, whereas 3px is clearly intentional. If we're adding a border to the left there, I think we might as well "own" it. Bear with me on this 😉:

To date, Gutenberg's UI is rather intentionally vanilla — it's designed not to interfere at all with your site's content or look and feel. Depending on how you look at it, the left border is a bit of an affront to that. it's more opinionated, and has a bit of an "editorial" feel to it. It doesn't necessarily interfere with your content, but it imposes an aesthetic weight to a really foundational part of the editing canvas.

As I've sat with the left border option over the past couple weeks, I've come to see the left border both as a UI element that solves problems, and also as a brand element. This border as something Gutenberg can own: When users select a block and see this edge, they'll instantly know that this is the WordPress editor. The classic editor was instantly recognizable because of its structure and gray background, and this border helps give Gutenberg a bit of that too. That aspect of this change isn't 100% necessary, but I do think it helps to give Gutenberg a little bit of a voice.

The second reason is that the PR includes a 3px left border on mobile screens too. This is fairly visible, and animates in really nicely. A 2px border tends to be really subtle and more easily blends in with the left side of a phone's screen. It's a little hard to see in these screenshots (since they have no actual phone edge in them), but here's a comparison: https://cloudup.com/c1W_W_bTxpC

Border remains, but a darker overall gray now frames the entire block. It is dark enough that optically it feels like it's still connected to the left border, but it is not so dark as to compete with the icon colors. This helps distribute out the weight of the left border, while still not being overwhelming. What do you think?

Out of curiosity, what color did you use there? I think we could bump this up to $dark-opacity-light-800 without too much trouble:

Original ($dark-opacity-light-500)

Darker ($dark-opacity-light-800)

[jasmussen]

First, a 2px border could be interpreted as a mistake, whereas 3px is clearly intentional. If we're adding a border to the left there, I think we might as well "own" it. Bear with me on this 😉

Although you did not have to explain this to me, your explanation is stellar. Five stars. ⭐️⭐️⭐️⭐️⭐️

Out of curiosity, what color did you use there? I think we could bump this up to $dark-opacity-light-800 without too much trouble

Just for the purpose of the mockup which took a photoshop roundtrip, I used
$light-gray-800. Obviously that has to be translated to one of the opacity colors. $dark-opacity-light-800 looks good to me, I might try bumping that to 900, but otherwise, I definitely feel the gray surrounding border still feels like it shares DNA with the left border, and honestly that feels like the thing that makes it work, especially in the selected state.

[kjellr]

Awesome, thanks Joen. I'll work on a little update to #14145 to include this darker border and we can try it out there.

[kjellr]

Closing in favor of #14145