The CSS pointer-events property acts as a traffic controller for user interactions. It dictates whether an element can become the target of pointer-based inputs, such as mouse clicks, hover states, and touch events. By modifying this property, developers can decide whether the browser treats an HTML or SVG element as interactive or lets interactions pass straight through to underlying layers.
To understand this property, it helps to look at how browsers handle user input. Before firing a click or hover event, the browser performs a process called hit-testing to determine which element is directly underneath the cursor. Under normal conditions, the browser targets the topmost visible element. However, if that element has pointer-events: none applied, the browser skips it entirely, targeting the next eligible element beneath it.
Standard and SVG-Specific Keyword Values
While pointer-events supports global CSS values, it features eleven key values. The two most common options, auto and none, apply to all HTML and SVG elements. The remaining nine values are exclusively designed for SVG rendering, offering granular control over which parts of a graphic trigger a response.
auto: The default behavior. The element interacts normally. In SVG, this is equivalent tovisiblePainted.none: The element ignores pointer events. The browser targets whatever lies beneath it.visiblePainted: Events trigger only if the SVG element is visible and the cursor is over a painted area (fill or stroke).visibleFill: Events trigger if the SVG element is visible and the cursor is over its fill, even if the fill is set to none.visibleStroke: Events trigger if the SVG element is visible and the cursor is over its stroke, even if the stroke is none.visible: Events trigger if the SVG element is visible, regardless of fill or stroke values.painted: Events trigger over a painted area (fill or stroke), regardless of visibility.fill: Events trigger over the fill area, regardless of visibility or fill values.stroke: Events trigger over the stroke area, regardless of visibility or stroke values.bounding-box: Events trigger anywhere within the smallest rectangle enclosing the SVG graphic, even over unpainted areas.all: Events trigger over any fill or stroke, regardless of visibility, fill, or stroke settings.
Practical Use Cases: Overlays and Menus
A classic application of this property is managing full-page modal overlays. To center a modal, developers often use a container that covers the entire viewport. By default, this invisible container blocks all clicks to the page below. Applying pointer-events: none to the wrapper allows users to click background elements. Because pointer-events is inherited, developers must manually restore interaction on the modal itself by setting it to pointer-events: auto.
This behavior is also valuable for dropdown menus. When hiding a submenu with opacity: 0, the menu remains physically present on the page and can accidentally capture hover events or block background links. Combining the opacity transition with pointer-events: none ensures the hidden menu does not interfere with the rest of the user interface.
Understanding Event Bubbling and Accessibility
It is critical to note that pointer-events only alters hit-testing; it does not change how events bubble up through the Document Object Model (DOM). If an interactive child element inside a non-interactive parent is clicked, the child becomes the target. The click event then bubbles up through the parent, meaning any event listeners attached to the parent will still fire.
Furthermore, pointer-events: none does not make an element completely non-interactive. The element remains accessible via keyboard navigation, allowing users to focus on form controls or links using the Tab key. For true element disabling, developers should use native HTML features. Form inputs should use the disabled attribute, while entire sections should be managed with the inert attribute to completely remove them from the accessibility tree.