- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Apr 2023 15:55:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-nesting] Require `div&`, disallow `&div`, for Sass compat``, and agreed to the following: * `RESOLVED: type selector remains required first; &div is invalid` <details><summary>The full IRC log of that discussion</summary> <fantasai> TabAtkins: In previous version of Nesting, we relaxed restriction to starting with a tag selector in order to allow & at the front<br> <fantasai> ... which was required for previous parsing solutions<br> <fantasai> TabAtkins: SASS uses & as a textual substitution, so if you write &div, you're asking SASS to append the letters "div", so if your parent selector was ".foo" you get ".foodiv"<br> <fantasai> ... having this mismatch would be an annoying upgrade story for them, because this sort of concatenation is very heavily used<br> <fantasai> ... due to object-oriented class naming patterns<br> <fantasai> ... On the other hand, putting additional type selectors on the compound selector is exceedingly rare<br> <fantasai> ... she's heard the request only a few times<br> <fantasai> ... So this is very low priority for them<br> <fantasai> ... upshot of all this, is I suggest we remove the relaxed restriction that allows type selectors to not be at the front<br> <fantasai> ... restoring us to previous restriction, which requires the tag selector in front<br> <fantasai> ... then you can write div& but not &div<br> <fantasai> ... which protects that syntax space for SASS and related languages<br> <fantasai> TabAtkins: This also helps with some degree of migration<br> <fantasai> ... if they know it's an error, they can autocorrect to the right form<br> <fantasai> TabAtkins: I was initially uncertain of specifying this, if there is already usage of &div in Chrome or Safari<br> <fantasai> ... but apparently Chrome's implementation never relaxed that restriction so &div has been invalid this whole time<br> <fantasai> TabAtkins: so at least for Chrome, this isn't an issue, so making this invalid again would be fine<br> <fantasai> ... unclear about Safari I couldn't test<br> <fantasai> TabAtkins: So I propose to revert the syntax restrictions<br> <fantasai> ??: [missed]<br> <fantasai> ??: We don't have the same behavior as Chrome, so it would be a breaking change for us<br> <fantasai> astearns: Given that there is likely not that much content targetting Safari's current implementation, would you be ok with this change?<br> <fantasai> ??: Pretty sure there are zero websites targetting it, so won't break the Web<br> <oriol> q+<br> <fantasai> TabAtkins: Then I ask for a resolution<br> <dbaron> s/??/matthieu/<br> <fantasai> s/??/mattieu/<br> <fantasai> s/??/mattieu/<br> <astearns> ack oriol<br> <emilio> +1 to keep that restriction, fwiw on Firefox's impl I never implemented it either<br> <oriol> Lety me reconnect<br> <fantasai> jensimmons: Curious to know what miriam thinks about this issue<br> <fantasai> miriam: I think this is a good idea, for the reasons Tab listed<br> <fantasai> ... I am not on the internals of everything that Natalie is conerned about here, but was part of the conversation with Tab and agree this is the direction to go to minorly limit a problem<br> <astearns> ack oriol<br> <fantasai> oriol: I'm opposed to the restriction, but not clear to me how exactly it's helping. In SASS the behavior is something else, and ppl are using that behavior, if they switch to Nesting they will have to adapt somehow anyway<br> <dbaron> s/mattieu/matthieu/<br> <fantasai> ... I'm not sure whether it's invalid or it means something different, if it is that relevant to people<br> <dbaron> s/mattieu/matthieu/<br> <fantasai> TabAtkins: As much as possible, SASS tries not to interpret valid CSS differently as how browsers would interpret it<br> <fantasai> ... It is helpful if we put it as invalid syntax, so it is definitely not something that would mean something in the browser<br> <emilio> q+<br> <fantasai> ... It's not strictly necessary, because they'll have compat pain anyway, but a long-term goal here, is that as long as author is not using SASS-specific features, they want to emit native CSS in the future<br> <astearns> ack emilio<br> <fantasai> ... being certain about using CSS-compatible syntax or invalid syntax that is SASS-interpreted is a goal<br> <fantasai> emilio: If we ever expose the final selector somehow, it would be weird if this couldn't be serialized in anyway<br> <fantasai> ... so I support not allowing &div<br> <fantasai> emilio: In particular, if devtools wanted to show the final selector that this element matched, you want to see something useful<br> <fantasai> ... if you write &div, you can't just expand it<br> <fantasai> emilio: so I would prefer to avoid this special case<br> <fantasai> astearns: Other comments or conerns?<br> <fantasai> s/conerns/concerns/<br> <fantasai> TabAtkins: Proposed to remove relaxation of type selector rules, keep current rule that type selector must be first in a compound selector<br> <fantasai> astearns: objections?<br> <fantasai> RESOLVED: type selector remains required first; &div is invalid<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8662#issuecomment-1514977935 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 April 2023 15:55:28 UTC