Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Rule: use-logical #13

Open
1 task done
NateRadebaugh opened this issue Nov 20, 2024 · 2 comments
Open
1 task done

New Rule: use-logical #13

NateRadebaugh opened this issue Nov 20, 2024 · 2 comments
Labels

Comments

@NateRadebaugh
Copy link

NateRadebaugh commented Nov 20, 2024

Rule details

Enforce the usage of Logical Properties and Values in CSS. Physical dimensions and directions are described left to right and top to bottom, while their logical counterparts are described start to end and inline or block.

What type of rule is this?

Warns about a potential problem

Example code

https://github.com/csstools/stylelint-use-logical

For example, to add spacing before the start of a paragraph, we might use the physical padding-left property.

p {
  padding-left: 2em;
}

Were the content Hebrew or Arabic — flowing right to left — then we might use alternating padding-left and padding-right properties.

p:dir(ltr) {
  padding-left: 2em;
}

p:dir(rtl) {
  padding-right: 2em;
}

Selector weight aside, we can instead use the logical padding-inline-start property.

p {
  padding-inline-start: 2em;
}

Participation

  • I am willing to submit a pull request to implement this rule.

Additional comments

I'm not sure the quirks of the new css parser and context, but my current stylelint configuration for angular projects includes:

{
  "extends": "stylelint-config-standard-scss",
  "plugins": ["stylelint-use-logical"],
  "overrides": [
    {
      "files": ["*.html", "**/*.html"],
      "customSyntax": "postcss-html"
    },
    {
      "files": ["**/*.component.ts"],
      "customSyntax": "postcss-angular"
    }
  ],
  "rules": {
    "csstools/use-logical": [
      "always",
      {
        "except": [
          "min-width",
          "max-width",
          "width",
          "min-height",
          "height",
          "max-height",
          "top",
          "bottom",
          "margin-top",
          "margin-bottom",
          "padding-top",
          "padding-bottom",
          "border-top",
          "border-bottom",
          "border-top-color",
          "border-bottom-color"
        ]
      }
    ]
  }
}
@nzakas nzakas added this to Triage Nov 20, 2024
@nzakas nzakas moved this to Triaging in Triage Nov 20, 2024
@nzakas
Copy link
Member

nzakas commented Nov 20, 2024

This sounds like a good idea. To follow ESLint naming conventions, I'd call this prefer-logical-properties.

We'd need to workshop the behavior a bit.

It looks like the Stylelint plugin automatically flags every property that has a logical equivalent and then allows you to opt-out using except? If so, it looks like you're excluding a lot of properties, and I wonder if there isn't some better default behavior?

Does it assume LTR so padding-left is always flagged to be padding-inset-start? Or is there some detection of LTR vs RTL?

@jeddy3
Copy link

jeddy3 commented Nov 20, 2024

There's an alternative Stylelint plugin called stylelint-plugin-logical-css that lists a fuller set of logical properties, values and units in its README.

For example:

h1 { 
  font-size: 8vi;
  margin-block: 2vb;
  text-align: start;
}

These properties, values and units have inconsistent support across browsers. For example, padding-inline is supported, whereas overflow-inline from the overflow spec has very little support. Perhaps a better default is Baseline's widely available? It's a shifting target, though.

It may also be helpful to people if the rule flags physical four-directional shorthand properties like margin, padding, and border-width, as there is currently no logical equivalent for these shorthands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Triaging
Development

No branches or pull requests

3 participants