I agree on point 1. Sorry if I wasn’t specific enough. What I mean by “expensive” would be a true polyfill (in the likes of an ajax call re-parsing CSS). I wasn’t applying that argument to the prollyfill. Perhaps because I am not particularly in love with the approach and the use of a custom non-valid attribute…
I guess, I am just arguing in favor of a principle that leave the default focus alone by default, and address the cases where I need to remove the focus ring on a case per case. Because once you’d do that for modality: keyboard, it becomes part of your fundamental CSS approach for everything. I don’t really like that. But it’s not a major concern. I can always come up with an alternative prollyfill reversing that approach.
PS: I’ll definitely explain the assisted-focus and hover-intent suggestion in depth, when I get a chance in a few days or within a week’s time. I feel I am on a good track with the idea, but it’s going to take very long description to explain why it’s needed, what it solves and how it would work. I need to sit on it for a bit, and think about half a dozen use cases to see if that concept can hold up.
We did this with lower fidelity specifically for a few reasons: 1) we’re not far enough along to seriously assume that what we have here could make the jump from prollyfill (speculative) to polyfill without feedback and changes 2) We can illustrate the usefulness in a practical way with a very small amount of code and allow developers to actually use it in production apps - this is really important if we want participation and feedback. 3) upcoming developments of custom mq’s would make high fidelity of whatever design is ultimately settled on similarly small.
With regard to the non-valid attribute, would it help if we made it a data- attribute? I believe we actually did this at one point in the evolution, I’m not entirely sure why we didn’t at least dasherize it, which would at least serve the same purpose and virtually guarantee it was safe. That’s perfectly valid feedback for the prollyfill I think, though you and I appear to be some of the only ones actually worried about this - it’s a pretty common thing actually. If people think that is an issue we should change, I’m happy to adapt it - also, it’s a github project so you can open issues or send simple technically minded pulls about the prollyfill itself.
I’ve done a similar “experiment” called focus-source for pretty much the reasons outlined in the article - by which I’m agreeing that there is a real need for this.
If I understood this correctly, the modality (or input-modality or interaction-modality) MediaQuery is supposed to change immediately whenever I change my mode of input (say, type something with my keyboard “keyboard”, then click something with my mouse “pointer”). That means that a focus-style would not be “sticky” and that may lead to confusing UI.
In my focus-source experiment I identified 3 modalities (I called it “interaction-type”): keyboard, pointer and script. The reason for “pointer” was - as has been pointed out by hexalys - that :focus needs to remain the default style for backward compatibility reasons. My applications usually focus a container/wrapper to act as a sequential focus navigation starting point, so I added “script” to allow the CSS to identify “focus set by application”.
Hexalys hinted at assisted-focus to provide the information if some non-document-accessible styling was being applied by an AT. I think that could/should be what :-moz-focusring is about.
I don’t like the MediaQuery idea very much. I’d have preferred a simple pseudo-class :keyboard-focus (that does not change while an element has focus). But the MQ would play nicely with :focus-within, where a simple pseudo-class would not.
I’m not very fond of the idea to define “keyboard-relevant input elements” (as the polyfill shows) - considering custom elements. The supports-modality="keyboard" attribute is technically not necessary, as anyone could achieve the same effect with current CSS functionality. Also using an attribute like that is limiting to single values - what happens when this proposal is extended to support voice input? Do we want to foster multi-value attributes like supports-modality="keyboard voice"?
I had trouble following the proposal and discussion because I was centered altering :focus styles, rather than “generically dealing with input modes”. I think the former - influencing focus styles - is a problem with a simple enough solution. Dealing with “interaction modality” in terms of, say, a FPS (First Person Shooter), is quite a different beast. Is there only one mode, or can keyboard and pointer be used simultaneously? is the mode constantly switching back and forth between keyboard and pointer if I use the mouse to aim, but the space-key to shoot? Is this even relevant to 95% of web sites/applications? I have all sorts of problems wrapping my head around this.
I actually think the focus ring is the special case in a primarily pointer-driven UI - however, as others have pointed out, it’s dangerous to assume that it only applies to keyboards, since other devices (e.g. a D-pad) also need a concept of focus.
Have another look at the proposal and maybe the prollyfill - play with the demo: Modality is determined algorithmically - currently the proposal only spells out the one for keyboard (and, logically “not keyboard”) but effectively it is a based on what just happened and what you are very very likely do to next because of where it happened. For example - if you even if you click on an <input> the modality becomes keyboard because the only way to interact with this is by sending keys to it.
Perhaps the modalities should be “pointer” and “focus” (with the contrast being that “pointer” modality does not use an element-centric “focus” model)? Or perhaps “focus: element” and “focus: ambient” (the latter referring to pointer-like interaction models where focus is not strongly tracked)?
I think this is actually a good point: this topic should primarily be about focus modality, since that’s the actual use case it’s trying to speak to - bigger ideas like general input modality are a confusion of concerns, and liable to gear-up problems in short-sighted assumptions. (Example: look at what happened when the iPhone came out, and every site that saw a “mobile” UA assumed “mobile” meant “low capability”, so the iPhone had to hide its mobile status as much as possible, outright ignoring styles that had been defined for “mobile” modalities.)
Also, this opens the door (at least in terms of discussion) for more granular notions of focus for input modalities that are better at gauging intent, like eye/hand tracking.
Also one reason leading me to the conclusion that the focus ring isn’t the special case, is consistency. Because we can’t technically reproduce the default focus ring for sure. Even if the color is faithfully reproduced via -webkit-focus-ring-color or with browser specific rules. That browser or user default may change.
A custom focus ring, styled possibly differently on every site, especially for non input elements, sounds like a very inconsistent and possibly annoying experience for “keyboard” only users. But I am open to the contrary with an accessibility user study or more data on this…
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.
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 @aboxhallalready 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.)
The CSSWG agreed this is a problem we should solve and generally approved work on this, probably in terms of a spec.
@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.
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.
@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.