The focus border is too subtle

[Tyriar]

It's too difficult imo to tell the difference between selected unfocused:

And selected focused:

The only difference is it looks slightly blurry.

[Tyriar]

You shouldn't just use the status bar bg for this as then theme authors will have problems with it - a lot of themes use a very muted status bar background. focusBorder is good, I think the problem is more with the background color applied to the focused cell. Consider all the states a cell can be in, you should be able to easily differentiate each of them, and not just by color is important for accessibility.

[lramos15]

I was trying to use VS Code colors to allow theme authors to still be able to theme everything / not have to maintain my own color palettes as extensions only get access to three "categories" of themes which is light, dark, and high contrast. I'll ask @misolori his thoughts and what the best color scheme might be.

[Tyriar]

Perhaps borrowing from the list colors would be better?

[miguelsolorio]

I think you're running into the issue where we don't normally uses list colors and focus together, there are specific tokens for each one.

One alternative you could try is to fade out the text that isn't selected and use the list color styles, and then apply an offset on the outline so it stand out:

[lramos15]

I don't really like the grey text with light grey headers as I feel the contrast between the two is lost. I do really like the thicker outline with a little bit of offset as I believe that makes it look super clear what is focused.

Thoughts on this?

[miguelsolorio]

It's better, but it's really hard to focus on it because of the white text in the background. The decoded text part is easier to scan because of this. Another thing you can explore is making sure all of the number elements are evenly squared (makes it easier to scan). Right now it's wider and makes your eyes work a bit harder.

[Tyriar]

@misolori making them square would reduce the amount of rows that can fit on the page?

[miguelsolorio]

@Tyriar probably, but it's so much easier to read:

Before

After

[Tyriar]

Personally I tend to not like reducing information density like this, it's cutting off ~1/3 of the content which could be important for the task at hand and end up increasing the amount of scrolling needed. Leveraging editor.lineHeight would be better imo as that's the user's preference.

[Tyriar]

Looks like the PR will only be square for certain font family/size combinations.

[lramos15]

I can look into editor.lineheight I'm not really sure what the best solution is here. I feel that the offset helps a lot and solves the underlying problem. The squaring is to supposed to help with readability and I'm not sure if it makes a huge difference as the ascii section cannot be square due to the use of spans.