- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Oct 2022 17:01:02 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-nesting-1] Syntax Invites Errors`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: [css-nesting-1] Syntax Invites Errors<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7834<br> <emeyer> scribenick emeyer<br> <emeyer> astearns: fantasai has suggested we should focus on this call on whether we replace the text in the specification with option 3, and then have further discussion later on proposal 4.<br> <TabAtkins> +1<br> <lea> +1<br> <bramus> SGTM<br> <astearns> https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md<br> <emeyer> astearns: We have four options with pros and cons, and some poll results<br> <emeyer> …Most positions are between options 3 and 1, with a smattering of 2 and 4.<br> <astearns> ack fantasai<br> <lea> I have added some vote counts under the table<br> <emeyer> fantasai: many considerations here. We have problems with the current syntax, which requires a lot of ampersands that are hard to remember where they’re needed<br> <emeyer> …we also want portability of the code structures is a concern with the current syntax<br> <emeyer> …there was another concern about confusion over spaces, but that seems minor<br> <emeyer> …Our options are: always prefix, nest into blocks, use a switch to change modes<br> <emeyer> …We explored many possible syntaxes. Lea?<br> <emeyer> lea: Option 3, you can nest without ampersands for most selectors<br> <TabAtkins> q+<br> <jensimmons> q+<br> <emeyer> …except the only descendants you need ampersands is element selectors<br> <argyle> q+<br> <emeyer> …The advantage is there’s no parser switch, and it’s also much less verbose than current syntax<br> <emeyer> …If you have a descendant selector that start with an element, you do need to ampersand that<br> <emeyer> …Compatibility with Sass is not a concern here, because it’s a one-time cost<br> <emeyer> …In general, the closer we can get to the Sass syntax, the better; developers like it<br> <emeyer> …People find the current syntax quite noisy<br> <emeyer> …We might also be able to relax syntax in the future, if we can figure out a way to do so<br> <emeyer> astearns: Ampersands not required, but allowed, yes?<br> <fremy> q+<br> <emeyer> (collective affirmation)<br> <emeyer> fantasai: Devs seem split 50/50 on use of ampersands or not<br> <emeyer> …As far as the proposal, the basic rule for nesting a selector is that you can’t start with a letter<br> <astearns> ack TabAtkins<br> <dbaron> (I think it's a letter or a dash?)<br> <lea> dbaron: yes<br> <emeyer> TabAtkins: While I initially supported option 1, having looked through the details, option 3 is very good<br> <emeyer> …It most of the time gives you the ability to write like in Sass, with one awkward exception that’s easy to tell apart<br> <bradk> Sorry to be so incredibly late<br> <emeyer> …Most of the time you can use an ampersand to nest and it works out fine<br> <emeyer> …The rule for whether you need it or not is very clear, and this does allow us to be close to Sass<br> <astearns> ack jensimmons<br> <emeyer> jensimmons: There are a lot of things about option 3 I really like, but the one thing I feel is a non-starter from my perspective is that not all selectors are treated the same<br> <emeyer> …Authors have to know that nesting is easy most of the time, except in this one case<br> <lea> Clarification: I didn't say element selectors were rare *at all*. Element selectors where the parent selector is inserted later (e.g. strong &) is rare.<br> <emeyer> …I understand the mitigations, the problem is teaching authors that this one selector type is weird, and the syntax isn’t consistent across all selector patterns<br> <astearns> ack argyle<br> <lea> q+<br> <emeyer> argyle: When you go to paste and forget the &, that’s a problem, but syntax highlighters are there to help authors<br> <emeyer> …Option 1 is the most portable because it’s unambiguous<br> <emeyer> …The community outside the WG has already passed the WG, which may be why a lot of people didn’t seem to case about the verbosity<br> <emeyer> …Option 1’s simplicity is appealing for tooling and to machines<br> <emeyer> …Teaching option 1 is easy, because it’s very consistent<br> <emeyer> …Teaching 3 or 4 gets muddy and complicated<br> <miriam> q+<br> <emeyer> …I did like the idea that most of the suggestions of 3 and 4 build on option 1, so I like the idea of going with option 1 and then in Level 2, we could use 3 and 4<br> <emeyer> …This would let us unblock engines that already do option 1 now<br> <fantasai> 4 doesn't build on 3 or 1 or anything<br> <TabAtkins> 3 has exactly one exception, same as 1 (and imo of the same complexity). 4 has no exceptions. It was the 2 variants that had slightly more complex requirements.<br> <fantasai> and also doesn't have any exceptions<br> <astearns> ack fremy<br> <argyle> correct, 4 doesnt build on 1, my bad<br> <emeyer> fremy: I’m glad that we aren’t considering option 2. I’m mixed between 1 and 3, and agree with the points mentioned before<br> <emeyer> …I’m kind of okay with 1, would be fine with 3, the consistency of 1 feel better<br> <emeyer> s/feel/feels/<br> <emeyer> If I had to choose, I’d probably say 1, but wouldn’t be mad if we choose 3<br> <emeyer> …I see myself converting nested rules into scoped rules, which we aren’t really addressing<br> <argyle> memorizing idents shouldnt be a requirement to nest effectively..<br> <emeyer> …Having a syntax incompatible with :scope is annoying and a downside<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <emeyer> …You shoudl be able to copy and paste anything and not have to rewrite anything<br> <astearns> ack lea<br> <emeyer> lea: Replying to jensimmons, I didn’t say element selectors are rare, but that element selectors where the ampersand comes later are rare<br> <astearns> ack miriam<br> <emeyer> miriam: Both proposals have weird edge cases<br> <fantasai> lea mentioned that `strong &` is rare, but `& strong` is fairly common and can be done with & as today<br> <emeyer> …in option 1, you have to learn when to use or not use @nest<br> <emeyer> …in option 3, you have to learn when to use ampersands with a descendant<br> <emeyer> …In my mind it’s a little easier to teach, because I can teach that you always have to start with a symbol<br> <fremy> miriam: we could just replace `@nest` with `&` and say that if there are one at the start and one later one, the one later one wins<br> <emeyer> …I do see Adam’s point that 1 and 3 are interoperable if we want them to be<br> <emeyer> …I don’t know if that’s an interesting approach to take, but it is possible<br> <jensimmons> I wish we had time to talk about option 4. If we ended up like 4 best, there's no need to debate 1 vs 3, etc.<br> <emeyer> astearns: I think it’s intriguing to do 1 and then allow 3 in the future<br> <bradk> I agree with the idea that #3 still allows you to do #1<br> <emeyer> …We need to take this back to the issue and come back to this next week with another scoped-time discussion<br> <emeyer> …Please do discuss further in the issue.<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-1284314893 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 October 2022 17:01:04 UTC