Pass all Umami CSS files through CSScomb to Ensure they Follow our CSS Coding Standards

Adding patch.

The changes in this patch don't all follow our CSS Coding formatting settings from here:
https://www.drupal.org/docs/develop/standards/css/css-formatting-guideli...

For example, that says "Add the pixel value in a comment directly after the the opening brace."
like so:
@media screen and (min-width: 28.125rem) { /* 450px */

But the .csscomb will render it like this:

@media screen and (min-width: 28.125rem) {
/* 450px */

I used the .csscomb settings from here: https://www.drupal.org/docs/develop/standards/css/csscomb-settings-for-d...

I'm not sure the issue is fixable, because single line comments are supposed to be on a line of their own, so we have a conflict here
https://www.drupal.org/docs/develop/standards/css/css-formatting-guideli...

Either we can't run the .csscomb or we update our coding standards.

I think this patch should be committed, as it fixes almost all coding standards issues, and the small few items it brings up (such as those in this comment) are much smaller issues than what it fixes.

Now that we have #2983568: Audit and improve focus styles across the Umami theme for logged out users patch committed, I've run every CSS file in the demo_umami profile through the csscomb using the settings from the Drupal Coding Standards csscomb settings.

There are no new code changes in this patch. It _only_ formats the CSS according to the coding standards from CSS comb. (One code block is added at the top of one file, from which it was missing.)

Once this is commited to Umami, we can then enforce it for all new CSS patches that are created.

The above patch has failures according to `yarn run lint:css` so this patch fixes these. I think we (as in, Drupal) might have some discrepancies between our CSS coding standards vs csscomb file vs css lint rules that we might need to figure out.

Thanks @Eli-T for that review. The csscomb says to use double quotes, so I have no idea why it rewrote them to single quotes.

It's also a bit strange that yarn run lint:css didn't catch them as issues.

I'm attaching another patch with all those set to double quotes.

HI Alex,

When I run yarn run lint:css I get no failures with the patch above.

However it does not give any errors for the ordering of CSS properties. The linter seems to accept this:

.view-mode-card {
   color: #000;
   display: flex;
   flex-direction: column;
   width: 100%;
   padding: 1rem;
}

and this:

.view-mode-card {
   display: flex;
   flex-direction: column;
   width: 100%;
   padding: 1rem;
   color: #000;
}

Though the bottom one is the one that should be correct.

So, I _think_ our CSS as per this patch is correct and following the guidelines (certainly better than it had been). If not, should we continue to stop working on other issues while we fix this, or should we abandon this and continue to work on other issues and fix up the CSS files as we touch them within other issues?

Maybe I'm missing something here, but I'm rather confused.

It seems to me that we have a patch for the demo_umami section of Drupal core that makes our code much cleaner and - as far as I can tell - follows Drupal's coding standards, but we are not going to commit it? Further, the patch was reviewed by another core maintainer (@Eli-T) who seems happy to mark it as RTBC, but we are not going to commit it?

I can appreciate that maybe the stylelintrc needs more work and that other sections of Drupal core may need their CSS fixed, but surely it's a positive thing for us to at least start with this one section - demo_umami - in good shape, and we can further amend it if we need to as the stylelintrc gets amended. It could also be the benchmark by which other sections/themes are gauged against when we get around to them.

I also think we need to look at marking the coding standards page - or at least the csscomb section of it - as obsolete if it is not to be followed any longer.

Should we abandon csscomb because so little of Drupal's CSS complies with its rules or should we commit the code that does comply with its rules, so we have one part of Drupal up-to-scratch?

I'm genuinely confused at why we are refusing to commit a patch that aims to follow Drupal's coding standards. We realised that demo_umami doesn't follow all the CSS coding standards, so we fixed that.

Is there a larger issue somewhere that I can help out with to fix all of Drupal's CSS in one go? Or to fix the stylelintrc file? Or will we fix all the other parts, like you say "step by step"? If step-by-step, is what we have here not a "step"? I'd expect that we should be able to fix all other files one file at a time and commit each as they are fixed. Here we're just attempting to do that with one full section, rather than one file at a time.

I'm postponing this issue in favour of @alexpott's idea that all coding standards fixes should be automatable so they don't re-occur.

We can mark this as fixed/closed when we get to that stage.