- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Nov 2021 21:44:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-nesting] Syntax suggestion`, and agreed to the following:
* `RESOLVED: change nesting draft to use open/close brackets, and add a note to show that syntax vs. what Tab would prefer`
* `RESOLVED: our preference is for a single syntax for nesting`
* `RESOLVED: don't have nesting om using its own interface; instead, just allow style rule to contain a list of style rule`
<details><summary>The full IRC log of that discussion</summary>
<dholbert> topic: [css-nesting] Syntax suggestion<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4748<br>
<dholbert> TabAtkins: I'll give initial presentation, and then others can argue for their preferences<br>
<dholbert> TabAtkins: leaverou and fantasai have some [...]<br>
<dholbert> TabAtkins: the way it's written now, you can nest a style rule inside of another style rule<br>
<dholbert> TabAtkins: you need to use ampersand<br>
<fantasai> s/[...]/concerns about the currently-proposed syntax, particularly that it has two variants/<br>
<dholbert> TabAtkins: alternately, if you want it somewhere other than at the start, you use the @nest syntax<br>
<dholbert> TabAtkins: two suggestions in the thread. one: always require wrapping set of curly braces, to syntactically distinguish rules from properties<br>
<dholbert> TabAtkins: few other variants on that<br>
<fantasai> see Miriam's comment at https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-924118287<br>
<dholbert> TabAtkins: I objected, don't like it; it means any nested style rule ends up being indented two levels from its parent<br>
<dholbert> TabAtkins: any non-trivial amount of nesting really blows out your margin, gets far over in your code editor<br>
<dholbert> TabAtkins: What I settled on at the end is just to always require an @nest rule. Throw away completely unlabeled rule, always use @nest<br>
<dholbert> TabAtkins: possibly be able to have @nest without a selector and nest style rules inside of that<br>
<dholbert> TabAtkins: not sure I like that part, OM will get a little messy, similar to how layer has two representations for same rule name<br>
<dholbert> TabAtkins: my initial proposal is that you remove the direct nesting and always make you use @nest rule<br>
<dholbert> fantasai: I think that I'd like to pick a syntax that's consistent, so there aren't multiple variations that are different. that's confusing<br>
<dholbert> fantasai: we should pick a syntax that's not noisy, since this is going to be used all over the place. This is a structural thing, and basic; I expect to see this a lot in the future<br>
<dholbert> fantasai: I don't have a problem with the extra indentation; that's an argument for not using very large indents, basically<br>
<dholbert> fantasai: leaverou raised some issues about how you'd handle the nested version of [...] mixed with selector lists, which is awkward<br>
<TabAtkins> Lea's comment: https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-940160175<br>
<dholbert> fantasai: I think the curly-brace syntax is fine, I understand you don't like it, want to hear from other people<br>
<dholbert> astearns: I'm not a big fan of the pure-symbol syntax, whether it's braces or ampersand. more difficult to notice, search for<br>
<dholbert> astearns: if everything required @nest, that seems easier to read, if slightly more difficult to type<br>
<dholbert> fantasai: you have to balance that against how basic is the syntax & how often it will be used<br>
<dholbert> fantasai: e.g. we don't have @style for style rules; we just have selectors<br>
<dholbert> fantasai: we don't write begin/end; CSS syntax is built out of these symbols<br>
<dholbert> fantasai: we have other selectors like @font-face which aren't used all the time, so they have to be clear<br>
<dholbert> fantasai: nesting syntax is closer to the former case, so most stylesheets will have a lot of it. so we don't need to have a keyword to make it searchable; it'll just be an obvious way to structure your CSS<br>
<dholbert> fantasai: people have been using nested selectors in preprocessors without any kind of keyword<br>
<dholbert> fantasai: maybe we end up with a keyword, but I don't know that we need to<br>
<dholbert> fantasai: having it all over your stylesheet, in front of every single rule, would be terribly noisy. they're not important<br>
<dholbert> fantasai: the markup should fade into the background<br>
<dholbert> astearns: is that an argument for only doing open/closing braces?<br>
<dholbert> fantasai: if we're insisting on a keyword, we could do @nest with braces. If we have it in front of every selector, that would be noisy<br>
<dholbert> fantasai: if we're going to have curly braces, you might as well just put them there. don't need a keyword<br>
<dholbert> fantasai: as long as we're not requiring it in front of everything, it's less of an issue<br>
<dholbert> miriam: not surprisingly, I agree with fantasai<br>
<TabAtkins> https://www.irccloud.com/pastebin/HyBOx2gA/<br>
<dholbert> miriam: I like how clean and simple and unrepetitive it is<br>
<dholbert> astearns: do you always get extra indentation, or is it possible to have a bare selector and then its decl block indented once?<br>
<dholbert> fantasai: it's up to your own indentation file & how you organize your code<br>
<dholbert> fantasai: the idea is, inside a selector, you put open and close curly braces in the same spot where you would put a declaration<br>
<dholbert> fantasai: and that indicates you're going to put some style rules<br>
<TabAtkins> https://www.irccloud.com/pastebin/nakoTt1z/<br>
<dholbert> fantasai: and that's important for selector parsing [...]<br>
<miriam> the proposal we made in this comment: https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-924118287<br>
<dholbert> fantasai: at the top of the proposal, there was a suggestion to use parenthesis<br>
<dholbert> fantasai: if you're not mixing declarations and style rules in the same selector block, you can just double-up your curly braces and indent one level<br>
<dholbert> fantasai: and that's pretty reasonable, but if you're mixing, you probably want to indent two levels for the case where you're including a selector<br>
<fantasai> s/of the proposa/of the issue/<br>
<fantasai> s/parenthesis/parenthesis, which is roughly what we're proposing here, except using curly braces/<br>
<dholbert> astearns: so we have two competing ideas<br>
<TabAtkins> (I find all the ways to avoid extra indents being easy to mess up, especially when editting later.)<br>
<dholbert> astearns: I like the idea of having a single syntax, not an at-rule vs ampersand depending on syntax<br>
<dholbert> astearns: sounds like either we use at-rule everywhere or open/close braces everywhere<br>
<dholbert> astearns: not hearing consensus, I'm hearing "I could live with"<br>
<dholbert> TabAtkins: I really really don't like the double-indent<br>
<dholbert> TabAtkins: people can't easily adjust indentation files without messing with other code<br>
<dholbert> TabAtkins: [...]<br>
<dholbert> astearns: one argument for the bracketed version: it's easy to see what's being declared at each level of indentation<br>
<dholbert> astearns: you can read down a column and it's all the same sort of thing at a given level of indentation<br>
<dholbert> fantasai: if we don't just do curly-braces, you'll need to prefix every single selector with somehting<br>
<dholbert> fantasai: don't want that to be @nest; that's too noisy<br>
<dholbert> fantasai: single symbol is not so bad<br>
<florian> I'm mildly in favor of the braced syntax, but I don't feel terribly strongly either way<br>
<heycam> q+<br>
<dholbert> fantasai: nesting another block in there is the right way to go<br>
<TabAtkins> ack<br>
<TabAtkins> zakim, ack<br>
<Zakim> I don't understand 'ack', TabAtkins<br>
<TabAtkins> ack TabAtkins<br>
<dholbert> heycam: agree with fantasai<br>
<astearns> ack heycam<br>
<dholbert> heycam: indentation is least important consideration of the things we're considering<br>
<dholbert> heycam: we often add @media or @supports rules and don't worry about additional indentation there<br>
<dholbert> heycam: I agree @nest syntax looks pretty noisy<br>
<dholbert> TabAtkins: @media usually isn't nested<br>
<dholbert> TabAtkins: I'm not worried about one level of indentation, but rather 3 levels<br>
<fantasai> s/not so bad/not so bad, but then selector prelude in unnested style rules will be different from nested style rules which is also not great/<br>
<dholbert> TabAtkins: that's enough to trigger lint warnings in many systems<br>
<dholbert> astearns: I have a terrible idea<br>
<dholbert> astearns: each nested selector could start with three colons<br>
<dholbert> astearns: we've only used 2 so far!<br>
<dholbert> astearns: [sarcasm, I think :D ]<br>
<dholbert> astearns: anyone who wants to publicly argue against bracket syntax? (aside from TabAtkins )<br>
<dholbert> astearns: small number of folks on call, but let's try a small straw poll<br>
<miriam> {}<br>
<TabAtkins> @nest<br>
<smfr> {}<br>
<fantasai> {}<br>
<astearns> {}<br>
<florian> {}<br>
<vmpstr> {}<br>
<heycam> {}<br>
<hober> {}<br>
<dholbert> {}<br>
<dholbert> astearns: are you ok with brackets, TabAtkins ?<br>
<dholbert> TabAtkins: I really want to show a normal stylesheet and how hugely indented it gets<br>
<dholbert> TabAtkins: happy to take a provisional resolution for now<br>
<dholbert> astearns: what does SASS use?<br>
<dholbert> TabAtkins: nothing, you just directly nest them in. Three deep = three indents<br>
<dholbert> astearns: and that's not possible for us?<br>
<dholbert> TabAtkins: there are certain selectors you can construct that look like property declarations<br>
<dholbert> TabAtkins: requires too much lookahead for UAs to implement that<br>
<astearns> ack fantasai<br>
<emeyer> +1 to seing side by side code examples<br>
<dholbert> astearns: should be a note in the spec<br>
<dholbert> astearns: proposed resolution: change nesting draft to use open/close brackets, and add a note to show that syntax vs. what Tab would prefer<br>
<dholbert> RESOLVED: change nesting draft to use open/close brackets, and add a note to show that syntax vs. what Tab would prefer<br>
<dholbert> fantasai: we also should resolve to have a single syntax for nesting<br>
<dholbert> RESOLVED: our preference is for a single syntax for nesting<br>
<dholbert> TabAtkins: one final question in this: right now, the spec defines the nested style rules to use a different OM class. the css nesting rule interface<br>
<dholbert> TabAtkins: if we're using a single syntax, then I don't think that makes a lot of sense?<br>
<dholbert> TabAtkins: they are in every possible way equivalent to a style rule<br>
<dholbert> TabAtkins: so my proposal is to just switch to use the existing CSS Style Rule interface in cssom<br>
<dholbert> astearns: so the only change is to change cssom to allow style rule to contain a list of style rules<br>
<dholbert> astearns: proposed resolution: not have nesting om using its own interface; instead, just allow style rule to contain a list of style rules<br>
<dholbert> RESOLVED: don't have nesting om using its own interface; instead, just allow style rule to contain a list of style rule<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-960145492 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 November 2021 21:44:18 UTC