Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Help choose the syntax for CSS Nesting

webkit.org

Post reply on HN
Print view View original

81–90 of 170 posts

Re: Help choose the syntax for CSS Nesting

#81

Post by culi »

toastal wrote: post #77
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.

I've stopped using preprocessor for years now. Almost everything I need is now in the spec or solved ‘good enough’ through a naming scheme. IMO, a preprocessor is a lot of complexity for little gain currently.

Eh. I kinda hate writing separate selectors just for a `:hover`

I agree CSS has come a long way. Nested CSS is the one thing I'm waiting for before I completely abandon preprocessors.

Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. Sure, better practices could usually make this unnecessary, but there's definitely valid situations for it. If you add up all the extra kb across millions of sites, and all the extra savings minifiers would be able to achieve with this syntax, I'd bet it starts to add up at a certain point

I was sad to see it left out of 2022-interop, but it's definitely the biggest feature I'm waiting for

Re: Help choose the syntax for CSS Nesting

#82

Post by culi »

wnevets wrote: post #16
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.

> stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read. That is my biggest take away from this whole thing. The SASS/LESS syntax is so much easier to read to me.

I don't really get how tbh. Isn't Option 3 the exact same thing as Sass except the "&" is required in a few more places than it is in Sass? It's also optional in Sass so I already write that way (always using the "&") personally

Re: Help choose the syntax for CSS Nesting

#83

Post by alwillis »

toastal wrote: post #77
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.

I've stopped using preprocessor for years now. Almost everything I need is now in the spec or solved ‘good enough’ through a naming scheme. IMO, a preprocessor is a lot of complexity for little gain currently.

> I've stopped using preprocessor for years now.

I decided to not use Sass on my latest project; feels like CSS is at the point where I didn't need it any more. CSS has come a long way.

Re: Help choose the syntax for CSS Nesting

#84

Post by culi »

jorams wrote: post #25

I'm a bit confused about the constant mention of option 3 in this article, because it seems to match none of the actual options from the original poll. The original poll offered three options: Option 1: @nest. Requires either starting a nested selector with &, or prefixing it with @nest if the & should not be at the start. Option 2: @nest restricted. Always requires starting with @nest. Option 3: Additional brackets…

> Additional brackets to group nested selectors.

Isn't this what Sass does? Option 3 seems to me to be exactly Sass nesting except the "&" is required in more places than it is in Sass. I personally love the "&" and already write my Sass that way anytime I nest

Re: Help choose the syntax for CSS Nesting

#85

Post by culi »

spoils19 wrote: post #23
martin_a wrote: post #3

Do we really need this? I find all the examples harder to read and understand than combining classes/elements.

Nesting is a solution in search of a problem. Combining classes has worked fantastically for me over the last 15 years.

that's great, but sometimes when I start vanilla side projects I like to take a CSS Zen Garden approach to things. That's harder to do the more tightly you couple your HTML and your CSS

Re: Help choose the syntax for CSS Nesting

#86

Post by alwillis »

culi wrote: post #81
toastal wrote: post #77

Earlier quoted context omitted.

I've stopped using preprocessor for years now. Almost everything I need is now in the spec or solved ‘good enough’ through a naming scheme. IMO, a preprocessor is a lot of complexity for little gain currently.

Eh. I kinda hate writing separate selectors just for a `:hover` I agree CSS has come a long way. Nested CSS is the one thing I'm waiting for before I completely abandon preprocessors. Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. Sure, better practices could usually make this unnecessary, but there's definitely valid situations for it.…

> I was sad to see it left out of 2022-interop, but it's definitely the biggest feature I'm waiting for

My understanding is the features for Interop were chosen because there wasn't good interoperability between browsers for them.

With CSS Nesting, once the spec (and the syntax) is finalized, it's going to work the same in all browser engines; hopefully it'll go smoothly and we won't need CSS Nesting be part of Interop 2023.

Re: Help choose the syntax for CSS Nesting

#87

Post by culi »

alwillis wrote: post #86
culi wrote: post #81

Earlier quoted context omitted.

Eh. I kinda hate writing separate selectors just for a `:hover` I agree CSS has come a long way. Nested CSS is the one thing I'm waiting for before I completely abandon preprocessors. Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. Sure, better practices could usually make this unnecessary, but there's definitely valid situations for it.…

> I was sad to see it left out of 2022-interop, but it's definitely the biggest feature I'm waiting for My understanding is the features for Interop were chosen because there wasn't good interoperability between browsers for them. With CSS Nesting, once the spec (and the syntax) is finalized, it's going to work the same in all browser engines; hopefully it'll go smoothly and we won't need CSS Nesting be part of Inter…

Correct. I meant the "2022 Investigation" section of it which accounts for 10% of the grade and focuses on future features

Re: Help choose the syntax for CSS Nesting

#88

Post by toastal »

culi wrote: post #81
toastal wrote: post #77

Earlier quoted context omitted.

I've stopped using preprocessor for years now. Almost everything I need is now in the spec or solved ‘good enough’ through a naming scheme. IMO, a preprocessor is a lot of complexity for little gain currently.

Eh. I kinda hate writing separate selectors just for a `:hover` I agree CSS has come a long way. Nested CSS is the one thing I'm waiting for before I completely abandon preprocessors. Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. Sure, better practices could usually make this unnecessary, but there's definitely valid situations for it.…

I wouldn't disagree. Nesting state and pseudo selectors can clean up code.

Re: Help choose the syntax for CSS Nesting

#89

Post by alwillis »

nailer wrote: post #19

I want browsers to have first class Sass support. Pave the cowpaths etc.

> I want browsers to have first class Sass support.

We don't want that.

For example, CSS Custom Properties (CSS variables) are far more powerful than Sass variables. Plus you'd have two different implementations for how variables work—CSS variables work with the cascade but Sass variables don't. You can't have two fundamentally different methods for variables. That's a non-starter.

Pretty much all of the good stuff from preprocessors is going to be implemented in CSS (including conditional statements) relatively soon; we're just not there yet. But CSS Nesting is an important first step.

Re: Help choose the syntax for CSS Nesting

#90

Post by notpushkin »

culi wrote: post #82
wnevets wrote: post #16

Earlier quoted context omitted.

> stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read. That is my biggest take away from this whole thing. The SASS/LESS syntax is so much easier to read to me.

I don't really get how tbh. Isn't Option 3 the exact same thing as Sass except the "&" is required in a few more places than it is in Sass? It's also optional in Sass so I already write that way (always using the "&") personally

Most of the time, yeah, but there's a corner case (example C from the article):

    a:hover {
      color: hotpink;
      :is(aside) & {
        color: red;
      }
    }
Here, you can't just use `aside &` as this starts with a letter and will confuse the parser. Hence, wrapping with `:is()` is requires.
Post reply on HN