W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2018

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

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 07 Jun 2018 00:05:10 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-395251355-1528329909-sysbot+gh@w3.org>
The Working Group just discussed `request to pick up the css-nesting proposal`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: request to pick up the css-nesting proposal<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2701<br>
&lt;dael> TabAtkins: The proposal is relatively simple. Wrote a spec a few years back. I'm fine but it's a syntax nicity where we didn't get it past hte community. If that's changed we can move it forward<br>
&lt;dael> fantasai: leaverou comment talks about wanting different specificity handling or the cascade. That's not syntactic only where you can do it wwith a preprocessor. There was @scope proposal before. I don't know if that's wanted still. I want to see more of that discussed. Do we want to effect cascade, if yes how. If we do this we should find out what's desired.<br>
&lt;dael> TabAtkins: I strongly believe nothing new on specificity. b/c nesting is in every preprocessor in existance doing so would be a major behavior change.<br>
&lt;dael> fantasai: No, not with same syntax.<br>
&lt;dael> TabAtkins: Second reason is it wouldn't be same as @scoped and it would produce thigns that some ways resembe but some way don't. @scoped wasn't popular and doesn't do what people want for scoping.<br>
&lt;dael> leaverou: I agree with TabAtkins, people are used to using nesting for preprocessors. I dsiagree with my earlier comment. I think scoping is useful, Not sure usability of scoping prop. It shouldn't hold nesting back.<br>
&lt;dael> TabAtkins: Happy to have that separate.<br>
&lt;dael> astearns: Objections to working on a purely syntactic nesting proposal<br>
&lt;dael> astearns: One concern is if you can do it in a preprocessor why do it, but even the preprocessor authors are asking us to do it.<br>
&lt;dael> chris: preprocessor expands to a ton of stuff and we don't want that expansion<br>
&lt;gsnedders> It's one less reason to use a preprocessor, IMO.<br>
&lt;gsnedders> And that's a good thing.<br>
&lt;fantasai> s/wanted still/wanted or something different/<br>
&lt;dael> astearns: Maybe an issue that we want to avoid the exposion of conbinations that can happens<br>
&lt;bkardell_> better for authors, better for network, very slightly worse for processing perf maybe?<br>
&lt;dael> florian: For OM representation yes, but effect that's unavoidable<br>
&lt;dael> TabAtkins: CSS style rules gain a child. OM doesn't explode<br>
&lt;dael> chris: That's a big advantage<br>
&lt;dael> leaverou: Huge advantage you can fo hover or focus styles on a one off<br>
&lt;dael> TabAtkins: Originally a proposal to do rules inside style attribute and this doens't have that. You need only one token of look ahead.<br>
&lt;dael> astearns: Obj to resolving we want to move forward with pure syntactic nesting?<br>
&lt;dael> TabAtkins: And I want the impl to say if they actually don't want it.<br>
&lt;tantek_> I'm too confused to comment on this last minute on the call<br>
&lt;dael> dbaron: If you're discussing changing what's in proposal it would be good to have that written to share around<br>
&lt;dael> TabAtkins: Entire proposal is linked in the issue to a spec on my personal github. It's laid out with no odd changes<br>
&lt;dael> TabAtkins: We can go to next week<br>
&lt;dael> astearns: We're over time. I don't hear obj. I think we are going to move forward, but let's give people time and we'll come back.<br>
&lt;dbaron> I think for Gecko implementation it's probably worth asking heycam and emilio rather than me.<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2701#issuecomment-395251355 using your GitHub account
Received on Thursday, 7 June 2018 00:05:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 7 June 2018 00:05:19 UTC