Remove box shadow from FSE block title and description

[glendaviesnz]

Changes proposed in this Pull Request

• Removes the box shadow from the site title and description block so they look like paragraph blocks when focused. Change suggested in feedback at Full Site Editing: Minor Site Description Improvements #34141 (comment)

I don't feel an actual input field is necessary — it isn't for the Paragraph block.

Testing instructions

• Load this branch in your FSE testing environment.
• Add a Site Description and Site Title block to a post.
• Verify that when each block is selected there is no blue text box border display as below
  

[matticbot]

Test live: https://calypso.live/?branch=update/fse-block-input-style

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[mmtr]

LGTM 👍

Seems this is the standard approach that Gutenberg takes on other blocks using PlaintText like core/code or core/html.

[kwight]

Seems this is the standard approach that Gutenberg takes on other blocks using PlaintText like core/code or core/html.

I'm seeing the border around the html block when active, which we don't have in this PR:

I actually assumed that having it when focused was an a11y thing, and that removing it would defeat that; are we understanding your comments correctly @jasmussen ?..

[kwight]

Just left some comments for further clarification first.

[kwight]

@glendaviesnz Oh, I also rebased to pull in #34237 , so that your PHPCS results here were more understandable (there's only unrelated issues 👍).

[glendaviesnz]

I actually assumed that having it when focused was an a11y thing, and that removing it would defeat that;

It looks like the HTML block is the only one that keeps the blue border on focus. A quick glance at A11y guidelines seems to indicate that the key thing is to show that the field has focus somehow - so maybe with the the likes of paragraph and heading blocks the full block wrapper is seen as indication enough - but will wait to see what @jasmussen has to say.

[mmtr]

Seems this is the standard approach that Gutenberg takes on other blocks using PlaintText like core/code or core/html.

I'm seeing the border around the html block when active, which we don't have in this PR:

I actually assumed that having it when focused was an a11y thing, and that removing it would defeat that; are we understanding your comments correctly @jasmussen ?..

I should have manually verified how the blocks look like rather than getting wrong assumptions from the code 😅.

But yeah, the box shadow is not displayed on those blocks but we still have a border around them coming from a border style.

Even though, I think it's ok to don't have any border around the input in order to match the same style we will get in the published view (which is the goal of the block editor). I think that's the reasoning behind the lack of any border on the paragraph inputs and probably showing the block box and toolbar is enough as @glendaviesnz pointed out.

That also explains why we show a border on the code block since that border will also appear in the published view and probably it is not related to an a11y enhancement. The HTML block is a different scenario, because the entered content will produce a different output on the published, so maybe the border is displayed just to differentiate these blocks from the other WYSIWYG blocks like paragraphs or headings.

[jasmussen]

Here's the core block:

In general the principles for block design is that the unselected state of the block should match what you see on the frontend, while the selected state both shows the selected block borders, and if necessary, any additional UI (such as the caption field popping out on an image). So normally we would not want those borders, because they are not reflected on the frontend.

However the custom HTML block is a bit of a special case, since it literally is custom HTML — you could write any code in there. For this block, the important bit is that the preview tab shows something that is front-end accurate, which is the case:

In other words, the gray border around the custom HTML block exists to indicate the boundaries of this contiguous chunk of custom HTML, even when you're typing and the block borders fade out. Think of it as a textarea, which therefore should have similar styles to a textarea.

The additional focus style wasn't there last I worked on the block, which means it has intentionally been added, and it makes sense — I only wish it used the same focus style as the actual textarea does, i.e. ligher blue and 2px solid. But that's something to fix in the upstream project.

I would recommend keeping it. CC: @enriquesanchez in case he has input.

[glendaviesnz]

@kwight are you happy with this now with the additional discussion?

[kwight]

Whatever works for the designers, absolutely 👍