- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 31 Aug 2022 16:43:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Nesting syntax`, and agreed to the following: * `RESOLVED: Revert the previous resolution from Nov 2021 mandating bracket-nesting syntax, and the WG preference for a single nesting syntax.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Nesting syntax<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4748<br> <fantasai> ScribeNick: fantasai<br> <fantasai> TabAtkins: Some time ago we had a discussion about what style of nesting syntax should use<br> <fantasai> TabAtkins: major options are what I drafted, nesting selector directly with an &<br> <fantasai> TabAtkins: or use @nest if needed<br> <fantasai> TabAtkins: option 2 is @nest always<br> <fantasai> TabAtkins: and option 3 is using brackets to wrap nested rules, never use @nest<br> <fantasai> TabAtkins: At the time we did a straw poll, and WG resolved on using brackets<br> <fantasai> TabAtkins: I was unhappy with this and we resolved to take it back for more data collection or arguments<br> <fantasai> TabAtkins: Adam Argyle ran a poll with significant response numbers about this<br> <TabAtkins> https://developer.chrome.com/blog/help-css-nesting/<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-1211280306<br> <fantasai> TabAtkins: Linked article, I think was written fairly<br> <fantasai> TabAtkins: It seems responses are incredibly one-sided<br> <fantasai> TabAtkins: Using & or @nest directly<br> <fantasai> TabAtkins: This is what's in the current spec and what I prefer<br> <fantasai> TabAtkins: This was an overwhelming response in favor of one option<br> <fantasai> TabAtkins: So suggestion is to revert previous resolution and keep syntax in current spec<br> <astearns> option 1 also allows you to write as if @nest is always required<br> <Rossen_> ack fantasai<br> <miriam> q+<br> <TabAtkins> fantasai: The problem I noticed reading thru the thread is the bracketed syntax was represented as always putting in the ampersand, while the point of bracketed syntax was to avoid needing it<br> <TabAtkins> fantasai: So I dont' think that's true that it was fairly written<br> <TabAtkins> TabAtkins: I didn't take that as part of the syntax at all, still needed the & to be the nesting selector<br> <TabAtkins> fantasai: The point was that it was mostly never needed, so I think the poll wasn't valid<br> <TabAtkins> miriam: I reviewed the article and helped come up with the syntax, so...<br> <Rossen_> ack miriam<br> <TabAtkins> miriam: I didn't think of removing the & as the main advantage of the brackets<br> <TabAtkins> miriam: As I was writing it I foudn the brackets more confusing than expected, and I actually *added* ampersands for clarity<br> <TabAtkins> miriam: AFter writing the demos I actually changed my mind away from bracketing<br> <TabAtkins> fantasai: I'm not going to block, if y'all liek this syntax better that's fine. I just don't like having an inconsistent syntax.<br> <TabAtkins> fantasai: I just don't think it's fair to say it was overwhelmingingly in one direction<br> <TabAtkins> Rossen_: So it sounds like we have a pretty strong response. Possibly biased, but Mia makes an argument for it not being so.<br> <fantasai> I really don't like the inconsistency, where you have to know when to use @nest<br> <Rossen_> q?<br> <TabAtkins> Rossen_: So proposed resolution is to undo the resolutions from november and leave the spec as it currentyl is<br> <TabAtkins> Rossen_: Any additional comments or feedback?<br> <TabAtkins> fantasai: I'm not gonna object because everyone seems to like it, but I really don't like that authors have to know when to use @nest, it's not a consistent syntax<br> <TabAtkins> fantasai: And I wish we had something else besides an inconsistent syntax<br> <TabAtkins> fantasai: I don't like @nest everywhere since it's verbose, but...<br> <TabAtkins> miriam: I agree on the problem and it's why I liked bracket before. I agree it's an issue and it's weird<br> <TabAtkins> miriam: But once I started writing examples, it almost all basic use-cases you just use the & and it works and looks cleaner.<br> <TabAtkins> miriam: and there are only rare cases where you need to use @nest and it's not as hard as I initially thought to know the difference<br> <TabAtkins> miriam: So that's why I changed my mind even tho I agree it's inconsistent<br> <bradk> +1 to miriam<br> <TabAtkins> plinss: I think elika has a valid point and before we decide on this we could make another design phase to try to come up with another route.<br> <fantasai> I'm not so opposed to the & , just that some rules require @nest and others dont'<br> <TabAtkins> plinss: I'm okay with undoing the previous resolution, just not sure we shoudl resolve affirmatively on the current syntax<br> <TabAtkins> Rossen_: Right, so let's just resolve on undoing the previous resolution.<br> <TabAtkins> Rossen_: Objections?<br> <TabAtkins> RESOLVED: Revert the previous resolution from Nov 2021 mandating bracket-nesting syntax, and the WG preference for a single nesting syntax.<br> <TabAtkins> Rossen_: And for the record, want to strongy encourage continued improvement of the design.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-1233176065 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 31 August 2022 16:43:27 UTC