- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 May 2019 16:40:10 +0000
- To: public-css-archive@w3.org
AmeliaBR has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-conditional-4][selectors-4] How should selector supports test react to partially-implemented selectors? == In #3207, it was agreed to add a `selector()` notation to `@supports`. [Draft spec for CSS Conditional Level 4](https://drafts.csswg.org/css-conditional-4/#at-supports-ext). This would presumably also apply to the [`CSS.supports(condition)` API](https://drafts.csswg.org/css-conditional-3/#the-css-namespace). However, I don't think there was any discussion about how this would interact with ["selector profiles"](https://www.w3.org/TR/2018/WD-selectors-4-20180202/#profiles) — certain selectors that were expected to be implemented only in DOM methods and not in CSS parsing. In #3925, the WG resolved to drop the idea of selector profiles, but instead to mark `:has()` (and potentially other selectors with performance concerns) as optional. There was a suggestion that “optional” could mean following the profile pattern of supporting some selectors in `querySelector` etc. that aren't supported in markup. So my question: if that is allowed, what should `CSS.supports("selector(parent:has(child))")` return? The same as `@supports selector(parent:has(child))`? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3936 using your GitHub account
Received on Wednesday, 15 May 2019 16:40:11 UTC