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

121–130 of 170 posts

Re: Help choose the syntax for CSS Nesting

#121

Post by frosted-flakes »

One big advantage of option 3 is that it allows for putting properties and nested selectors in any order, rather than segregating them in different groups. This is already possible in Sass and I do it all the time. For example:

    .card {
        border: 1px solid;
        &:first-child {
            border-top: none;
        }
        background: blue;
        &:hover {
            background: red;
            color: yellowgreen;
        }

        display: flex;
        // etc.
    }

Re: Help choose the syntax for CSS Nesting

#122

Post by martin_a »

culi wrote: post #85
spoils19 wrote: post #23

Earlier quoted context omitted.

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

> That's harder to do the more tightly you couple your HTML and your CSS

That's probably why you shouldn't do that... ;-)

Re: Help choose the syntax for CSS Nesting

#123

Post by Sesse__ »

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…

It's not clear at all what that strict syntax would look like that would disambiguate with less lookahead. The fundamental problem is that colon is used both for declarations and in (pseudo-)selectors, not that people are somehow inventing corner-case CSS that nobody actually writes and we can just outlaw in a spec change.

The only change I can really think of would be requiring space after the colon for declarations (i.e. “color:red” is disallowed, it must be “color: red”), but that's much more than a strict mode, that's something that invalidates millions and millions of perfectly valid web pages and introduces a much larger whitespace sensitivity than today.

Re: Help choose the syntax for CSS Nesting

#124

Post by eCa »

hypertele-Xii wrote: post #115
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.…

> Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. So... 20 bytes or so? A whopping 20 megabytes per a million websites. Seems like a very, very, very small optimization.

20 bytes per rule. While not a fan of the syntax[1], there’s the advantage when reading of seeing that rules are explicitly nested versus doing string parsing of rule definitions.

[1] In particular the significant space char difference between &. And & .

Re: Help choose the syntax for CSS Nesting

#127

Post by Sesse__ »

runarberg wrote: post #51
Sesse__ wrote: post #11

Earlier quoted context omitted.

> 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…

What happened to the rule where if the nested selector doesn’t start with & then an explicit @nest is required? Doesn’t that fix the unlimited look-ahead?

That was option 1, and it was voted out for being unneccessarily verbose.

Re: Help choose the syntax for CSS Nesting

#128

Post by hypertele-Xii »

eCa wrote: post #124
hypertele-Xii wrote: post #115

Earlier quoted context omitted.

> Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. So... 20 bytes or so? A whopping 20 megabytes per a million websites. Seems like a very, very, very small optimization.

20 bytes per rule . While not a fan of the syntax[1], there’s the advantage when reading of seeing that rules are explicitly nested versus doing string parsing of rule definitions. [1] In particular the significant space char difference between &. And & .

Why does a website need more than one :hover rule?

Re: Help choose the syntax for CSS Nesting

#129

Post by somishere »

frivoal wrote: post #97
somishere wrote: post #20

Earlier quoted context omitted.

I guess the idea would be something along the lines of a 'strict' tag, to identify a shift to modern syntax with stricter rules around parsing, that ensures an infinite lookahead wouldn't be required for e.g. pseudos vs properties. I put together a regex last time this was discussed [1] (which obviously completely alleviates all concerns): https://regex101.com/r/aOc2Pz/1 But seriously, syntax evolutions happen. If th…

The reason why this cannot be done is documented in the csswg's informal FAQ: https://wiki.csswg.org/faq#versioning-css-fixing-design-mist...

The documented reasoning and references do not make any sense. Older browsers are going to choke on newer syntax regardless. This is an ongoing issue in the JS domain that is managed reasonably well via e.g. polyfills, tooling and rapid release. Often with code bloat initially, sure, but the browsers catch up. The days of "oldIE" are long gone.

The point of the declaration is to tell the browsers that can handle the syntax to handle it. Another method could be to use a new linking method. Regardless, the language would still gracefully degrade as only the newer syntax would require strict rules in place.

Please explain it to me if I am completely missing the point.

Re: Help choose the syntax for CSS Nesting

#130

Post by somishere »

Sesse__ wrote: post #123
somishere wrote: post #39

Earlier quoted context omitted.

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…

It's not clear at all what that strict syntax would look like that would disambiguate with less lookahead. The fundamental problem is that colon is used both for declarations and in (pseudo-)selectors, not that people are somehow inventing corner-case CSS that nobody actually writes and we can just outlaw in a spec change. The only change I can really think of would be requiring space after the colon for declarations…

The difference isn't the separator, it is the suffix. Strict designation would afford that either properties be signed off with a semi-colon on the same line (or just a newline). Alternatively you could go the other way and enforce selector signoff with a comma or a bracket on the same line. No strict, no nesting /newfangled wizardy.

This allows for graceful degradation.

My point about corner cases is that there is very, very limited use of pseudo selectors, relatively speaking. Let alone pseudo selection where the selector is based on an element and not a class, or ID, or something else easily differentiable from a property. Which is to say, they are the corner case.

Post reply on HN