Re: [csswg-drafts] [css-nesting] request to pick up the css-nesting proposal

The Working Group just discussed `css nesting`, and agreed to the following:

* `RESOLVED: add css-nesting as an ED, Tab Atkins as editor, file issues until ppl are overall kinda happy with what it's like before we consider FPWD`

<details><summary>The full IRC log of that discussion</summary>
&lt;florian> topic: css nesting<br>
&lt;florian> github: https://github.com/w3c/csswg-drafts/issues/2701<br>
&lt;florian> TabAtkins: we tried to discuss that a while back, but didn't have time to conclude. Should we rediscuss, or re-resolve<br>
&lt;TabAtkins> https://tabatkins.github.io/specs/css-nesting/<br>
&lt;florian> myles: I want an overview<br>
&lt;florian> TabAtkins: nesting style rules is a common request, and a feature of every css preporsessor in existence<br>
&lt;florian> TabAtkins: and one of their most popular feature<br>
&lt;florian> TabAtkins: makes stylesheets much easier to maintain<br>
&lt;florian> TabAtkins: it is purely syntatic sugar, but is worth covering because of the huge demand<br>
&lt;florian> TabAtkins: the way they're done in preprocessors are ambiguous with properties<br>
&lt;florian> TabAtkins: My propose spec disambiguate with by using &amp;<br>
&lt;florian> TabAtkins: you can use &amp; at the front, and if you want it elsewhere, you can use @nest to keep things unambiguous<br>
&lt;TabAtkins> a:hover ....<br>
&lt;florian> TabAtkins: the above looks like a "a" property with a "hover" value<br>
&lt;frremy> q+<br>
&lt;florian> TabAtkins: CSS parsing only requires a finite amount of lookahead, and we'd like to keep it that way<br>
&lt;florian> leaverou: isn't it only a problem when the tag selector is the first part of the selector<br>
&lt;florian> TabAtkins: I don't like that because it's not obvious, and hard to teach<br>
&lt;Rossen> q?<br>
&lt;florian> fantasai: you could pick a random character to start any rule with<br>
&lt;astearns> ack frremy<br>
&lt;fantasai> s/any/every/<br>
&lt;florian> TabAtkins: yes, that's what "@nest" do<br>
&lt;florian> frremy: replace @nest with &amp;<br>
&lt;TabAtkins> &amp; &amp;.foo {...}{<br>
&lt;florian> TabAtkins: it's ambiguous<br>
&lt;heycam> q+<br>
&lt;florian> Florian: I don't like it, @nest is nicer<br>
&lt;florian> leaverou: that would be hard to read<br>
&lt;frremy> &amp;:hover<br>
&lt;frremy> &amp; > span > &amp;<br>
&lt;florian> frremy: you only include it if needed<br>
&lt;TabAtkins> &amp; span:not(&amp;) {...}<br>
&lt;Rossen> q?<br>
&lt;florian> TabAtkins: other bad example ^<br>
&lt;astearns> ack heycam<br>
&lt;myles> Q+<br>
&lt;frremy> (I was convinced by the clarification that the &amp; can be replaced more than one in the selector , which I didn't know)<br>
&lt;myles> -q<br>
&lt;florian> heycam: can we require starting with a combinator (and use an explicit descendant combinator)<br>
&lt;florian> TabAtkins: doesn't solve it for &amp; in the middle<br>
&lt;florian> fantasai: if you use @nest, use it everywhere<br>
&lt;florian> TabAtkins: too verbose<br>
&lt;florian> heycam: @nest introduces a block?<br>
&lt;florian> leaverou: ????<br>
&lt;fantasai> s/everywhere/everywhere. If you think that's too verbose, choose a different disambiguator. Alternating between using @nest and not is not great/<br>
&lt;florian> TabAtkins: very hard to express in grammars<br>
&lt;florian> TabAtkins: in the most common cases, stating with an ampersand is short, which is important<br>
&lt;florian> fantasai: just use something shorter than @nest<br>
&lt;fantasai> s/just//<br>
&lt;florian> Florian, fantasai: how about naked @<br>
&lt;florian> myles: we don't have to bikeshed the syntax if we're just talking about adopting the module<br>
&lt;leaverou> fantasai: or naked &amp; to introduce a nested block? /* just throwing ideas! */<br>
&lt;florian> astearns: objections?<br>
&lt;fantasai> s/fantasai:/fantasai,/<br>
&lt;florian> frremy: does it need to be a new module?<br>
&lt;florian> florian: no, but it's nice that way<br>
&lt;florian> astearns: objections?<br>
&lt;florian> fantasai: ED is fine, want to bikeshed the syntax before FPWD<br>
&lt;fantasai> fantasai: Seems like nobody is really happy with the spec as-i<br>
&lt;fantasai> s/as-i/as-is/<br>
&lt;florian> xidorn: no objection, but my concern is that it expands in some cases into :matches() like things<br>
&lt;florian> xidorn: and that's hard to optimize<br>
&lt;florian> TabAtkins: you can expand them out fully<br>
&lt;florian> emilio: how about the OM?<br>
&lt;florian> TabAtkins: not expanded in the OM<br>
&lt;florian> xidorn: that makes it hard<br>
&lt;fantasai> s/in the OM/in the OM, rules get a .childRules object/<br>
&lt;florian> xidorn: because of the combinatorial explosion<br>
&lt;florian> florian: we still have to deal with that in preprocessor generated sylesheets<br>
&lt;fantasai> ScribeNick: fantasai<br>
&lt;fantasai> astearns: Hearing no objections to starting work on the module. Hearing a lot of issues against it.<br>
&lt;fantasai> astearns: Anyone else interested in heping Tab?<br>
&lt;fantasai> RESOLVED: add css-nesting as an ED, Tab Atkins as editor, file issues until ppl are overall kinda happy with what it's like before we consider FPWD<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2701#issuecomment-402392212 using your GitHub account

Received on Wednesday, 4 July 2018 07:40:58 UTC