5 ms·

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 rhetor

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 https://www.w3.org/People/Bos/CSS-variables

aasasd 4y ago
> That was almost 14 years ago. Now that's a page that can be dated by its look.
- noSyncCloud 4y ago
  >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...
tambourine_man 4y ago
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.
- account42 4y ago
  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.
  - dmitriid 4y ago
    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".
    - tannhaeuser 4y ago
      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 ;)
      - dmitriid 4y ago
        > 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.
    - 4y ago
geraldyo 4y ago
"it hasn't been done before, so it can't be done now". 25 years ago isn't 14 years ago isn't now...
- jaywalk 4y ago
  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.
  - jakelazaroff 4y ago
    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.
    - jaywalk 4y ago
      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.
    - FinalBriefing 4y ago
      When I look at these proposals, I would still prefer using Sass over regular CSS. It's syntax is just cleaner.
mgdlbp 4y ago
> 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
LocalPCGuy 4y ago
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.

aasasd 4y ago

> That was almost 14 years ago. Now that's a page that can be dated by its look.

noSyncCloud 4y ago
>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...

tambourine_man 4y ago

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.

account42 4y ago
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.
- dmitriid 4y ago
  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".
  - tannhaeuser 4y ago
    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 ;)
    - dmitriid 4y ago
      > 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.
  - 4y ago

geraldyo 4y ago

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

jaywalk 4y ago
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.
- jakelazaroff 4y ago
  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.
  - jaywalk 4y ago
    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.
  - FinalBriefing 4y ago
    When I look at these proposals, I would still prefer using Sass over regular CSS. It's syntax is just cleaner.

mgdlbp 4y ago

> 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

LocalPCGuy 4y ago

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.