Update postcss* to latest releases

Green enough for me!

spokje → changed the visibility of the branch 11.x to hidden.

Mirroring status of parent issue, which became critical.

spokje → changed the visibility of the branch 3487817-11.x-postcss to hidden.

spokje → changed the visibility of the branch 3487817-11.x-postcss to active.

spokje → changed the visibility of the branch 3487817-11.x-postcss to hidden.

spokje → closed merge request !10206

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Needs rebasing, but I'll wait for some of the other sibling issues to land before doing so.
Otherwise we're entering rebase-ception land.

spokje → closed merge request !10239

Were these auto generated?

Were these auto generated?

@smustgrave, I assume you're talking about the PCSS (and thus also the CSS) changes in this MR.
They're not auto-generated, but were manually changed to make this MR pass tests.

It seems I didn't push after the first commit which only bumped postcss and friends, so there's no test-results from that one, but that complained about @nest being deprecated, so I removed that from all PCSS-files and did a $yarn build:css.

That came back with errors (See https://git.drupalcode.org/issue/drupal-3487817/-/pipelines/350377/codeq...), which I manually corrected (and another $yarn build:css) in my third commit, after which all went green.

May want someone with css eyes to take a look

Example

#drupal-off-canvas-wrapper .links li is now is(#drupal-off-canvas-wrapper .links) li and I'm not enough of a frontend guy to know why .links is included in the is() function but not li or vice versa.

Ah, those bits, with the whole is(#yada .yada) were auto generated, I am even less a front end person than you are probably.
I could never come up with stuff like that.

But by all means, let experts look at it.

spokje → closed merge request !10342

Why were the manual changes in commit 63ea0139 needed?

They all we're needed to pass the stylelint job, see https://git.drupalcode.org/issue/drupal-3487817/-/pipelines/359246/codeq...

@spokje, thanks, I missed that.

This needs rebase because 📌 Update all JavaScript dependencies which cause no changes Active just landed.

#drupal-off-canvas-wrapper .links li {
:is(#drupal-off-canvas-wrapper .links) li {

So this looks harmless but I don't understand why it's being applied. MDN says:

The :is() CSS pseudo-class function takes a selector list as its argument, and selects any element that can be selected by one of the selectors in that list. This is useful for writing large selectors in a more compact form.

But #drupal-off-canvas-wrapper .links this is not really a list of selectors as described in those docs.

Is postcss doing this because it doesn't like HTML IDs as CSS selectors? Or is there something else I'm missing.

Was hoping to get this into the 11.1.0 release but instead I think we should hold off until someone properly js competent is able to review it a bit more.

Cross-posted with NickWilde, moving to needs work based on that.

Tracked down that the :is selectors are coming from the postcss-nesting plugin: https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-nesting.

With the update, the default edition for the plugin becomes 2024-02 which is documented with:

usage of :is() pseudo-class is no longer optional

Setting the edition to '2021' does prevent the :is selectors from being added and can be done with this change to core/scripts/css/compile.js:

diff --git a/core/scripts/css/compile.js b/core/scripts/css/compile.js
index 5c9426747e8..3064bbbae38 100644
--- a/core/scripts/css/compile.js
+++ b/core/scripts/css/compile.js
@@ -33,6 +33,7 @@ module.exports = (filePath, callback) => {
           'has-pseudo-class': false,
           'image-set-function': false,
           'prefers-color-scheme-query': false,
+          'nesting-rules': { edition: '2021'},
         }
       }),
       postcssPixelsToRem({

I don't know enough about the CSS nesting standard though to say whether that should be done.

I can see what postcss is trying to do...

In situations where you've nested a list of selectors inside another list of of selectors, and you want to support browsers that aren't compatible with css nesting, but which are compatible with the the ":is()" selector, then ":is()" can be an efficient way to provide something equivalent to the nesting.

For example, this (with nesting):

article,
aside,
section,
div{
  p,
  table,
  img,
  figure{
    width:100%;
  }
}

...is equivalent to this (without nesting, aka pre-2024):

:is(article, aside, section, div) :is(p,table,img,figure){
    width:100%;
}

.... which is far fewer characters than than this (without nesting or the use of :is(), aka pre-2021):

article p,
article table,
article img,
article figure,
aside p,
aside table,
aside img,
aside figure,
section p,
section table,
section img,
section figure,
div p,
div table,
div img,
div figure{
  width:100%;
}

All three are perfectly correct CSS... but from the looks of it, postcss is clearly not smart enough to properly recognise all situations where :is() is not necessary.

If there's no other ways to tweak the processing (e.g. unwrapping any :is() selector which doesn't contain a comma) then you're just choosing between the efficiency of allowing the use of :is() for more complicated nested structures, with the side-effect of it sometimes being used unnecessarily, or going without :is() in appropriate situations in return for potentially longer, but more backwards compatible css, and no superfluous :is() selectors.