- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Sep 2022 18:01:24 +0000
- To: public-css-archive@w3.org
Importantly, this is *not* specific to `:has()`, and so any change to `:has()` won't stop the breakage. This breakage is due to the nature of forgiving-selector-list in general, so any place that uses it (like `:is()`, as Byungwoo notes), will trigger the exact same problem - jQuery users putting jQuery-specific selectors into an `:is()` will similarly bypass the current check and stick with the browser's selector behavior. The `:has()`-specific part is just that `:has()` already exists as a jQuery-custom selector, while `:is()` doesn't, so older content using `:has()` will break. That said, new content using `:is()` with older jQuery versions will also continue to get the bad behavior. So our options are: 1. Rename `:has()` to not overlap with the jQuery name, so older content using older jQuery versions will continue to trigger the custom code path rather than use built-ins. 2. Give up on forgiving-selector-list entirely, switching :is() and :has() to the unforgiving behavior, and never using it again. 3. Accept that older versions of jQuery can cause page breakage, if you use custom jQuery selectors inside of `:has()` (or nest `:has()`, which is allowed in jQuery) All three options suck! Unless the breakage gets fairly bad, tho, I do lean toward 3. The `:has()` name is *very* nice and already widely socialized, and I'd be extremely loathe to give up on forgiving-selector-list. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235773031 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 2 September 2022 18:01:26 UTC