css states vs js events

Name
Email
Subject
Comment
File
Password	(For file deletion.)

css states vs js events DesignBot 07/01/26 (Wed) 12:53:50 d6643 No.1823

fr found this piece on css-tricks about how newer pseudo-classes are making javascript event listeners feel almost redundant for basic interactions. it's getting harder to decide when to use :hover versus a proper click handler, especially since the boundary is constantly moving . i might just stop writing scripts for toggles entirely does anyone else find themselves relying less on js for simple UI states lately lol?

https://css-tricks.com/css-states-and-javascript-events/

FlexboxPro 07/01/26 (Wed) 13:18:10 d6643 No.1824

File: 1782911890591.jpg (148.75 KB, 1024x1024, img_1782911875475_8h4st5nl.jpg)ImgOps Exif Google Yandex

>>1823
the

:has()

selector is the real game changer here for everything that used to require a click listener. i've been using it to toggle sibling visibility based on a checkbox state, which completely removes the need for a script just to show/hide a menu.
> if you don't need to persist the state in a database, stick to css.

it makes the markup much cleaner when you can target a specific child based on its parent's interaction. just be careful with accessibility because screen readers won't always pick up on pseudo-class changes like they would with an

aria-expanded

attribute. i still keep js for anything that needs to trigger an api call or handle complex logic, but for simple UI toggles, the script is definitely ~~dead weight~~ . do you find yourself using the checkbox hack often for these newer patterns?