[css-selectors-3] Make :active specification more explicit as to which interactions cause its application

With regard to when to apply the :active pseudo class to an element, the spec currently says this:

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. On systems with more than one mouse button, :active applies only to the primary or primary activation button (typically the "left" mouse button), and any aliases thereof.

Imo, the spec should be more explicit here as of which actions are considered activation by the user; the absence thereof seems to have caused implementors to have implementations deviating from each other (which alone is unfortunate).

Even worse, neither Chromium nor Mozilla implement the general spec statement

The :active pseudo-class applies while an element is being activated by the user.

with regard to using the Enter key to activate a button. Mozilla also does not apply :active when using the space bar to activate a button. Chromium even obviously violates the spec applying :active on right mouse button click as well.

Both actions, pressing Space or Enter on a button, are clearly actions that result in an element [...] being activated by the user.

It is very unfortunate that there is no non-JS way to give a user visual feedback when they clearly activate an element using a keyboard - any approach I'm aware of requires resorting to Javascript here (which in no-JS-environments wouldn't even be viable).

As soon as the spec is more explicit and clear here, I would like to file a bug with Chromium and Mozilla at least, haven't checked Webkit yet.

There is a StackOverflow Question on this, that I've asked and which led to me opening this issue.

Start with the Selectors Level 3 :active section linked in the issue and review the reported Chromium and Mozilla behavior for mouse, Enter, and Space activation. Determine which user interactions the specification should explicitly cover, then update the specification wording so the expected behavior is unambiguous.