- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Nov 2022 17:48:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-nesting-1] Yet another nesting proposal`, and agreed to the following:
* `RESOLVED: call this Option 5 :)`
<details><summary>The full IRC log of that discussion</summary>
<jensimmons> I'd like to begin this discussion by requesting we call this "Option 5".<br>
<fantasai> RESOLVED: call this Option 5 :)<br>
<fantasai> plinss: This is something I've been wanting to do since the 90s, and immediately ran into problem of conflicts when nesting selectors inside a rule that expects properties<br>
<fantasai> plinss: I understand option 3 is trying to find workaround, an doption 4 a different approach<br>
<fantasai> plinss: Wondering what if we turn the problem around entirely<br>
<fantasai> plinss: and introduce a top-level construct that only contains nested rules<br>
<fantasai> plinss: so never mix properties and rules in a single context<br>
<fantasai> plinss: My concern with Option 3 is that even if we have a syntactic way to disambiguous, that does paint us into a corner<br>
<fantasai> plinss: harder to introduce new things in the future<br>
<fantasai> plinss: My proposal is to introduce an @rule, calling @nest<br>
<fantasai> plinss: and inside that block is nothing but nested rules<br>
<fantasai> plinss: Can have no selector for a block, and that applies properties to the top-level selector<br>
<TabAtkins> q+<br>
<fantasai> plinss: No parsing changes, no extra lookahead, no changes to OM, easy to explain, no special bizarre syntax rules, just works<br>
<fantasai> plinss: Downside is you add an extra layer of indenting for properties that apply to top-level rule<br>
<fantasai> plinss: but I don't see that as a problem because I add extra blocks to code all the time, modern tools make this easy<br>
<fantasai> plinss: it's easy to see what happens<br>
<oriol> q+<br>
<fantasai> plinss: I think this is much better than adding cognitive load to authors, learning weird parsing exception rules<br>
<fremy> q?<br>
<Rossen_> ack TabAtkins<br>
<oriol> q-<br>
<fantasai> TabAtkins: As I said in issue, my objection is still that it requires a non-local edit<br>
<fantasai> TabAtkins: Can't just add stuff, need to go back and change the existing rule to allow nesting<br>
<fantasai> TabAtkins: It's a non-trivial bit of work, and is distinct from the way that every preprocessor has tried to do things since they invented nesting<br>
<fantasai> TabAtkins: Also, I continue to think that any statement about complexity of the rules for Option 3 is overstated, it's literally just "does the selector start with an identifier? if so need a prefix"<br>
<fremy> q+<br>
<fantasai> TabAtkins: not that big a deal to learn or work around<br>
<fantasai> TabAtkins: Doing non-local edits to add nested rules to something is also a cognitive load when making edits in place<br>
<fantasai> TabAtkins: I don't like it<br>
<fantasai> TabAtkins: it does have better qualities than some other proposals<br>
<fantasai> TabAtkins: but it's roughly equivalent to just prepending @nest to all rules in terms of overall functionality, just changes where @nest shows up basically<br>
<fantasai> TabAtkins: That's been mildly rejected by authors and WG already, would like to avoid<br>
<fantasai> plinss: On the conflict issue, the point that you're missing is that mixing selectors and properties in one block does constrain us for future expansion<br>
<fantasai> plinss: if we ever want to put [missed] in a property block, we can't do that<br>
<fantasai> plinss: I'm very concerned about contraining our ability to expand CSS later<br>
<fantasai> TabAtkins: I share your concern. Still have some room for expansion, so I'm okay with it. E.g. if your expansion is after property name, can still do that; or if we introduce functional notations, we can still do that<br>
<fantasai> TabAtkins: neither of these would be parsed as a nested rule<br>
<fantasai> TabAtkins: so think there's still enough space for expansion, in my opinion<br>
<ydaniv> s/contraining/constraining/<br>
<fantasai> plinss: Also, you can interleave properties and nested rules, how does that show up in the OM? Will lose that on reserialization<br>
<fantasai> plinss: my proposal avoids because can't do that<br>
<fantasai> TabAtkins: Assigning meaning to ordering seems fraught in first place, but it does mean when reserialize it'll look different from input<br>
<Rossen_> q<br>
<fantasai> plinss: no functional difference, but authors will order things for organizational reasons, and it's a loss to the author if lost on reserializatoin<br>
<astearns> In option 5 you can still interleave, I think `@nest foo { & {} bar {} & {} }`<br>
<fantasai> fremy: I feel like there's a way of serializing this<br>
<fantasai> fremy: I don't agree that if you allow properties after rules it's meaningless<br>
<fantasai> fremy: it's same as selector with & only<br>
<fantasai> fremy: It affects ordering<br>
<fantasai> fremy: If your property defined after a rule doesn't work<br>
<fantasai> fremy: but that's a different topic, but it's something to consider<br>
<plinss> astearns, yes, but the ordering is preserved because they're all style rules<br>
<astearns> ok<br>
<fantasai> fremy: Other than that, I feel like one positive point from plinss's proposal he didn't mention<br>
<fantasai> fremy: Shared with Option 4<br>
<fantasai> fremy: It's ability to copy / paste<br>
<fantasai> fremy: If you nest with Option 3, cannot copy paste without running into problems maybe<br>
<fantasai> fremy: Both this and option 4 have this ability<br>
<fantasai> fremy: I agree that when you change from one rule to nesting, you have t oadd some stuff before/after, but I think it's worth mentioning that for Option 3 that if you go from nesting to not nesting or vice versa<br>
<fantasai> fremy: you need to change things<br>
<fantasai> fremy: refactoring is a pain in both cases, but it's different kind of paint<br>
<fantasai> fremy: but I wanted to mention this important point<br>
<tantek> copypaste++ and and also +1 for adding/removing nesting without having to rewrite the contents as a design principle<br>
<Rossen_> q?<br>
<argyle> q+<br>
<Rossen_> ack fremy<br>
<jensimmons> +q<br>
<fantasai> argyle: I'm confused by the copy/paste scenario? I'm writing CSS using nesting 1, 2, 3,<br>
<fantasai> argyle: I copy paste stuff in and out of socpe, in and out of ..., just use & everywhere<br>
<fantasai> fremy: You decided to use & everywhere, but if you remove nesting it'll break<br>
<Rossen_> ack argyle<br>
<fantasai> argyle: it only breaks with :has()<br>
<fantasai> fremy: that's not what I mean, what I mean is if you have a CSS file with a lot of rules, they can start with any selector<br>
<fantasai> fremy: html or p or whatever<br>
<fantasai> fremy: If you want to take all these rules and nest them, and say they only apply in this div with special ID<br>
<fantasai> fremy: you have to add & to selectors or they will break<br>
<fantasai> fremy: You can't just copy paste them into the brackets<br>
<fantasai> argyle: Concern in general, & makes it better and more clear<br>
<fantasai> fremy: Even if it was required, you would have to add these when you paste into nested context<br>
<fantasai> fremy: When you have a stylesheet with normal selectors, if you want to nest this stylesheet, you have to add & before every selector or it won't work<br>
<fantasai> argyle: I would like to see examples<br>
<fremy> stylesheet was " html { color: red }<br>
<fantasai> Rossen_: Sounds like some conversation paste each other, but 2-3 line example from fremy you will be able to see what he means about usability<br>
<fremy> if you want to nest this in #id<br>
<fremy> "#id { html { color: red } }" is not valid<br>
<fantasai> argyle: I've been using this stuff, it's not just theoretical<br>
<fantasai> argyle: I have 100s of lines of nested lines of CSS, I don't find a portability issue<br>
<fremy> you have to go and edit "#id { & html { color: red } }"<br>
<fantasai> argyle: I don't see what you're talking about<br>
<Rossen_> q?<br>
<fremy> and you have to do that for potentially a lot of selectors<br>
<fantasai> argyle, you're one of 50% of authors who think it's fine to prefix all their style rules everywhere forever with &. The other 50% of authors don't want to do this.<br>
<argyle> i'm in both camps, trying both..<br>
<fantasai> jensimmons: I really like this option, I like this a lot. I like it better than Option 4<br>
<fantasai> jensimmons: what I would hope is that folks who've done a lot of work on this, and advocating to make this reality<br>
<fantasai> jensimmons: I hope that you are honestly willing to consider these other possibilities<br>
<fantasai> jensimmons: what's interesting about this is that it's a deviation from how web developers have thought about nesting from e.g. sass<br>
<fantasai> jensimmons: it is more like writing an @rule and doing stuff inside it, isntead of having the shape from sass<br>
<fantasai> jensimmons: but I don't think we should reject out of hand<br>
<fantasai> jensimmons: there is something elegant of it<br>
<miriam> q+<br>
<fantasai> jensimmons: and I thinkw e ened to think of the full range of ppl who write CSS, from students to hobbyists to professionals that write lots of JS to professionals that do other type of software engineering to professionals that do [msised]<br>
<fantasai> jensimmons: want it to be not breaking<br>
<fantasai> jensimmons: make it easy to understand<br>
<fremy> q?<br>
<fantasai> jensimmons: think this proposal is very elegant and straightforward<br>
<fantasai> miriam: 2 things<br>
<fantasai> miriam: 1. This proposal is very much like @scope, doesn't have scoping aspects but otherwise the shape of it is basically identical to socpe<br>
<fantasai> miriam: I don't know if that's positive or negative, but worth pointing out<br>
<fantasai> miriam: I agree with Jen about who we should think about, but also with Tab about how this seems problematic<br>
<fantasai> miriam: copy/paste is pitched as an advantage, but you're not abile to copy/paste int osomething not @nest, takes a lot of adjustment<br>
<fantasai> miriam: All of these proposals have tradeoffs, and we keep fighting about which tradeoffs, and aruging which are better for authors<br>
<Rossen_> ack jensimmons<br>
<Rossen_> ack miriam<br>
<fantasai> miriam: I think all of theme are hard for authors, but we need to pick one<br>
<fantasai> fremy: I thought we agreed to make a survey and see what ppl think, but we now have another proposal<br>
<fantasai> fremy: but we should probably should do that<br>
<fantasai> Rossen_: Agreed<br>
<fantasai> Rossen_: getting away from topic which is review of this proposal<br>
<fantasai> Rossen_: appreciate plinss for describing the proposal and its pros/cons wrt others<br>
<jensimmons> q+<br>
<fantasai> Rossen_: My hope is that we'll get to next step and at some point will need to close the door on more options<br>
<fantasai> Rossen_: and start scoping down which we will go with, which will work best for authors<br>
<fantasai> Rossen_: with that, I want to move on...<br>
<fantasai> Rossen_: but I want to simply take the conversation down to a closure with next steps being, let's figure out what ppl think about these options in a representative way<br>
<fantasai> Rossen_: and then come back to making some choices<br>
<fantasai> jensimmons: I would really love for us to come to a decision, a final decision, by the end of the year. That might be a little ambitious<br>
<fantasai> jensimmons: I do think we're close.<br>
<fantasai> jensimmons: we could just decide on Option 3 and call it a day, but I think we do want to have a bit more debate about 4 or 5<br>
<fantasai> jensimmons: but I also hear the clock ticking, so would like a decision by early January<br>
<fantasai> Rossen_: Appreciate pressure and urgency, and hope we'll have something end of year or beginning of next<br>
<fantasai> Rossen_: Ok, let's wrap up this conversation. Thanks plinss for bringing this up<br>
<fantasai> Rossen_: one last closing question, do we have a path forward to organize non-biased survey, and who would that be?<br>
<fantasai> Rossen_: jensimmons, can you do that? You seem most non-biased :)<br>
<fantasai> fremy: I think last time miriam, TabAtkins, fantasai and leaverou agreed to help<br>
<fantasai> plinss: I can edit the new proposal into the table<br>
<fantasai> -> https://drafts.csswg.org/css-nesting-1/proposals<br>
<fantasai> ACTION: plinss to update proposals table<br>
<fantasai> ACTION: jensimmons, miriam, leaverou, fantasai, etc. to create survey<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7970#issuecomment-1332528034 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 November 2022 17:48:47 UTC