- From: Dani Guardiola via GitHub <sysbot+gh@w3.org>
- Date: Mon, 15 Jul 2024 13:53:38 +0000
- To: public-css-archive@w3.org
My use case is keeping long selectors DRY, for example: `:is(:hover,:focus-visible,[data-focus-visible]):not(disabled,[aria-disabled],[data-disabled])` This is a selector that targets elements that are being hovered or focused through the keyboard, and are not disabled. This is common, since many times the styles will be the same for these states. Note that it includes selectors that could be set by JavaScript libraries such as Ariakit or Radix, which typically "extend" the web platform with accessible UI primitives. These libraries can't trigger native selectors like `:focus-visible` and, therefore, need to signal them through other means like data attributes. Additionally, they might need to communicate a disabled state, but the `disabled` attribute is invalid in most elements, and therefore either `aria-disabled` or a data attribute must be set. I would like to be able to define this once, and use it everywhere to target these states consistently. My current solution is a custom PostCSS plugin that adds states through `:is-targeted` and similar non-standard pseudo selectors, which get transformed into their long variants. While the approach works, it results in a hard to parse output which is also larger. The alternative (writing these by hand) can result in significant usability or accessibility problems, as it's fairly easy to miss an important part of a selector or forget to update existing ones with important changes (e.g. if a library is upgraded). I hope I explained my use-case clearly enough! Would love to see this land. -- GitHub Notification of comment by DaniGuardiola Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10567#issuecomment-2228563161 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 15 July 2024 13:53:39 UTC