Brainstorm: options for opting in to always matching focus ring

[alice]

We know we need a way to opt an element in to always (or never?) getting a focus ring. Let's talk about strategies for doing this.

[alice]

Proposal: just use :focus

Use the existing :focus pseudo-selector to opt an element in to always getting a focus ring on focus. Requires a way to recover the platform default focus style, assuming :focus-ring will be the UA default in future (which we should probably provide in any case).

Example

custom-text-editor:focus {
  outline: platform-default;  /* need a way to express this */ 
}

Pros

• Potentially makes the mental model of :focus-ring easier to understand
• Could use same strategy in UA stylesheet, e.g. input[type=text]:focus

Cons

• No scope for any more nuanced matching options
• Requires an extra concept (albeit one we probably want anyway) to allow re-enabling the platform default focus ring.

[alice]

Proposal: add a new CSS property to express when an element should match :focus-ring

Allow an element to opt in to :focus-ring matching the way built-in text editing elements do. Potentially also allows fine tuning focus-ring matching at page author discretion.

Example
(all syntax to be considered a "straw man")

custom-text-editor {
  show-focusring: always;
}

div[tabindex=-1] {
  show-focusring: never;  /* may potentially be overridden by user preference */
}

* {
  /* match when focus is moved via the keyboard explicitly, i.e. tab/shift-tab */
  show-focusring: explicit-focus; 
}

button {
  show-focusring: on-keypress;
}

Pros

• More nuance possible

[alice]

cc @shans

[kloots]

@alice I think your 2nd proposal is far far better than pursuing the current :focus-ring implementation; it's more robust.

1. Allows for fine grain control over when the focus ring is displayed; solving for all of the various niche cases discussed in When to match :focus-ring:? #33
2. Makes it much easier for authors to preserve browser default focus styles (should they want to)
3. Feels more with-the-grain of CSS; reminds me of how overflow works.

Nice one.

[robdodson]

I like the second proposal if we can get buy-in. And I also want outline: platform-default; :)

[kloots]

@alice @robdodson what's the next step for moving on @alice's proposal?

[robdodson]

@kloots I think one thing alice and I were unsure of: were you saying you like the second proposal instead of :focus-ring or in addition to :focus-ring? In other words, were you suggesting we drop :focus-ring entirely and pursue that other proposal?

[kloots]

@robdodson yeah, I really like @alice's second proposal and think it'd be better for the industry if we pursued that over :focus-ring.

[alice]

To clarify: this was always intended to be as well as :focus-ring, and affect when :focus-ring matches. :focus can't be changed at this point (believe me, we went around and around on this previously).

The full story would then hopefully look like:

• Browsers provide a default :focus-ring style in the UA stylesheet.
• Authors may override that style if they wish.
• Authors may use outline: platform-default (whatever it ends up being called) to reset the outline style further on down the cascade.
• Authors may also fine-tune when they wish certain elements to match :focus-ring.
• :focus will continue to match any active element.

[kloots]

@alice thanks for the clarification. Man, sorry to hear :focus cannot be changed because that's the obvious pseudo-selector everyone knows about. Giving developers a new CSS prop that would allow authors to fine tune when it matches and what it looks like seemed really with the grain of how other things in CSS already work; like when border-radius was introduced years back.

[alice]

Next steps:

• Write up full proposal for show-focusring (whatever we call it) property
• Figure out the status of outline-style, which allows recovering the platform outline style if used correctly
• Propose :focus-ring and show-focusring at CSS WG in Paris in August.

[marcysutton]

I really like the way this is going. It seemed difficult to support all necessary use cases with :focus-ring alone, and this provides a lot more control for handling focus states within a deep cascade. We'll have a challenge explaining why :focus couldn't be used no matter which way we go, so at least if the APIs allow us to achieve more detailed focus we'll be successful at getting UI jobs done (and then relaying to others how we did it). Curious to hear how the proposal goes over with the CSS WG.