The CSS specification includes some suggestions for the heuristics
used to determine whether or not focus should be indicated:
https://drafts.csswg.org/selectors-4/#focus-visible-pseudo

Here's how I think these suggestions apply to JavaFX:


> If the user has expressed a preference (such as via a system preference or a 
> browser setting) to always see a visible focus indicator, indicate focus 
> regardless of any other factors. (Another option may be for the user agent to 
> show its own focus indicator regardless of author styles.)

As far as I know, no supported OS platform has a system-wide setting
for focus indicators. Absent such a setting, I think app developers
can easily support always-on focus indicators by using the :focused
pseudoclass, instead of :focus-visible.


> If the element which supports keyboard input (such as an input element, or 
> any other element that would triggers a virtual keyboard to be shown on focus 
> if a physical keyboard were not present), indicate focus.

As with the first suggestion, this can be achieved by using the
:focused pseudoclass.


> If the user interacts with the page via keyboard or some other non-pointing 
> device, indicate focus. (This means keyboard usage may change whether this 
> pseudo-class matches even if it doesn’t affect :focus).

This behavior is implemented in the proposed PR.


> If the user interacts with the page via a pointing device (mouse, 
> touchscreen, etc.) and the focused element does not support keyboard input, 
> don’t indicate focus.

This behavior is implemented in the proposed PR, but without regards
to whether or not the focused element supports keyboard input. If app
developers want to have always-on focus indicators for keyboard input
elements, the :focused selector can be used.


> If the previously-focused element indicated focus, and a script causes focus 
> to move elsewhere, the newly focused element should indicate focus.
> Conversely, if the previously-focused element did not indicate focus, and a 
> script causes focus to move elsewhere, the newly focused element should also 
> not indicate focus.

This behavior is difficult to implement in JavaFX, because there is no
way for a node to know whether or not it gained focus
programmatically, or as a result of a control skin invoking
requestFocus(). Supporting this scenario would require adding new
public API and potentially changing lots of skins to account for the
distinction between programmatic and mouse-based focus traversal. I
think the impact on existing code would be too large for a marginal
benefit.

Reply via email to