Twenty Twenty-Four: Unintended focus outline is applied in the Site Editor

[wildworks]

Improvements have been made to the focus outline style for Twenty Twenty-Four in [57554]. This changeset adds the following styles, which appear to affect all focusable elements in the site editor.

.wp-site-blocks *:focus{
  outline-width:2px;outline-style:solid
}

[wildworks]

Outline when focusing on a cell in a table block

[wildworks]

Outline when focusing on paragraph block

[poena]

So what is the expected way for any users to add focus styles?

The "elements" in theme.json includes links and buttons. There are so many more focusable elements, so its not a good enough replacement.

Do we really need to enqueue the style.css file in block themes, or should the specificity in the editor styles solve this?

[wildworks]

I'm wondering if it's necessary to override the browser's default focus outline style in the first place. This is because I believe that the browser's default focus style should meet accessibility standards. If we want to avoid the dot style, how about just removing the focus style itself from theme.json?

If we want to explicitly increase the thickness of the default focus outline, we might have no choice but to load style.css only on the front end or define a style like the one below.

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 2,
	"styles": {
		"elements": {
			"button": {
				":focus": {
					"css": "outline-width:2px;outline-style:solid"
				}
			}
		},
		"blocks": {
			"core/navigation-link": {
				"elements": {
					"link": {
						":focus": {
							"css": "outline-width:2px;outline-style:solid"
						}
					}
				}
			},
			"core/comments": {
				"css": "& input:focus { outline-width:2px;outline-style:solid }"
			}
		}
	}
}

[poena]

This is not only a problem for this theme, but for all block themes where someone wants to change the focus style.

[sabernhardt]

Considering that the purpose of the thicker style is to make focused elements more visible, I would call the focus style in the site editor more of a "happy accident" than a mistake.

However, it is inconsistent with the post editor, so it probably should be changed.

The theme could check whether .wp-site-blocks also includes one of the editor classes. The editor's class attribute (for now) includes block-editor-block-list__layout and edit-site-editor-canvas__block-list.

.wp-site-blocks:not(.block-editor-block-list__layout) *:focus

Or if raising the specificity more is a problem, it could use :where()

.wp-site-blocks:where(:not(.block-editor-block-list__layout)) *:focus

If the editor's content.css is changed instead, html .rich-text:focus would be enough to override Twenty Twenty-Four's style.

[sabernhardt]

lowers the specificity of Twenty Twenty-Four's focus style

[sabernhardt]

A less specific selector in the theme could avoid the extra outline in the site editor without needing to use an editor-related class name.

[wildworks]

I think a lower selector makes sense to me too. On the editor side, no unnatural outlines appear to occur.

What do you think about setting the specificity to zero to ensure that only the browser default styles are overridden?

:where(.wp-site-blocks *:focus) {outline-width:2px;outline-style:solid}

[youknowriad]

I agree that lower selector makes sense. Did we consider removing .wp-site-blocks as well? Is that really necessary?

[poena]

Thank you for your help, everyone.

I used .wp-site-blocks to prevent the style from affecting the admin toolbar links, log out link, and skip link. Which are outside (before) <div class="wp-site-blocks">.

Updating the style in the theme is a short term fix, it might solve this exact situation but does not prevent other themes and users from breaking the Site Editor focus styles.

[youknowriad]

Updating the style in the theme is a short term fix, it might solve this exact situation but does not prevent other themes and users from breaking the Site Editor focus styles.

I agree with the logic but for me the issue is the usage of the specific .wp-site-blocks because with the same logic above, you could say the admin bar should have a higher specificity for these things.

This style is like a "reset" so IMO, it should have the lowest specificity possible.

[sabernhardt]

using :where(.wp-site-blocks *:focus)

[poena]

Screenshot of 60535.2.diff: The table block in the Site Editor, with a cell selected and no visible focus style

[poena]

I have not found a way to make it work without the wp-site-blocks class.
And I don't think the theme should enqueue the style CSS file only to increase the outline width; so I would like to re-add the commit keyword for patch 60535.2.diff.

[oglekler]

Hi @poena this can have a huge impact on the front end, and if I am using a mouse to hover, the hover behavior should be enough if I am not using a keyboard to navigate (how these things can be saparated - is a question too). I found a couple of places where this new style looks really weird, but with different themes and places, this can have an impact in many different and unexpected places.

[poena]

I did not understand:

• The CSS does not change the :hover styles and the :active styles.

• Nor does it change other themes.

[poena]

That WooCommerce tabs are problematic to style is not a problem with the CSS proposed for this ticket, but with the plugin.
You can see that even in Woo's own theme "Storefront", Hello Elementor, Astra, Kadence, and GeneratePress, the focus outline for the tabs on the single product page is only visible on three sides.

WooCommerce itself includes extra CSS for the tabs for several of the bundled themes: but not for Twenty Twenty-Four.

[oglekler]

Thank you, @poena, I just panicked a bit when I saw this focus behaviour because one time we had global change in images appearance and at some sites I was maintaining back then all images become stretched. Of course, I was testing before an update, but still it was a surprise.

Can we use :where() as @sabernhardt has suggested? It most likely will allow plugins to keep their own focus behaviour on elements they specified.

[poena]

I tried removing the outline width on links with the :active state, but it did not hide the outline when I right click on a link (Chrome and Firefox on macOS).

It only kind of worked on left click mouse down. On mouse up, both the outline and text decoration are visible again.

I just added this in theme.json under styles > elements > link

":active": {
	"outline": {
		"width": "0"
	}
},

[wildworks]

The reason why focus styles are applied even when you right-click an element is probably because right-click implicitly puts focus on the element. If this was intended, I don't think it's a bug. For example, Twenty Twenty-One also has its own focus style, which can be applied in the right-click menu.

​https://github.com/WordPress/wordpress-develop/blob/ec37b57fb98a28539f9427f81c3cf268d46561ad/src/wp-content/themes/twentytwentyone/style.css#L1594-L1601

If the right-click behavior is not what we want, hou about using focus-visible?

[wildworks]

I believe that the current focus style is a big problem on the editor side and needs to be fixed in some way in WP6.5. If we need more time to investigate the impact on consumers or find a more ideal approach, how about reverting [57554]?

[poena]

I added the commit keyword 8 days ago but I do not have commit access myself.

So perhaps the core or theme commiters would like to add their opinions.

[youknowriad]

I'm going to commit 60535.2.diff I think it's a good compromise for now.

[youknowriad]

In 57739:

Bundled Theme: Fix focus outline in Twenty Twenty-Four in the editor.

Improvements made to the focus outline style for Twenty Twenty-Four caused a regression in the focus outlines of the block editor. This commit solves the regressions by reducing the CSS specificity while keeping the improvements.

Follow-up to [57554].

Props wildworks, poena, sabernhardt, youknowriad, oglekler.
Fixes #60535.