Hacker News Reader

Comment by tannhaeuser | Hacker News Reader

It also looks like asking the general public for a go to make CSS even more complicated, when we all know it's a one-way ticket to Chrome dominance, ie a rhetoric dictators have been using. Note the absence of the option to "do nothing" and keep good-damn CSS as it is already after 25+ years of tinkering that haven't solved its problems.

I mean even one of the long-term editors of the CSS spec has raised hands and warned against including ever more inessential and author-oriented features [1]. That was almost 14 years ago.

[1]: https://www.w3.org/People/Bos/CSS-variables

View on HN

CSS has evolved tremendously. Variables are amazing, so is flex and grid.

Nesting is way overdue. But of course we shouldn’t be discussing it at Google’s site.

Variables (since they are not just constants), flex and grid all allow doing things that were previously not possible or at least not reasonably. Nesting is a pure syntax change that is already solved via a preprocessing step. So yes, we should weight what this adds in convenience vs. the cost of the adding this to all browsers, maintaining support for it forwever, the impact it has on future additions as well as new websites using this not working on older browsers. Note the should - I'm perfectly aware that the web dev ecosystem already often ignores many of these.

We kind of had variables with preprocessing before. Or a simple sed ‘s/str/replace’.

But true support is convenient. One of the best places to write CSS is the browser’s dev tools. Having CSS variables work there is awesome.

If it can be parsed almost as fast, I say go for it.

Those are constants. CSS variables are more powerful than that since they can be changed at runtime which allows e.g. minesweeper in pure HTML and CSS: https://github.com/propjockey/css-sweeper

Scoping and nesting are two things that would solve 99% of problems when it comes to organising CSS (and components). They should definitely be on the browser level and not "solved by preprocessors".

I disagree. Given the enormous complexity browsers have aggregated already, we should strive to make browsers "player apps" (like MP3 players): a relatively simple front end with huge versatility in server apps and back ends, rather than, like, everything for everybody. I'm aware that ship has sailed a long time ago, but piling ever more not-so-well-motivated stuff onto browsers just means the next generation has to start over with a clean slate; actually I think this is inevitable already.

CSS nesting is clearly serving the use case of components in web apps, as opposed to mere content-driven web sites. IMO a sensible approach would be to give web app developers powerful ways to tie into rendering and layout programmatically (a la Houdini API) when those apps will require JavaScript, and in many cases use CSS-in-JS anyway, rather than burden browser cores with ever more questionable CSS features.

"Would solve 99% of use cases" also sounds like famous last words ;)

> a relatively simple front end with huge versatility in server apps and back ends

Define "relatively simple"?

Nesting and scoping in CSS don't make frontend any more complex. CSS has had problems with it's flat top-level structure since the very beginning of its existence. Approaches like BEM didn't appear out of thin air.

> CSS nesting is clearly serving the use case of components in web apps, as opposed to mere content-driven web sites.

Even a content-driven web site has a plethora of repeating and/or complex elements that are a pain to define and maintain.

> Would solve 99% of use cases" also sounds like famous last words

Google has poured hundreds of millions of dollars into web components whose primary use case (that is, what they are being used for in reality) could've been solved by scoping and nesting.

Same goes for all the CSS-in-JS abominations.

AFAIK, this is just syntactic sugar. A shortcut.

It’s not scoping in the inheritance sense. The C in CSS is for cascading. Inheriting is the natural way to be for CSS

Casacading !== inheritance. These are very different things. I wish we had inheritance (or traits) in CSS.

Well tell me the difference then. We have cascading inheritance, that’s what CSS is all about.

Unless we’re using different definitions of the term

Casacading alpplies to all elements in the cascade. Whether you want it or not.

At the same time it's impossible to say "hey, I want to inherit from that particular style", and not have the cascade apply to it. For example, I want a button and I don't want anything in the hierarchy above overriding its borders, or colors, or fonts, or...

Oh, I see. Arbitrary non hierarchical opt-in inheritance. Or perhaps a cascading inheritance opt-out, and you could add classes back as you please. That would be cool.

Not sure how it would impact browser parsing and drawing, but it sure would be useful.

I agree it shouldn't be on chrome's website, but nesting in native CSS is a very welcome and needed change, and one of the last things I consistently reach for SCSS for. It's been requested for years.

It does have the ability to be a foot-shotgun, but so do 3/4s of the features in CSS if you don't understand them. And people that want it would probably just do the same thing in SCSS anyways.

> asking the general public ... when we all know it's a one-way ticket ... a rhetoric dictators have been using. Note the absence of the option to "do nothing"

regrettably reminiscent of the Wikimedia Foundation

> That was almost 14 years ago.

Now that's a page that can be dated by its look.

>The distribution is as you might expect, lots of very small files, very few large files:

> - Half the files is less then 7 lines. > - 90% is less than 163 lines. > - Only 0.6% is longer than 500 lines.

This part jumped out at me. Those were the days...

"it hasn't been done before, so it can't be done now". 25 years ago isn't 14 years ago isn't now...

Nobody's saying it can't be done. They're simply questioning whether it should be done, since we have tools that solve this problem already. It's not giving us anything we don't already have, and so the value proposition in making the syntax more complex is pretty shaky.

Why should the tool be necessary? I'd much rather write plain CSS than use Sass, and nesting makes that significantly more readable and easier to maintain.

Whether the tool should or should not be necessary is an entirely different question. The reason it is necessary is because it enabled writing "CSS" in a way that it was never meant to be written. And as evidenced by the blog post and all of the discussion here, adding the functionality to browsers isn't at all straightforward.

So a better question is why shouldn't the tool be necessary? It's all about writing the same CSS in a more developer-friendly way, not enabling CSS to do something it never could before (like variables and flex did). Why should browsers have to worry about this added complexity? Just write your stylesheets however you'd like, and then run a tool to compile them down to standard CSS.

When I look at these proposals, I would still prefer using Sass over regular CSS. It's syntax is just cleaner.

Reply on news.ycombinator.com