- From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
- Date: Mon, 16 May 2022 18:16:17 +0000
- To: public-css-archive@w3.org
emilio has just created a new issue for https://github.com/w3c/csswg-drafts: == [selectors] [css-conditional] Detecting :has() restrictions == Multiple implementations want to ship the `:has()` selector with a variety of limitations in order to prevent performance footguns and complexity: * https://github.com/w3c/csswg-drafts/issues/6399 * https://github.com/w3c/csswg-drafts/issues/6952 * https://github.com/w3c/csswg-drafts/issues/7211 * https://github.com/w3c/csswg-drafts/issues/7212 However, since `:has()` has forgiving parsing like `:is()` / `:where()`, it's not possible to detect these limitations easily, and it won't be possible to do so if we ever remove these limitations. For `:is()` / `:where()` it's not a problem since it's generally assumed that if the selector is valid outside of them it'll be valid inside of them... But for the limitations that folks are imposing on `:has()` (and which for the record I agree with) this is not true. Perhaps we should special-case `@supports selector(..)` to _not_ use forgiving parsing? Otherwise the only way to potentially detect this is with script (by reading back the serialization of `:has()` and see if the relevant selectors have been dropped). cc @byung-woo @anttijk Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7280 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 16 May 2022 18:16:18 UTC