Exposing a user's input modality

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.

I don’t get where you are getting this from. I was in the room - the concern expressed was absolutely just as I described that you could style the display of a control with focus to be none thereby removing focus and moving it back to body, to which I replied quite clearly that a UA could prevent this by important on the display just as it says above and just as it says in the minutes. Why would they important the outline? It would be counter-productive to the whole endeavor and not what FF did in the experimental one either. Again, literally no one is suggesting that, it’s pretty clear that that is the opposite of what anyone is suggesting because it flies in the face of the proposal and would be self-defeating. This will not happen.

As for changing the rule of focus, I’m fairly certain we just can’t… it’s defined already and widely used in who knows how many ways. Stylistically things would unexpectedly change and maybe not for the better, but beyond that even it could have programatic effects like – element.matches(".foo :focus") for example.

If that’s what you’re talking about, why would anybody do :focus-ring {display: none;}? That would cause the entire element being focused to be hidden. If you’re saying it would only hide the focus ring, well, then :focus-ring sounds like a pseudo-element (which applies separate styles to an element tied to the element being selected) rather than a pseudo-class (which conditionally applies styles to the element it selects). It sounds like the discussion “in the room” maybe doesn’t realize that they’re conflating the two, which is what I’ve been saying - you need a pseudo-element (for styling the ring itself) and a pseudo-class (for styling the element surrounded by the ring). And :focus is supposed to be that pseudo-class, in every semantic sense, which is why I’m suggesting UAs tighten its applied effect to match these semantics (and match the proposed pseudo-element’s visibility).

As for changing the rule of focus, I’m fairly certain we just can’t… it’s defined already and widely used in who knows how many ways. Stylistically things would unexpectedly change and maybe not for the better, but beyond that even it could have programatic effects like – element.matches(".foo :focus") for example.

While it’s theoretically possible that somebody has relied on the historic leakiness of those semantics in non-applicable contexts, I’m honestly skeptical that such a thing would be used in practice. I can’t think of any real problem to which using :focus's applicability beyond keyboard focus was legitimately a solution that changing the applicability of :focus would break - and I can think of several cases where its leaky applicability is a problem that changing the focus rules would fix, especially for existing content. This is why I propose testing with an experiment in Chrome (Canary) whether changing the :focus rule would actually cause anything to break, rather than just throwing up our hands and saying “who knows”.

They wouldn’t/don’t with focus, but that’s the question that came up.

The Web has an impressive imagination. It’s not at all unbelievable that code in the wild would use a selector as defined and documented for quite a while now in imperative code to do something useful.

In any case, I’m really not trying to blow this off but I’d like to suggest that if it’s just the two of us discussing you can feel free to email or privately message me and if we can achieve some kind of valuable insight we can always circle it back in. I’m more than willing to discuss I’m just worried that we’re not really adding much value to the conversation RN circling around the same basic bits. OR If you want to make a case to the CSS WG itself, you can send comments to www-style, it’s public and open. Keep in mind though that there are WG members here already and so far it’s silent, so - if we’re relying on the ‘bubble up’/feedback nature of wicg/discourse we can wait for someone else to contribute useful thoughts.

Was just wondering if there’s been any updates or activity on this proposal since an ED was decided upon? I couldn’t find any CSSWG drafts for it.

This would be an extremely useful feature for properly implementing Material Design on the web platform. We define a lot of guidelines around keyboard-specific focus and these are impossible to implement currently without javascript. Anything I can do to help please let me know!

@tabatkins was gonna get it added, originally to selectors L4 as :focus, unsure if it will remain in 4 or move to 5, but he could probably tell you the status. In the meantime the prollyfill works pretty well in our experience (though, more like a shim at this point I suppose… different surface, same effect).