Problem/Motivation

Our PostCSS results in strangely indented CSS.

See core/themes/olivero/css/layout/views.css for example:

 .view > * {
    margin-block-end: var(--sp2);
  }
<code>
Should be
<code>
 .view > * {
  margin-block-end: var(--sp2);
}

Proposed resolution

Run stylelint fixer as part of our build on the resulting postcss code.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Issue fork drupal-3314523

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

alexpott created an issue. See original summary.

alexpott’s picture

Status: Active » Needs review
alexpott’s picture

We could remove the core/.stylelintignore but unfortunately the resulting CSS still doesn't pass our rules...

yarn run lint:css 
yarn run v1.22.19
$ stylelint "**/*.css"

themes/olivero/css/components/autocomplete-loading.module.css
 71:1  ✖  Unexpected unknown type selector "_"  selector-type-no-unknown
 78:1  ✖  Unexpected unknown type selector "_"  selector-type-no-unknown

themes/olivero/css/components/fieldset.css
 51:1  ✖  Unexpected unknown type selector "_"  selector-type-no-unknown

3 problems (3 errors, 0 warnings)

This is because the resulting CSS is like this:

/* stylelint-disable-next-line selector-type-no-unknown */

_:-ms-fullscreen,
html[dir=ltr].js .form-autocomplete.ui-autocomplete-loading {
  background: var(--autocomplete-throbber-IE-icon-url) no-repeat right var(--autocomplete-icon-right-offset) center / var(--autocomplete-throbber-IE-size);
}

The new line between the disable rule and the _:-ms-fullscreen, is the problem. I think this is coming from the postcss processing.

mherchel’s picture

Status: Needs review » Reviewed & tested by the community

FWIW, those rulesets will be removed shortly.

Anyway, this looks great! In fact, its so great that I discovered a bug while spot checking the resulting CSS (see #3314574: Invalid PostCSS causes invalid CSS within new off-canvas CSS).

Thanks!

lauriii’s picture

Committing this to 10.1.x would potentially make it slightly harder to backport CSS changes from 10.1.x. to 10.0.0. However, I'm wondering if we have to be concerned about backporting issues with CSS from 10.1.x to 10.0.x at this point? It seems like something we would have been worried about few months ago but I guess now most CSS changing issues would only go to 10.1.x. Thoughts?

alexpott’s picture

Version: 10.1.x-dev » 9.5.x-dev

This is a whitespace change to generated CSS files I think this is fine to backport to 10.0.x - I also think we can backport this to 9.5.x too - obvs it will need a reroll for that branch :)

alexpott’s picture

I created a MR for 9.5.x too

  • lauriii committed b544664 on 10.1.x
    Issue #3314523 by alexpott: PostCSS results in CSS that does not comply...

  • lauriii committed 82789fe on 10.0.x
    Issue #3314523 by alexpott: PostCSS results in CSS that does not comply...

  • lauriii committed c1a8f29 on 9.5.x
    Issue #3314523 by alexpott: PostCSS results in CSS that does not comply...

lauriii’s picture

Status: Reviewed & tested by the community » Fixed

Committed MR #2849 b544664 and pushed to 10.1.x and cherry-picked to 10.0.x.
Committed MR #2855 c1a8f29 and pushed to 9.5.x. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.