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

Reducing the gap between standard Tailwind and the Scale preset #227

Open
jwueller opened this issue Sep 4, 2023 · 3 comments
Open

Reducing the gap between standard Tailwind and the Scale preset #227

jwueller opened this issue Sep 4, 2023 · 3 comments

Comments

@jwueller
Copy link

jwueller commented Sep 4, 2023

I would like to discuss/propose some flattening of the hierarchy for the Tailwind preset, as it is currently quite verbose compared to the default configuration. Tailwind already flattens the regular CSS property hierarchy a lot by removing unambiguous prefixes where possible, often leading to even less typing than the standard property names would have required. This is a continuation of that idea.

Some examples of changes I would personally prefer:

  • text-text-&-icon-disabledtext-disabled
    Rationale: Most icons already inherit text colors, so namaing them separately is probably unnecessary.
  • bg-functional-informational/text-functional-informationalbg-informational/text-informational or maybe even just bg-info/text-info
    Rationale: Nested properties are unambiguous.
  • bg-additional-violet-500bg-violet-500
    Rationale: Color names are unambiguous.
  • (and many others)

Since none of these prefixes actually prevent any naming collisions, it would likely improve readability and reduce friction for developers already familiar with standard Tailwind, thereby easing a codebase transition to the Scale preset.

I'm happy to contribute a PR with my proposed changes where specific details may be more appropriate to discuss, but I would like to get a feel for the general consensus on such a change before I start working on it.

@mato-a
Copy link
Contributor

mato-a commented Sep 8, 2023

I am generally in favor of this idea 👍

@jwueller
Copy link
Author

Should I proceed with setting up a PR, or does this need additional sign-offs?

@acstll
Copy link
Collaborator

acstll commented Dec 1, 2023

@jwueller no additional sign-off are needed — I also think this is a great idea. @maomaoZH what do you think?

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

No branches or pull requests

3 participants