- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Oct 2022 16:07:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `nesting syntax`, and agreed to the following:
* `RESOLVED: We're taking option 3 over option 1`
* `RESOLVED: change the spec to reflect option 3`
<details><summary>The full IRC log of that discussion</summary>
<astearns> topic: nesting syntax<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/7834<br>
<ydaniv> astearns: who wants to present summary<br>
<ydaniv> TabAtkins: we've got 4 options covering all the posibilites<br>
<fantasai> Summary of Options -> https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md<br>
<ydaniv> ... option 1: either start with @nest or &<br>
<ydaniv> ... option 2: you have a parser switch and afterwards only declaration switch<br>
<fantasai> s/only declaration switch/only style rules, so they're unambiguous and don't need special prefixing/<br>
<ydaniv> ... option 3: your selector has to start with anything but an ident<br>
<ydaniv> ... in a rare case where you do need to start with ident you can either use an & or wrap it up with :is() or :where()<br>
<ydaniv> ... option 4: what FRemy presented either as separate block or separate block following an &<br>
<ydaniv> astearns: we've had a poll. I wonder whether there's another combination of starting with 1 and relaxing later to 3.<br>
<ydaniv> TabAtkins: not sure it's a good idea to change syntax<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to respond to astearns<br>
<fremy> q?<br>
<fantasai> -> https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md#twitter-polls<br>
<ydaniv> fantasai: lea did a couple of twitter polls which are also helpful<br>
<ydaniv> ... we have a significant majority that ppl perfer & at all time<br>
<ydaniv> ... we have a large number of authors who are not going to be satisfied with option 1<br>
<argyle> q+<br>
<fantasai> s/perfer & at all time/prefer not requiring & at all times/<br>
<jensimmons> q+<br>
<astearns> ack argyle<br>
<ydaniv> adam: there are many other projects with different syntax who are using different syntax and are not considered in the polls<br>
<TabAtkins> (Tho note there are even larger ecosystems that are using nesting syntaxes without a required & prefix.)<br>
<lea> q+ to say "authors are not complaining" is not equivalent to "authors are satisfied"<br>
<astearns> ack jensimmons<br>
<ydaniv> ... just wanna make sure they're included in this conversation<br>
<fremy> q+<br>
<jensimmons> Meet is broken<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to say "authors are not complaining" is not equivalent to "authors are satisfied"<br>
<astearns> q+ jensimmons<br>
<ydaniv> lea: authors are not complaining, they just accept it is what it is. But I have seen authors complaining that current syntax is too noisy<br>
<argyle> var(--foo) got the same response<br>
<ydaniv> ... this is why we brought this up<br>
<ydaniv> ... they really need nesting, but that it could be better<br>
<emeyer> q+<br>
<astearns> ack jensimmons<br>
<fantasai> s/that it could be better/but they will use what they have, even if it could be better/<br>
<ydaniv> jensimmons: I really like option 4 the best. It's really simple. Other options are really complicated. I feel like CSS should be fun and simpe<br>
<florian> +1 to jensimmons<br>
<astearns> ack fremy<br>
<ydaniv> ... option 4 captures that<br>
<ydaniv> fremy: I agree with what lea said. At the end of the day you have to ship something.<br>
<argyle> q+<br>
<ydaniv> ... ppl use what they have<br>
<ydaniv> ... I would not object to option 3. It's not the best I think. I like 4 better.<br>
<fremy> https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1292196313<br>
<ydaniv> ... one point I want to highlight, option 4 is the least complexity<br>
<ydaniv> ... we define 3 different syntaxes for nesting. It may change...<br>
<jensimmons> q+<br>
<TabAtkins> q+<br>
<ydaniv> ... You have to consistently switch between syntaxes. I think this is a big weakness<br>
<flackr> q+<br>
<astearns> ack emeyer<br>
<ydaniv> ... why add ambiguity when we can keep it simple. But if other ppl prefer other options and are comfortable with tradeoffs then we might as well do it<br>
<ydaniv> ericmeyer: I like option 4. Makes the most sense as an author.<br>
<astearns> ack argyle<br>
<lea> q?<br>
<ydaniv> argyle: may pick whatever syntax via any tool they choose.<br>
<miriam> q+<br>
<ydaniv> ... when you reason option 1 has the least things to remember. The least ambiguous<br>
<ydaniv> ... feels like a win win win across the board<br>
<fantasai> Option 4 is the most unambiguous, and quite likely the easiest to implement.<br>
<fantasai> Whether it's the best, idk, but it's the most unambiguous<br>
<lea> Not sure where it's founded that other options would take longer to implement. We only have one data point here.<br>
<ydaniv> ... you don't have to remember what you can/can't use. Not need to teach what's an ident<br>
<ydaniv> ... all options eventually rely on &<br>
<ydaniv> fremy: not true, option 4 does not<br>
<astearns> ack jensimmons<br>
<ydaniv> jensimmons: I don't really like the idea of us coming up with syntax now and changing later.<br>
<TabAtkins> Big +1 to jen's point - adding new *functionality* later is fine, adding new syntaxes for no new functionality is bad.<br>
<fantasai> +1<br>
<ydaniv> ... as someone who's taught authors, I don't think it'll go well if we change syntax 3 yrs down the road<br>
<ydaniv> ... our best shot is now<br>
<lea> +1<br>
<ydaniv> ... we should plan on our very best solution and be done with it<br>
<ydaniv> ... I also believe strongly that nesting is important for ppl to code better and easier<br>
<ydaniv> ... if they have to remember many rule with a lot of mental complexity it's an overhead<br>
<ydaniv> ... not assume that using other tools is something everyone will be okay with<br>
<fantasai> jensimmons: I want nesting to be easy and fast to use, I want it to be elegant, and if there's a bug it's a typo and not because you're using the wrong variant of syntax<br>
<bramus> q+<br>
<ydaniv> ... option 4 we haven't talked much about before. I haven't heard others talking about it much<br>
<astearns> ack TabAtkins<br>
<ydaniv> TabAtkins: I'd like to say what I don't like about option 4<br>
<ydaniv> .... I'm very strongly opposed to 4. 1. it is not nested, feels unnatural<br>
<bramus> +1<br>
<JakeA> +1 to the it's-not-actually-nested issue<br>
<ydaniv> ... the idea that it's chained after and not inside the block<br>
<bramus> authors already know how to nest, from at-rules, markup, etc.<br>
<ydaniv> ... option 4 is the only that's not compatibe with current state. It doesn't mix with the rest.<br>
<florian> q?<br>
<florian> q+ to respond to tab's argument 1 and 2<br>
<fantasai> wrt style attributes, we could just allow the rule block to be placed inside the style attr, if we don't want to add a new attribute. This has the same parsing properties.<br>
<ydaniv> ... if you want nest existing rules into other rules you have to go to bottom and add there<br>
<lea> +1 to everything TabAtkins is saying<br>
<ydaniv> ... in general having things in a sibling-wise way is not a greay idea<br>
<florian> q-<br>
<ydaniv> ... in parent-child relationship things are always nested. other options do that, 4 does not<br>
<ydaniv> ... I also want to stress that this is harder to parse<br>
<fantasai> s/is harder/is not harder/<br>
<ydaniv> ... 1 & 3 are identical. 2 is a bit harder<br>
<ydaniv> ... 4 isn't difficult in any way, simply new<br>
<fremy> q!<br>
<astearns> ack florian<br>
<astearns> ack fla<br>
<ydaniv> flackr: we mentioned in option 3 that it's possible to relax further.<br>
<astearns> q+<br>
<ydaniv> ... it may be, but not a good idea<br>
<ydaniv> TabAtkins: not a good idea ^_^<br>
<astearns> ack miriam<br>
<fantasai> s/good idea/possible idea/<br>
<fantasai> TabAtkins: Selectors just have fundamentally infinite overlap with property:value delcarations<br>
<ydaniv> miriam: I agree generally with what Tab said. option 4 is weird. It's all trade offs. 3 is the one I voted for.<br>
<ydaniv> ... there's one rule to learn, always start with a symbol<br>
<ydaniv> ... I like the idea that both allow for forgiving parsing<br>
<astearns> ack bramus<br>
<astearns> ack dbaron<br>
<ydaniv> bramus: I think nesting without nesting is also inventing wierd things<br>
<ydaniv> dbaron: I think that 4.iii variant is somewhat different than others. Having look at it more, looks like you have a selector and bunch of things after it<br>
<ydaniv> ... after looking it while doesn't feel like a nested rule<br>
<ydaniv> astearns: I was on the queue to say something similar<br>
<dbaron> s/a nested/an un-nested/<br>
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1282700284<br>
<fantasai> Conceptually, style rules would now have three parts:<br>
<fantasai> a selector<br>
<fantasai> a declaration block<br>
<fantasai> a style rule block (optional)<br>
<TabAtkins> that extra indent is very significant!<br>
<ydaniv> ... we also had another similar proposal of nesting a new block inside<br>
<astearns> q?<br>
<astearns> ack astearns<br>
<ydaniv> ... which gets rid of the weirdness<br>
<astearns> ack fantasai<br>
<ydaniv> fantasai: my suggestion we have a lot of options<br>
<ydaniv> ... pick between 1 or 3 and then continue<br>
<ydaniv> astearns: we're not picking a winner, we're choosing which avenue to take<br>
<ydaniv> TabAtkins: I suggest we take binding votes<br>
<bramus> +1 on binding vote<br>
<ydaniv> fantasai: I think the problem is that ppl are trying to implement and we should be trying to resolve today<br>
<ydaniv> ... suggest polling between 1 and 3<br>
<fantasai> POLL: Option 1 vs Option 3<br>
<TabAtkins> 3<br>
<lea> 3<br>
<fantasai> 3<br>
<argyle> 1<br>
<oriol> 1<br>
<miriam> 3<br>
<JakeA> 1<br>
<flackr> 3<br>
<dbaron> 3<br>
<patrickangle_> 3<br>
<futhark> 1<br>
<bramus> 3<br>
<jensimmons> 3<br>
<ydaniv> astearns: taking 2 votes: whether to continue with 1 or change to 3 please put<br>
<astearns> 3<br>
<fremy> 3<br>
<Sebastian_Zartner> 1<br>
<emeyer> 3<br>
<ydaniv> 3<br>
<florian> 3<br>
<ydaniv> astearns: looks very much in favor of 3<br>
<ydaniv> fantasai: we're taking option 3 over 1<br>
<ydaniv> RESOLVED: We're taking option 3 over option 1<br>
<ydaniv> fantasai: anyone want's to add anything to this discussion?<br>
<fantasai> s/this/3 vs 4/<br>
<dbaron> s/this discussion/the discussion of option 3 versus option 4/<br>
<ydaniv> astearns: I think that option 4 may get us to a better place<br>
<ydaniv> fantasai: option 4 has to possible ways...<br>
<astearns> the added punctuation could be '{}' :)<br>
<ydaniv> s/to/two/<br>
<fremy> q+<br>
<jensimmons> q+<br>
<dbaron> fantasai: ... two adjacent blocks, or some punctuation between them (which would allow omitting the first block)<br>
<fantasai> s/to possible ways/two viable options/<br>
<ydaniv> fremy: there's one thing I dislike, the idea that this is usability against "I don't like it"<br>
<ydaniv> TabAtkins: I think this is a bad characterisation<br>
<TabAtkins> q+<br>
<astearns> ack jensimmons<br>
<astearns> ack fremy<br>
<ydaniv> jensimmons: I heard ppl say that option 4 doesn't feel like nesting because they're not nested inside. not like SASS.<br>
<ydaniv> ... but I feel like I get that, I hated it, but then thought what it opens up, it became my first choice<br>
<ydaniv> ... it lets me write more simply without repeating<br>
<TabAtkins> Big objection against 4 is the inconsistency with other syntaxes or planned future syntaxes. At-rules - do they have to go in the property or the rule block? Nested @media - how do we do properties directly inside of it with option 4 syntax? This is common and popular in Sass, for example.<br>
<ydaniv> ... feels like we're trying to solve reality where instead we could choose a different way to accomplish more<br>
<astearns> ack TabAtkins<br>
<ydaniv> TabAtkins: I said before that option 4 is incossistent with current syntax and others<br>
<lea> Oh great point, +1 TabAtkins<br>
<futhark> present-<br>
<ydaniv> ... introducing a new postfix syntax will cause us problems in may ways<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to respond to Tab<br>
<ydaniv> ... instead of using current syntax which works nicely<br>
<ydaniv> fantasai: I agree with Jen about portability between contexts<br>
<ydaniv> ... I have reservations against, options 3 has more rules to learn but portability troubles me<br>
<ydaniv> ... we can make changes to syntax<br>
<lea> q?<br>
<ydaniv> ... there are ways around nesting media rules<br>
<TabAtkins> 3<br>
<JakeA> 3<br>
<bramus> 3<br>
<lea> 3<br>
<argyle> 3<br>
<fremy> 4<br>
<astearns> 4<br>
<ydaniv> astearns: shall we take 3 vs. 4 poll? please vote<br>
<oriol> 4<br>
<jensimmons> 4<br>
<flackr> 3<br>
<florian> 4<br>
<dbaron> 4<br>
<andreubotella> 3<br>
<patrickangle_> 4<br>
<Sebastian_Zartner> 3<br>
<ydaniv> 4<br>
<fantasai> probably 4<br>
<jensimmons> ericmeyer isn't here, but he said 4 before<br>
<dholbert> 4<br>
<ydaniv> TabAtkins: editors choice<br>
<ydaniv> lea: which editor?<br>
<ydaniv> astearns: slightly in favor of 4<br>
<ydaniv> ... if we want to take a binding resolution 4 wins<br>
<ydaniv> TabAtkins: I would object, it's very annoying.<br>
<ydaniv> argyle: I agree<br>
<JakeA> Poll developers for 3 vs 4?<br>
<ydaniv> astearns: we could change the draft to 3, and leave this question open<br>
<ydaniv> florian: it's effectively making a decission<br>
<argyle> its just a prototype, no intent to ship<br>
<ydaniv> astearns: if we're conflicted then we should not ship<br>
<ydaniv> lea: it's already implemented behind a flag<br>
<ydaniv> astearns: then they're shippind shouldn't affect our decission<br>
<ydaniv> jensimmons: I would be disappointed if google ships and this affects our process<br>
<ydaniv> argyle: Google never intended to ship<br>
<ydaniv> ... no one was intending to ship<br>
<ydaniv> jensimmons: pressure is good<br>
<astearns> ack fantasai<br>
<ydaniv> fantasai: I think we should take suggestions to put options infront of developers and get more feedback<br>
<ydaniv> ... we could get more colab<br>
<ydaniv> ... would be reasonable to update draft to 3 think we like it better<br>
<ydaniv> ... get more feedback about 4 and come back when we're more confident<br>
<JakeA> The future is longer than the past :D<br>
<ydaniv> ... we have to get it right, otherwise...<br>
<ydaniv> jensimmons: what Tab said about syntax sounded intesresting would like to see example<br>
<fantasai> s/otherwise/this is going to fundamentally change how we write CSS for ~80% of style rules for the rest of the life of CSS/<br>
<fantasai> s/think we/since we/<br>
<fantasai> s/like it better/like it better than option 1/<br>
<ydaniv> argyle: I sugges writing many examples and see how it comes up<br>
<fantasai> +!<br>
<fantasai> +1<br>
<ydaniv> ... with option 4 & 3<br>
<ydaniv> astearns: proposed resolution to change draft to 3 and leave 4 to another talk<br>
<ydaniv> ... I don't think it's useful anymore<br>
<ydaniv> RESOLVED: change the spec to reflect option 3<br>
<ydaniv> astearns: who will take this to developers?<br>
<ydaniv> lea: together with someone else<br>
<ydaniv> fantasai: I can help<br>
<ydaniv> miriam: me too<br>
<ydaniv> fantasai: we should also mark it up in the draft for ppl to see<br>
<ydaniv> astearns: done with this issue<br>
<ydaniv> ... 10 mins break<br>
<fantasai> s/it up in/issue into/<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1292277520 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 October 2022 16:07:17 UTC