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

111–120 of 170 posts

Re: Help choose the syntax for CSS Nesting

#111

Post by alwillis »

LudwigNagasena wrote: post #103
alwillis wrote: post #75

Earlier quoted context omitted.

> What is even the problem? People use preprocessors, poly-fills, hot-reloading, etc anyway. It isn't 1990s. All of this tooling is used because of missing CSS features for the most part. The web browser's ethos is to be a viewing and authoring environment; from Netscape Navigator on, browsers have enabled its users to write HTML and later, CSS. For that to continue, browsers we can't have web authoring that's depend…

Everything is still going to be tree-shaken, minified and mangled before being transferred to the client; no matter how much bells and whistles are added to web languages. Why not just make it decoupled and efficient? Compiling code isn't a radical idea.

As pointed out in the article, the nesting syntax has to work in every setting that CSS works in today and has always worked in—from a hobbyist working alone on a side project to teams working on huge code bases and everything in between.

Because of the universality of the web, anyone from a kid in a developing country with a netbook and a text editor to teams at Fortune 500 companies need to be able to author CSS.

It's a non-starter to require all kinds of tooling—preprocessors, compilers, task runners, packagers, etc. to create web content. You can use these tools if it makes sense for a particular situation but it should always be optional.

BTW, browsers already use Just In Time compilers [1] to render CSS as efficiently as possible; all of the tooling you mentioned is mostly to reduce the size of CSS payloads over a network. Regardless if you minify CSS or not, its rendering speed isn't going to change.

With these tools, there's no compiling happening anyway, just transforming one text format (Sass) to another text format CSS. It's not like WebAssembly where code is compiled into a byte-code format that runs in a virtual machine.

[1]: https://webkit.org/blog/3271/webkit-css-selector-jit-compile...

Re: Help choose the syntax for CSS Nesting

#112

Post by lifthrasiir »

lifthrasiir wrote: post #40
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…

To elaborate why you need unlimited lookahead, consider the following: h1:has(+ p) { something: anything; } h1 { something: nothing; } everything: has(+ p) { something: anything; }; h1 { something: nothing; } Syntactically speaking these two lines are equivalent except for a single semicolon; the differing first token doesn't change anything about that. And you can absolutely add a custom element that looks like a pr…

Pretty much late edit: in the second line `: has` to be `:has` with no whitespace (as CSS parsers do care about whitespaces in some contexts).

Re: Help choose the syntax for CSS Nesting

#113

Post by franciscop »

bongobingo1 wrote: post #99
franciscop wrote: post #91

Earlier quoted context omitted.

Optional and being able to require it with e.g. a linter on a per-project basis seems better idea for me, since I'd strongly prefer not using & and for the vast majority of cases (as we learned from SASS) it's not needed.

Q for Smarter people than me with more experience: is it better to require stricter upstream and loosen the downstream (so would require &, and MyCSS framework could insert them where needed) or looser upstream and tighten local code with linters? "be conservative in what you do, be liberal in what you accept from others" applies?

The problem is that "MyCSS framework" would not be a CSS framework, it'd be a full build system if it's incompatible, so that way no one would use the looser form. So if it's looser upstream, you can always tighten it more downstream in a fairly seamless and optional way, while the opposite is not really true.

Re: Help choose the syntax for CSS Nesting

#114

Post by wruza »

I like the idea of using newlines to alleviate some syntactical issues. Here is what I came up with after experimenting with option 4:

  .foo 
    { color: red
  ;}{ .bar
        { color: blue
    ;} p 
        { color: yellow
    ;}
  }
If you make punctuation dimmer in your editor, it becomes a nicely aligned structure, also a toplevel ;} denotes a beginning of a nesting block, it’s like “hey look here as well ;}” and searchable with /^;}{.

Re: Help choose the syntax for CSS Nesting

#115

Post by hypertele-Xii »

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

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

Re: Help choose the syntax for CSS Nesting

#116

Post by wruza »

Klonoar wrote: post #15
somishere wrote: post #13

Earlier quoted context omitted.

Possibly a stupid question. But is there a reason you couldn't include 2 engines? And require e.g. a doctype assertion?

Because it's the same result as if you just included the slower one, since there's mindshare for the SASS variant already - it'll just become defacto standard, and slow down the web. The line in the sand here is good.

This mindshare is mostly among end developers. Big frameworks will still compete in performance (iff it really that matters, the numbers are kept in secret for some “full-stop” reason) and use preprocessing and boil-down minification as they are now.

The implied impact is based on a wrong assumption and unpublished effects.

Re: Help choose the syntax for CSS Nesting

#118

Post by Sesse__ »

claytongulick wrote: post #42
Sesse__ wrote: post #32

Earlier quoted context omitted.

Have you looked into @scope?

I haven't! I found this [1] which basically has everything I want, but apparently it's been deprecated, which makes me sad. Searching, I found [2], is that what you're referring to? It looks like it'll do what I'm after, if a bit less gracefully. Exciting though! [1] https://css-tricks.com/saving-the-day-with-scoped-css/ [2] https://drafts.csswg.org/css-cascade-6/#scope-atrule

Yes, the latter. At least Chromium-based browsers support it behind a flag (ie., you can't use it on the web yet, but you can experiment with it and file feedback). I don't know if Firefox does, too, but they very well might.

Re: Help choose the syntax for CSS Nesting

#119

Post by bryanrasmussen »

what will nesting do to the cascade rules - I suppose that

.foo { & .bar { color: blue; } }

will have the same precedence rules as

.foo .bar { color: blue; }

in which case it is probably best to avoid the usage in most cases.

Given CSS variables, container queries and various other developments nesting seems like a bad way to organize your CSS.

on edit: to clarify my experience with sass is that people nest overly much, creating very complicated precedence situation that then later they can't figure out why their bar class is blue.

Re: Help choose the syntax for CSS Nesting

#120

Post by alwillis »

toomanydoubts wrote: post #24
spankalee wrote: post #10

Earlier quoted context omitted.

Did you read the third paragraph in the article?

I think the question that's not answered clearly is: why can Sass parse it, but browsers can't? It says: "If they see a sequence like element:pseudo, they’ll parse the entire style rule as if it were a property: value declaration.", but why can't the parser be modified to work like Sass parser? Maybe it's obvious for someone who has deep parser knowledge, but for someone who only has a superficial knowledge, this is…

> I think the question that's not answered clearly is: why can Sass parse it, but browsers can't?

I'm tired but here goes…

Parsing the proposed syntax isn't the real problem; it's parsing plus executing the selectors. Long story short: CSS is programming language that uses a JIT compiler to render CSS.

Sass doesn't run anything; it just transforms one text format into another text format; it's the browser runs the CSS.

Compared to what's required for CSS to run inside of a browser, interface with HTML, JavaScript and SVG (for starters), the Sass parser is trivial in comparison.

> Does this all just boil down to "we don't want to have the work of rewritting the CSS parser"?

Seriously, that's a non-starter for a code base the size and complexity of a browser engine. Not to mention it could mean throwing away years of work on these browser engines.

It's way too late for that… Chrome already has option 3 implemented; to rewrite something would delay this by… a few months? Maybe a year?

Think about it: should Apple, Google, Mozilla, Microsoft, Igalia rewrite code that's already running successfully for billions of users to accommodate whiney developers, many of whom are going to keep using Sass anyway, no matter what they do?

I doubt any of us, if we were leading these teams, would think rewriting major portions of the browser engines makes any kind of sense at this point.

[1]: https://drafts.csswg.org/css-nesting/

Post reply on HN