12 ms·

So now we discuss web standards on chrome.com ? This looks like the beginning of the end of a free web governed standards established by an independent body. I

So now we discuss web standards on chrome.com ? This looks like the beginning of the end of a free web governed standards established by an independent body. I would have expected such an article to be published on w3.org...

mattgperry 4y ago
Why didn't they publish one then?
oefrha 4y ago
Any person can publish a blog post discussing web standards on the “free web”. You’re welcome to publish one yourself.
- echelon 4y ago
  Too many Google engineers working on this to keep up.
tannhaeuser 4y ago
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 ;)
- 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.
rachelandrew 4y ago
Things don't get a lot of eyeballs on them on w3.org which defeats the object of the post which is to get developer feedback. It's pretty normal for CSSWG members to ask for opinions via tweets, on their own blogs, or in other places. I've posted stuff to my personal blog in the past. This is something that will be worked on in the CSS Working Group, it happens to have people from Chrome working on it, however it will be discussed with the rest of the CSSWG who have a range of affiliations: https://www.w3.org/Style/CSS/members.en.php3 https://www.w3.org/Style/CSS/members.en.php3
- lovasoa 4y ago
  The request for feedback could have been discussed at w3, and google could still have made a blog post about it saying something like "this is what we have been discussing at w3 so far, your feedback is welcome on w3.org"... The post is on chrome.com and mentions the decision makers as "we".
- clairity 4y ago
  nesting will be nice when it lands, but i'm most excited by far for :has() support. i know chrome and safari have initial implementations in place and firefox just recently started. :has() will be the biggest advancement in css since grid, moreso than nesting or container queries, because of the power it puts in the stylists' hands. unfortunately trying to track its progress is a haphazard gander into an opaque maze of different sites and bug trackers.
aasasd 4y ago
Afaik browser devs are dictating the standard for many years already. Also, the post ackshually refers to a W3C draft at https://www.w3.org/TR/css-nesting-1/ https://www.w3.org/TR/css-nesting-1/
apatheticonion 4y ago
I too am salty about this, but the W3C uses IRC for discussions and have no easy forum or boards for RFCs (like TC39 with their use of GitHub for ECMAScript proposals). Contributing to web standards is not really accessible and that contributes to this Chromium-centric world.
- rachelandrew 4y ago
  The CSS Working Group uses GitHub primarily, and any minutes from IRC are added to the issue. Here: https://github.com/w3c/csswg-drafts/issues https://github.com/w3c/csswg-drafts/issues You are very welcome to contribute!
- seba_dos1 4y ago
  What kind of chat would be more accessible than IRC?
  - frosted-flakes 4y ago
    What kind of chat wouldn't be more accessible than IRC?
- greggman3 4y ago
  > Contributing to web standards is not really accessible How so? AFAICT if you want to contribute just go contribute. It's open to all. Discussions are had on public mailing lists, github, etc... Here's one place to start https://github.com/w3c https://github.com/w3c
  - apatheticonion 4y ago
    Where would one raise a proposal for something like adding a `sandbox` flag to `<script>` elements, the proposal of adding a feature like a "Context Menu API" for PWAs or discussions around pro-privacy features?
the42thdoctor 4y ago
Hey, I am just happy that survey is not on Google Forms requiring a G account.
dmitriid 4y ago
> This looks like the beginning of the end of a free web governed standards established by an independent body. The end sailed us by a few years ago. Chrome now dominates all standards bodies and pushes quite a few of its proposals forwards with utter disregard for anyone.

mattgperry 4y ago

Why didn't they publish one then?

oefrha 4y ago

Any person can publish a blog post discussing web standards on the “free web”. You’re welcome to publish one yourself.

echelon 4y ago
Too many Google engineers working on this to keep up.

tannhaeuser 4y ago

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

rachelandrew 4y ago

Things don't get a lot of eyeballs on them on w3.org which defeats the object of the post which is to get developer feedback. It's pretty normal for CSSWG members to ask for opinions via tweets, on their own blogs, or in other places. I've posted stuff to my personal blog in the past. This is something that will be worked on in the CSS Working Group, it happens to have people from Chrome working on it, however it will be discussed with the rest of the CSSWG who have a range of affiliations: https://www.w3.org/Style/CSS/members.en.php3 https://www.w3.org/Style/CSS/members.en.php3

lovasoa 4y ago
The request for feedback could have been discussed at w3, and google could still have made a blog post about it saying something like "this is what we have been discussing at w3 so far, your feedback is welcome on w3.org"... The post is on chrome.com and mentions the decision makers as "we".
clairity 4y ago
nesting will be nice when it lands, but i'm most excited by far for :has() support. i know chrome and safari have initial implementations in place and firefox just recently started. :has() will be the biggest advancement in css since grid, moreso than nesting or container queries, because of the power it puts in the stylists' hands. unfortunately trying to track its progress is a haphazard gander into an opaque maze of different sites and bug trackers.

aasasd 4y ago

Afaik browser devs are dictating the standard for many years already. Also, the post ackshually refers to a W3C draft at https://www.w3.org/TR/css-nesting-1/ https://www.w3.org/TR/css-nesting-1/

apatheticonion 4y ago

I too am salty about this, but the W3C uses IRC for discussions and have no easy forum or boards for RFCs (like TC39 with their use of GitHub for ECMAScript proposals). Contributing to web standards is not really accessible and that contributes to this Chromium-centric world.

rachelandrew 4y ago
The CSS Working Group uses GitHub primarily, and any minutes from IRC are added to the issue. Here: https://github.com/w3c/csswg-drafts/issues https://github.com/w3c/csswg-drafts/issues You are very welcome to contribute!
seba_dos1 4y ago
What kind of chat would be more accessible than IRC?
- frosted-flakes 4y ago
  What kind of chat wouldn't be more accessible than IRC?
greggman3 4y ago
> Contributing to web standards is not really accessible How so? AFAICT if you want to contribute just go contribute. It's open to all. Discussions are had on public mailing lists, github, etc... Here's one place to start https://github.com/w3c https://github.com/w3c
- apatheticonion 4y ago
  Where would one raise a proposal for something like adding a `sandbox` flag to `<script>` elements, the proposal of adding a feature like a "Context Menu API" for PWAs or discussions around pro-privacy features?

the42thdoctor 4y ago

Hey, I am just happy that survey is not on Google Forms requiring a G account.

dmitriid 4y ago

> This looks like the beginning of the end of a free web governed standards established by an independent body. The end sailed us by a few years ago. Chrome now dominates all standards bodies and pushes quite a few of its proposals forwards with utter disregard for anyone.