Skip to content
Get in touch

Using :active and ::before to expand the action area of an item without messing anything else

Opinion Articles

Gonçalo Cancella

Bliss Applications

Context

I’m developing a step sequencer with the help of Vue.js and Tone.js.
Recently I had to address an interesting UX problem. There was the need for small controls for each track, in the sequencer. I ended up going with knobs for the volume and had to deal with a UX pitfall. Keeping the left button pressed and trying to manage the volume when the mouse left the small 20×20 area it stopped controlling the knob correctly and instead started having a funky behavior.

 

Default behavior

The first solution was enlarging the action area by using a common pattern of making the pseudo-element ::before larger than its contents. While it improved the component usability, it didn’t solve the problem in case the user left the action area.

Nope!

:active to the rescue!

The :active CSS pseudo-class represents an element (such as a button) that is being activated by the user. When using a mouse, “activation” typically starts when the user presses down the primary mouse button.

https://developer.mozilla.org/en-US/docs/Web/CSS/:active

 

With the :active state, it was possible to ensure the affected area was as big as we required it to be and it was only that size while interacting with the component.

Essentially, the idea is to make the affected area the size of the whole window while pressing the mouse down on the component. With the help of position: fixed and our good old buddy z-index: 9999 to make sure it doesn’t get interference from other components, like so:

Oops…

Et voilà, we are now able to dance around the component across the window and it behaves as we expect it to.

Polka time!

Related articles

Opinion Articles
RxRepository: Building a testable, reactive, network data repository using RxSwift (part 1)

In this series we will tackle the problem of optimizing network access to fetch data from the network, a common theme of networked applications. While it is certainly trivial to fetch data from a server in any modern framework or OS, optimizing the frequency of access to the network, in order to save bandwidth, battery, user frustration, amongst other things, is complex. More so if you want to reduce code duplication, ensure testability, and leave something useful (and comprehensible) for the next engineer to use.

Opinion Articles
RxRepository: Building a testable, reactive, network data repository using RxSwift (part 2)

In part 1 of this series we started tackling a common problem of networked applications, that of optimizing resource usage and user experience, by optimizing network access. We typically do that by avoiding expensive resource usage, as in avoid making network calls. This avoidance is not more than a mere compromise on the type of resource we decide to spare. Trade a network call for memory space, by caching network responses. It also comes with constraint relaxation, as we do not need the latest version of a particular resource. We, thus, avoid a network call. Nevertheless we want that what we have cached to eventually expire, or to be able to forcefully reload a resource.