[selectors] Should :active match spacebar down?

[jonathantneal]

From the Selectors Level 4 specification

The :active pseudo-class applies while an element is being activated by the user. For example, between the times the user presses the mouse button and releases it.

The :active pseudo-class is useful for providing immediate feedback about the expected click behavior of an element.

Its usage is well documented, in sources from Adobe, Google, Salesforce, Tailwind, and CSS Tricks.

The :active pseudo-class is versatile for pointers, in that it is not limited to specific elements.

Example from MDN:

p:active { background: #eee; }

There is a keyboard limitation to the :active pseudo-class that many sources do not mention. Between the time a user presses the spacebar and releases it, the :active pseudo-class is only ever applied to a <button> element. Some resources may even suggest that the pointer-triggered :active and the keyboard-triggered :active should always work the same.

The :active pseudo-class is used to style an element that has been “activated” either by a pointing device or by a tap on a touchscreen device. It can also be triggered by the keyboard, just like the :focus pseudo-class.
— An Ultimate Guide To CSS Pseudo Classes And Pseudo Elements. Smashing Magazine

It is my belief that :active state is equally valuable to style for both keyboard and the pointer interactions.

Should the :active pseudo-class apply to any active element between the times the user presses the spacebar and releases it?

I think opening this behavior up to all elements should be considered, or perhaps alongside some other mechanism like :focusable.

I do not know for certain why :active does not behave this way already, but I suspect it is related to the early WWW distinctions between hyperlinks and buttons, similar to how a spacebar press-and-release does not “click” a hyperlink. This is a problematic guess, tho, since the :active state applies to non-clickable elements when used with a pointer.

I was confused by a note in the specification that reads “there may be document-language or implementation-specific limits on which elements can become :active.” This note links to the HTML5 specification which defines a list of activatable elements. However, the HTML5 specification does not list any special criteria for spacebar interaction, and the criteria for :active — which includes “if the element is focusable” — suggests to me that it could apply to any element activated.

[myfonj]

This seems somewhat complement for older issue #4787.

Recently, while giving a warning about "this particular CSS trick is not keyboard-accessible, so use it only as the last resort" for a hundredth time (0), I realised that actually I have no idea why things are exactly like this, and that maybe specifying something like

any non-prevent-defaulted (1) activation gesture (like a spacebar press) on any focusable element (like <what-ever tabindex="0">) triggers the same CSS :active state currently left mouse button press does

would not make the web explode. What do you think? I see no backward compatibility dangers in this at this point, only that for keyboard and assistive technology users some stuff that already works for mouse users would start working for the first time in the history, what sounds like a pretty nice thing to me.

To demonstrate how sad current inconsistent state is (and how hard it is to explain it to a novice), I made a small "game":

css-active-keyboard-activation-edge-2025-05-04.223404.mp4

Video description

"Press to find out…" above list of rectangles of slightly varying sizes, each with a text "Who am I?" inside followed with a blank space. There is also an On-Screen keyboard on the side. At first, mouse pointers gradually points on each item pressing it, what makes it change a colour and reveal text in the blank area. These revealed fragments read "I am a…" and the type of the element: button, link, span, SVG and MATHML. Then the on-screen keyboard is used, pressing the Space Bar button/key for the activation and changing to a next item with the Tab button/ley. Only the "button" element reveals its hidden text this way.

This recording is from current MS Edge, which, unlike Firefox (2), at least does :active with a Space Bar on buttons.

---

(0) Was probably at SO under https://stackoverflow.com/q/79578932/540955
(1) Not sure about that "non-prevent-defaulted" thing, since it seems that :active works regardless the events (non-)propagation, and even on disabled form elements.
(2) Some time ago I've made a test and got results from both browsers for an ancient but closely related Firefox feature request.

[myfonj]

“if the element is focusable” — suggests to me that it could apply to any element activated.

Turns out, yes, the HTML spec there says that

[Focusable] Elements that meet all the following criteria:

• the element's tabindex value is non-null, or the element is determined by the user agent to be focusable […];

And there is even a direct example under :active:

For example, if the user is using a keyboard to push a button element by pressing the space bar, the element would match this pseudo-class in between the time that the element received the keydown event and the time the element received the keyup event.

From these two rules it really seems to me that pressing a space bar on a focused <what-ever tabindex="0"> should work (provided it is light-DOM without focus delegation and non-disabled).

---

Overlooked that in a Roman's comment, what led BZ to (IIUC) ask about which concrete keys should be involved in this process: whatwg/html/issues/2725