Enforce the use of CSS Logical Properties in core

The issue linked in #7 was closed by stylelint-use-logical-spec v5.0.0, so hopefully it's time to revisit this.

Hiding patches.

I postponed 📌 Clean up locale CSS in line with our CSS standards Postponed on this issue.

@Gauravvvv, why did you make a second MR?

I rebased MR 7761. The I ran the automated fixes. There are now 2 failing tests.

core/profiles/demo_umami/tests/src/FunctionalJavascript/OpenTelemetryFrontPagePerformanceTest.php
core/profiles/demo_umami/tests/src/FunctionalJavascript/AssetAggregationAcrossPagesTest.php

It's nice to have a rule and automated fix for this one.

MR needs quite a bit of work (only did 1/3 of the changed files). Essentially we need to make sure that any [dir="rtl"] rule is still needed and remove all the associated /* LTR */ comments in the CSS.

The manual cleanup is needed because if you have

.myclass {
  padding-left: 10px;
}
[dir="rtl"] .myclass {
  padding-left: 0;
  padding-right: 10px;
}

seems the config of the lint check is broken

It's easier to revert the last commit, fix the config and rerun the linter

@nod_, thanks for the review!

While I don't know CSS very well I accepted the suggestions because they made sense to me. I then tried just a few to see if I truly understand. I look forward to feedback on those few changes.

Still more work to do here.

alexpott → changed the visibility of the branch 3312966-enforce-css-logical-properties to hidden.

Thanks, the fix you tried are accurate. One thing is that the last autofix changed all the values for float/border but they are supposed to be excluded from the config. So either we change the config to remove all exceptions, or we change the code to follow the exceptions (ie. revert the last autofix commit).

@nod_, I think the choice is yours to make. Which do you prefer?

I pinged folks on slack to get some more views on this. I think I'd rather go all-in we used to have a problem with postcss and the float logical values, it might be fixed by now.

Shall we break this into smaller child issues? What is a good way to do that for this type of change?

breaking it down would be first automatic transform of all the css files that do not have a [dir=] rule, since automated replacement is safe.

Then it's a little bit of case by case. Might need to see what's left to know how to split things up.

I think the comment

/**
* Chromium and Webkit do not yet support flow relative logical properties,
* such as float: inline-end. However, PostCSS Logical does not compile this
* value, so we accommodate by not using these.
*
* @see https://caniuse.com/mdn-css_properties_clear_flow_relative_values
* @see https://github.com/csstools/postcss-plugins/issues/632
*/

added as part of the ticket https://www.drupal.org/project/drupal/issues/3313146 🐛 PostCSS Logical not transpiling flow relative properties (e.g. float: inline-start) which are not supported by Chrome and Safari Fixed is no longer required since the issue (https://github.com/csstools/postcss-plugins/issues/632) mentioned in that comment is already closed.

@nayana_mvr, Can you explain how you found the 'missing ,css files' ?

There was a pipeline error as shown below,

It says .pcss.css file from line no. 273 is not updated. This happens when .css (compiled) file corresponding to .pcss.css file is not updated with the changes. I have faced similar issue before. That’s why I tried the command yarn run build:css in core folder and found that the .css files corresponding to the .pcss.css files shown in the error are not pushed to the branch.