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

141–150 of 170 posts

Re: Help choose the syntax for CSS Nesting

#141

Post by Sesse__ »

somishere wrote: post #130
Sesse__ wrote: post #123

Earlier quoted context omitted.

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

Once you start looking at the suffix to disambiguate what the first token means, you're already in the more-than-one-token lookahead land, which is what we're trying to avoid in the first place.

CSS property declarations already need to be signed off with a semicolon on the same line. If not, the entire declaration is ignored (this is specified in the CSS standard, and if you don't implement it correctly, you will break real web pages).

Re: Help choose the syntax for CSS Nesting

#142

Post by jacobp100 »

runarberg wrote: post #53

It feels weird that the CSS WG does a popular vote for a different syntax implementing the same feature, something that an expert opinion should weigh way more then popular demand. But at the same time TC39 picked an archaic version of the pipeline operator (|> https://github.com/tc39/proposal-pipeline-operator ) despite a clear demand from the community to pick a functional one. Perhaps the two committees should lea…

The version they’re picking is the fast pipe from OCaml, and the only pipe in ReScript. It works much better for type inference, and avoids the extra allocations the FP pipe usually incurs

Re: Help choose the syntax for CSS Nesting

#143

Post by [deleted] »

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…

[deleted]

Re: Help choose the syntax for CSS Nesting

#145

Post by specialist »

Whichever option the boffins decide, nested and flattened should be isomorphic. And used interchangeably.

Like this, but for CSS: https://github.com/wnameless/json-flattener

Sharp observers will notice that flattened declarations look like path expressions.

While CSS selectors are nice, path expressions enable concise drill down to precise modifications (overrides).

For future, every programming language should have intrinsic path expressions. Basically a useful, usable, legible version of LINQ.

--

PS- I really don't get the '&' ampersand. It's like a reference?

"foo.bar { ... }" is sugar for the expanded "foo { bar { ... }}". Makes sense. (No ampersand required.)

But "foo { bar & { ... }}" being the same as "bar foo { ... }" breaks my brain. What's the use case for reversing the parent-child relationship, contrary to the lexical order?

Update: Oh. It's a SASS thing. Meh.

Re: Help choose the syntax for CSS Nesting

#146

Post by Vinnl »

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…

Unfortunately, you would still have the problem of seemingly-arbitrarily needing `:is` in some cases, when the & isn't at the start of a declaration.

So e.g.

  .someClass {
    :is(a) > & {
      font-weight: 700;
    }
  }
instead of the more intuitive (but impossible)

  .someClass {
    a > & {
      font-weight: 700;
    }
  }

Re: Help choose the syntax for CSS Nesting

#147

Post by Vinnl »

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 do wonder whether "no nesting" should've been an option in the poll. Not because I necessarily think it's the right option, but it might be: if this gets added to CSS, but people keep using other tools for easier nesting, then we're stuck with that implementation nonetheless.

Re: Help choose the syntax for CSS Nesting

#148

Post by [deleted] »

culi wrote: post #84
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

[deleted]

Re: Help choose the syntax for CSS Nesting

#150

Post by extra88 »

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

Earlier quoted context omitted.

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?

At minimum, you'll likely have different effects for links than for buttons.

Component-centered design is very common so the styles for each component that would benefit from :hover may have its own variation on it, for the color differences if nothing else.

:hover is not the only interaction pseudo-class, :focus and :active can also be nested.

Post reply on HN