Exposing a user's input modality

I think this is an interesting direction, although potentially focus isn’t the best name since it’d be easy to confuse it with the existing meaning of :focus (imagine a discussion talking about the :focus pseudo-selector in the context of the focus modality - it all gets a little Who’s On First).

We actually discussed the notion of simply not matching :focus unless we gauged (via the mechanisms discussed in the article) that it was likely to be useful; however, we felt that this would unfortunately potentially break things. (This would honestly still be my ideal world scenario, I think.)

Felt, or saw? I honestly can’t think of anything I could point to that this would break. Maybe experiment with it, with something like a browser extension (akin to what @paul_irish is proposing in this lazyweb-requests issue for page caching)?

I don’t think treating focus styling as the special case negates this. In fact, one of the goals which led us to this proposal was to remove incentives for removing the default styling in the first place. The idea would be that the browser (via the UA stylesheet) would apply the focus ring only when it will be useful.

Could be an option. The case we were worried about breaking is where someone detects the focused element by using matches(':focus') or similar (although I can’t seem to make that work…)

anything imperative that uses selectors here is prone to unusable breakage in fact - authors may currently want to find element #x if it has focus or something in an event handler or whatever and take different code paths. Changing the results of :focus from whatever interoperable terms they mean today causes me concern.

Agreed - the difficulty is in finding any appropriate word for this, that is both not completely unheard of, and not used anywhere else in the platform. I can’t think of any (“navigation” was one, but that’s already used to refer to page-to-page transitions).

EDIT: Actually, what about “interaction”, since that’s essentially what this governs (not just focus, but also manipulating the values of checkboxes etc)? EDIT 2: As @aboxhall already suggested.

In any case, I’m probably going to split off to a separate thread at some point to discuss this specific approach, since I think it’s pretty distinct from the proposal set out in the OP.

Also, I think this proposal should come with a recommendation to UAs to apply this modal approach for hiding focus rings to their default stylesheets (in line with my general view that we need to start standardizing UA default styles, and vetting them for sanity in the process), since it’s clearly what everybody wants and there’s no reason to foist that onto page authors. (I do prefer the idea of going one further and removing the entire notion of “focus” when not in the element-focusing “keyboard mode”, but as discussed above that may be an insurmountable concept.)

However, as discussed offline, this already wouldn’t work in Firefox as FF only sets the “sequential focus navigation starting point” on click, not focus.

1 Like

So, just to keep this thread up to date…

  1. The CSSWG agreed this is a problem we should solve and generally approved work on this, probably in terms of a spec.

  2. @aboxhall and I met up with @tabatkins to discuss and we agreed tentatively that exposing a new pseudo-class which only applies “when the native focus ring would apply” might be enough. Generally speaking, this follows the rules we laid out in our article but I expect that this may be non-normative in a spec but would give examples of why certain things currently do what they do (IE, a text field gets the focus ring no matter how it was focused because the only way to interact with it is to type some keys and you want to know where they are going to land). Mozilla has had something kind of like this for a while and we’d just be starting with defining/standardizing that including how author defined controls could participate in that decision in defined ways - so that’s the proposal currently to CSSWG.

  3. we’re currently looking into whether there should be a corresponding event for this, what use cases might use such a feature, etc., whether this falls short in important ways, etc.

If you have thoughts, opinions or use cases - share away.


Is the initial idea for 3. this event to fire on the change of modality state? I suppose this would also need some form of DOM state too right?

As described above and in its own thread, I think it should be a pseudo-element and not a class (since, essentially, we already have a pseudo-class in :focus, and it isn’t enough).

@jonathank Yes, that’s the idea. Is such a thing useful/can you provide use cases?

@stuartpb This was discussed in CSSWG this morning and there was consensus that this is a pseudo-class by all existing definitions. Minutes should be available soon if you want to check them out or check IRC logs.

Where would I do either of those?

“As you go” scribing happens on IRC, you can find all whatwg/w3c irc logs for posterity on http://krijnhoetmer.nl/irc-logs - final minutes are usually posted to public www-style mailing list within a few days. If you’re a member you’ll get one, otherwise you can view them on https://lists.w3.org/Archives/Public/www-style/

Okay, I took a look at the IRC logs, and while it’s true that focus rings are currently implemented as a pseudo-class, I’m saying that, moving forward, they should be re-defined as a pseudo-element (ie. the way UAs implement them should change):

  • I don’t see anybody in the IRC transcript explaining how the proposed :focus-ring selector isn’t just effectively equivalent to the :focus selector we already have, except that :focus has historically been presented in irrelevant contexts (in which case, the solution is changing UAs to stop presenting it in these irrelevant contexts, the way Firefox does).
  • The issue of elements inadvertently removing the focus style was stated as being solvable by making some undefined change to the outline property. Not only does this gloss over the problem and leave it unsolved - the potential solution (making it somehow dependent on the property) would have all the same problems (properties being overridden by selector specificity). Adding !important, as proposed as a solution for UA style sheets, does not solve the problem: it would only make rational changes by page authors harder, by making them unable to use the cascade when appropriate.
  • Making the focus ring a pseudo-element allows it to have dimensions and position independent of the element being focused. Not only is this useful for elements whose effective border is distinct from the element’s actual border (as is the case for many elements, such as header links), it also allows for the focus ring to animate as it moves from position to position (as seen in prior art like Windows’ voice-based on-screen accessibility mechanism since Windows Vista).

Yes useful, some use cases I can think of are:

  • page may contain assistive layout that is controlled by JavaScript
    • keyboard devices may provide less predictive results in a search box perhaps
    • tap vs double tap and gestures may be disabled with a mouse
    • pan and zoom could be an interface choice when focusing is less possible (This was something I was working on as a replacement for a mouse using a mobile)
    • inertia effects may be pointless or less obvious when tabbing with a keyboard
  • page may choose to swap out personalised text that describes using different layout

@stuartpb IRC is live-scribed by a single person, it’s very hard to capture literally everything that is said but we try to do a good job of capturing the most important bits. The topic, as most are, was introduced on www-style minutes usually capture this link when the topic is changed, but for some reason not here so I’m sharing it for completeness. Both the email thread and the irc minutes state on multiple occasions the key points which I feel like are enough, but I’ll try to do better here…

You don’t see anybody explaining how it isn’t a strict subset of focus because it’s explained specifically that it is a strict subset of focus. Our proposal, the linked email and the minutes all explain precisely that because the focus ring is focus styling but the :focus pseudo is not based on the same information as the browser’s focus styling operates from authors are faced with only bad options and, not surprisingly, bad things happen for a11y. It shouldn’t be hard to impossible to do the right thing if you just want to say “because of branding I’d like the focus ring (when it is shown) to be purple”. This proposal makes it easy to do the right thing in the common cases like changing the outline color, the background-color, etc only when it is presented/without destroying the a11y built into the platform.

This is misunderstood possibly because of incomplete minuting. Someone (Chris Lilley I believe) asked about whether there should be any common-sense restrictions around what you could and couldn’t do, mentioning specifically that if you wrote a rule that said :focus-ring { display: none; } this would cause focus to be lost. Of course, focus currently has this same issue - it’s self evident that that is a bad idea and we have no data or complaints suggesting that authors actually do this - it doesn’t create a cycle either so it’s not an algorithm problem and, as I mentioned, UA sheets can potentially !important the display property if they are really worried about it. Despite your text emphasis, I feel pretty confident saying “hide the thing which has focus” is in no way rational and in all other respects I fail to see how the proposed solution doesn’t solve problems.

In light of the question about limiting styles I brought up your feedback that it should be a pseudo-element, that got no uptake and I’m in agreement with the group here that elements have states which you’d like to style and that there are/have been use cases for years that involve styling the background color, the text color, the outline, the border, etc which are currently problematic because of a minor flaw in the design of :focus which we’re interested in fixing. If you really have strong feelings on this particular piece - that there are use cases you feel are necessary and unmet with :focus or the proposal because they are a pseudo-class you might email specifically this bit to www-style for comment.

@jonathank I the issue here is that the thing is determined both by what just happened (IE, did the user focus with a sequential action like tab or pressing a d-pad or did they use a random access style pointing mechanism to jump here like a mouse or touch) and the control itself - a text input for example is always “keyboardy” because predictively the only way to interact with it is to send keys and you have to know where they are going to land lest you type your password into a non-password field and give it to the creepy dude behind you). What you’re talking about sounds different - for example: what is a keyboard device? Aren’t they all? How would you know “focusing is less possible” because that sounds like a capability which is something different - the piece explains this and why capability doesn’t work for this case but in a nutshell, users switch modalities all the time and stuff like the focus ring is still relevant in many of them.

The solution here is to change the rules for :focus to the proposed rules for :focus-ring, not add another pseudo-selector that’s just “the existing rule, but not broken”. This wouldn’t going to cause a problem for existing content because the rules for :focus were already only essentially useful for this case - the only time the difference influenced a style as written was to disable focus styling. (I had misread posts above as saying that Firefox has already done this, but it would be possible to test this in Firefox with a Greasemonkey script that converts :focus rules to :-moz-focus-ring, which would be, as I believe you put it, “the canary in the coal mine” for finding any potential problems in doing so.)

Now, you might end up encountering problems on pages that have explicitly disabled the focus style due to its historical ugliness - that would be the job for the proposed pseudo-element, to sidestep issues with :focus being disabled (more reliably than a pseudo-selector - see the next point), as well as adding previously-impossible abilities to mutate the focus ring boundaries separately from the focused element.

It’s not about :focus-ring {display: none;}, it’s about .button.danger {outline: red;} superseding the :focus-ring selector (giving the element a stateless outline that will override the focus ring) due to higher specificity. Yes, a UA stylesheet could add :focus-ring {outline: blue !important;}, but all that’s going to do is make it so content authors have to write .button.danger {outline: red !important;}.

Conversely, having a pseudo-element would permit having both outlines displayed, since styles on pseudo-elements don’t conflict with the element’s styles.