PR ready for review/testing: backdrop/backdrop#4713

Instead of having to provide a second set of .png icons for each template for the selected state, I am using CSS filter instead. It seems that there's 97%+ support for it in modern browsers nowadays: https://caniuse.com/css-filters

I've tried to match #43afe4 as much as possible, but it is not 100% perfect (since I had the current gray color to start with as a base instead of white). Experienced designers or people with a very keen eye might pick that up, but not obvious to the naked eye really. It should be matching the halo of other focused elements very closely. Here's a screenshot of multiple text elements intentionally focused in the same form to compare it with side-by-side:

There are other ways to do this, like using an additional .svg etc., but that would complicate the code and would be changing markup, whereas the current PR only changes a couple of lines of CSS.

...speaking of keen designer eyes, pinging @wesruv and @dariusgarza about this (if you can spare a few mins please).

I've looked at this and tested the PR. Would mark it WFM, but it would be good to get at least one or two more opinions first.

Based on the last comment, I've set the milestone on this issue, in order to keep it in our radar for the next bug fix release.

In using the sandbox, I found using the exact same blue border for both "focus" and "selected" to be confusing. When entered a layout name and then hit the tab key, it wasn't obvious where my focus went, since the focus for the layout template is the same as the selected value.

In using the sandbox, I found using the exact same blue border for both "focus" and "selected" to be confusing.

Agreed! Maybe we can change the border color for checked layout templates then. See a mockup screenshot below. (I took the occasion to also emphasize the template name and add a √ character.)

I think it could be appropriate to change these to svg, personally. It would fit with all the other svg work being done and make it much easier to recolor these in various themes.
(Also, it would make building a representative svg icon for flexible templates much more trivial)

I think it could be appropriate to change these to svg, personally. It would fit with all the other svg work being done and make it much easier to recolor these in various themes.

I opened up a follow-up issue.
#6487

In using the sandbox, I found using the exact same blue border for both "focus" and "selected" to be confusing. When entered a layout name and then hit the tab key, it wasn't obvious where my focus went, since the focus for the layout template is the same as the selected value.

I've rebased the PR sandbox and I tried the same workflow using only the keyboard. My understanding is that once you tab into the template selection, what is highlighted is the current selection. You change selection by using the left/right keys and then tab out to move to the path text field. Seems right to me 🤔

... Seems right to me 🤔

Oh, I think I know what you mean now. Let me work on it a bit more then.

I think it could be appropriate to change these to svg, personally.

Yes 👍🏼 ...there's some progress in #6487 with converting the icons for core-provided layout templates to SVG, however we need to consider that contrib and custom templates might still be using .png.

I still need to loop back to this.

In using the sandbox, I found using the exact same blue border for both "focus" and "selected" to be confusing. When entered a layout name and then hit the tab key, it wasn't obvious where my focus went, since the focus for the layout template is the same as the selected value.

@quicksketch I tested how the keyboard navigation works currently without this PR, and this seems to be a pre-existing problem I think. The reason is that using the left/right keyboard keys also selects the template (as opposed to moving the focus and leaving the previously selected template in a "selected" state, and then having to use the spacebar to actually make the selection).

When using a mouse, that is not an issue: the :hover state is styled differently and leaves the currently-selected template in a "selected" state until you actually click on another one. But with keyboard navigation, there is no :hover state (because moving focus also selects the template at the same time).

Can someone please test on a demo sandbox vs. the PR and confirm?

Can someone please test on a demo sandbox vs. the PR and confirm?

Confirmed.

Thanks @olafgrabienski 🙏🏼 ...that's one less thing to work on. Still leaving this as needs work, in order to address the rest of the feedback here.