Help choose the syntax for CSS Nesting

Post by runarberg » Fri, Dec 16, 2022, 1:20 AM UTC

Sesse__ wrote: post #11

slinger wrote: post #5

> Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible, however, because of the way browser parsing engines work. I wish browser vendors could work around this limitation and stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read.

> I wish browser vendors could work around this limitation and stick to Sass syntax. FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web w…

Post by runarberg » Fri, Dec 16, 2022, 1:27 AM UTC

Post by flappyeagle » Fri, Dec 16, 2022, 1:31 AM UTC

somishere wrote: post #39

Sesse__ wrote: post #18

Earlier quoted context omitted.

If nothing else, it would strongly increase maintenance and testing costs. You also have the usual problems of cut-and-paste between examples and stylesheets not necessarily working as you'd expect. Then there's the subtle issue like how you'd serialize such things from CSSOM (JavaScript); which parser mode would you use? How would you serialize something “unsupported” in one mode that was created by CSSOM? Which mod…

Understood. But if the idea was for a 'strict' syntax? i.e. in order to make use of newer syntax rules, CSS would need to declare itself as such and be formatted per spec (and would fail to parse otherwise, same as now), negating the need for "infinite lookaheads" per the explainer. So it's more like a switch statement than multiple engines. CSSOM is straightforward this way, you're dealing with strict by default. In…

Post by RheingoldRiver » Fri, Dec 16, 2022, 1:36 AM UTC

joeydi wrote: post #26

I think the reason this debate continues to rage on is that all of the options are worse than what is currently available with pre-processors. If CSS can’t match or improve on the obvious syntax used by sass then they should not implement it. All of these options are confusing. Nesting is not a requirement for CSS. Just let it go and if you want nesting use sass.

Post by chrismorgan » Fri, Dec 16, 2022, 1:48 AM UTC

jasonhansel wrote: post #50

I prefer Option 3, but IMHO the "&" should be required in all cases. Having it present in some places and absent in others makes the resulting code less readable, more ambiguous, and generally harder to understand. I'd rather keep things simple and uniform, even if it costs extra keystrokes. Also: it would allow things like ".a { &.b { x: y; } }" (which would be equivalent to ".a.b { x: y; }") to be clearly different…

  parent {
      /* This might or might not work. */
      > child {
          …
      }
  }

  parent {
      & > child {
          …
      }
  }