- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jan 2024 17:39:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[selectors] What is the reasoning for ignoring defaullt namespaces only on the subject for :is() / :where() / :not()?`, and agreed to the following: * `ACTION: TabAtkins to create a new issue for removing the rule` * `RESOLVED: Close issue #5684 with no change` <details><summary>The full IRC log of that discussion</summary> <Frances> Alan: Namespaces for :is() / :where() / :not()<br> <Frances> Emilio: Compact wise is probably okay, Tab's answer is good but weird that nested selector list has weird parsing behavior.<br> <Frances> Tab: Context if you write a selector without a namespace, with a url, will apply namespace to all selectors unless specifically overridden, even non type selector in the element name.<br> <TabAtkins> a.foo<br> <TabAtkins> a:is(.foo, .bar)<br> <TabAtkins> foo|a:is(.foo, .bar)<br> <Frances> Tab: Issue is if you start with a.foo and then want to have foo or a bar class, normally second selector matches same or more elements. In presence of default namespace selector, it might not.<br> <TabAtkins> foo|a.foo => foo|a:is(.foo, .bar)<br> <Frances> Tab: If it wasn't for the special case, they could get the default namespace rather than .foo namespace. Selector might not match anything. Do not apply now special namespace rule to their arguments.<br> <TabAtkins> foo|a.foo<br> <TabAtkins> foo|a:nth-child(n of .foo)<br> <Frances> Tab: Some related issues about other spots such as nth child of the selector. Expect to match all elements, with default namespace rule, it might not match anything.<br> <Frances> Tab: Alternative don't want backwards incompatible, can remove default namespace rule to only use when there is a type selector. Namespaces in general are rarely used across css, could fix by removing the special rule.<br> <Frances> Emilio: What is the implementation style of the rule?<br> <astearns> ack dbaron<br> <Frances> David: Probably well implemented for :not for the subject part of it. Referencing type selector, should be explicit about including universal selectors.<br> <Frances> Tab: default selector is a universal selector<br> <Frances> David: :hover and *:hover are weird.<br> <Frances> Oriol: If using featureless element, need to use universal selector to match them.<br> <Frances> Emilio: Only on quirks mode?<br> <dbaron> s/are weird/would now be different, which is a little weird/<br> <TabAtkins> :host *:host<br> <Frances> Oriol: For :hover, they are the same except for some cases can add universal selector to change the meaning.<br> <Frances> Tab: :host and *:host might not match a featureless element.<br> <Frances> Emilio: Ignore default namespace unless global or type selector.<br> <dbaron> s/Referencing type selector/When you talk about a type selector/<br> <dbaron> s/about including/about whether or not you're including/<br> <Frances> Tab: We can close the issue with no change and open another issue with changing the underlying rule entirely to be mutually exclusive with some of the other issues with the :is rule, need to be consistent and intuitive. Why do we have the rule in first place need to explain.<br> <Frances> Alan: Need to describe if backwards compatible.<br> <Frances> Emilio: Do we want it in the right most compound, why only in the right most compound?<br> <Frances> Tab: The one that is selecting the element, namespace rule probably invented to restrict to the default namespace, would make slightly harder to use the selector?<br> <Frances> David: Might be a function of how the selectors evolve over time, not taking combinators, and now taking them.<br> <Frances> Tab: Does make sense to apply to all components.<br> <Frances> David: rule to not apply to is part after last combinator makes sense.<br> <Frances> Tab: Intuition is to use :is and :where as syntax rules, such as preceding combinator, treated same as outer<br> <Frances> David: when there is a default namespace, should only be applied in one space in the selector, if overriding place in both spaces.<br> <Frances> David: right now outside of :where and not inside<br> <Frances> Emilio: :Has is different, is doesn't match. nth is different from :where. Interesting to see where in browsers it's implemented, possible non intentional implementation.<br> <dbaron> s/if overriding place in both spaces/so if you're overriding it you don't have to override it the same way in both places/<br> <Frances> Emilio: fine with no change, can address in another issue. Might not be specific to Firefox. We could try simplifying it.<br> <dbaron> David: also, regarding :has(), I can certainly see :has() working differently<br> <dbaron> s/space in the selector/place in the selector for a particular element/<br> <Frances> PROPOSAL: Close issue #5684 no change<br> <Frances> Alan: Can make the rule consistent, open a new issue on backwards compatibility or remove rule entirely<br> <astearns> ACTION: TabAtkins to create a new issue for removing the rule<br> <Frances> RESOLVED: Close issue #5684 with no change<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5684#issuecomment-1896288290 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 January 2024 17:39:34 UTC