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

Discussion: Tailwind modifiers #751

Open
thejackshelton opened this issue May 19, 2024 · 5 comments
Open

Discussion: Tailwind modifiers #751

thejackshelton opened this issue May 19, 2024 · 5 comments

Comments

@thejackshelton
Copy link
Contributor

Kobalte does something interesting. You add a plugin to your tailwind config, and the modifiers are changed:
https://kobalte.dev/docs/core/overview/styling#using-the-tailwindcss-plugin

This makes styling component states much cleaner. Thoughts?

@maiieul
Copy link
Contributor

maiieul commented May 20, 2024

Looking into this right now, I don't think data-[closing]:fade-out data-[open]:fade-in is any worse than ui-closing:fade-out ui-open:fade-in. Maybe it's even better, because not only it means no external plugin to install, but it is also more explicit to what is being done by the headless component.

@maiieul
Copy link
Contributor

maiieul commented May 22, 2024

One "argument" in favor of using data-[state=...]: is that sometimes it could be about something else than an action. For example shadcn and radix have the "side" attribute such as data-[side=bottom]:slide-in-from-top-2 (scroll right to see more):

<SelectPrimitive.Content
      ref={ref}
      className={cn(
        "relative z-50 max-h-96 min-w-[8rem] overflow-hidden rounded-md border bg-popover text-popover-foreground shadow-md data-[state=open]:animate-in data-[state=closed]:animate-out data-[state=closed]:fade-out-0 data-[state=open]:fade-in-0 data-[state=closed]:zoom-out-95 data-[state=open]:zoom-in-95 data-[side=bottom]:slide-in-from-top-2 data-[side=left]:slide-in-from-right-2 data-[side=right]:slide-in-from-left-2 data-[side=top]:slide-in-from-bottom-2",
        position === "popper" &&
          "data-[side=bottom]:translate-y-1 data-[side=left]:-translate-x-1 data-[side=right]:translate-x-1 data-[side=top]:-translate-y-1",
        className
      )}
      position={position}
      {...props}
    >
    ```
    
    but if it's an exception or there are only a few exceptions like that, then it's probably better to combine.

@shairez
Copy link
Contributor

shairez commented May 22, 2024

@maiieul from what I understand - it'll always be data-

the tailwind plugin will just make it easier for TW users to write ui- instead of data-

did I understand it correctly?

@maiieul
Copy link
Contributor

maiieul commented May 23, 2024

Hmmm I'm not sure if the plugin is just an add-on or if it's required. But even if it's just an add-on to avoid the bracket syntax, I'm not sure I prefer ui- to data -[]..

Here's the tailwind docs: https://tailwindcss.com/docs/hover-focus-and-other-states#data-attributes

@shairez
Copy link
Contributor

shairez commented May 23, 2024

I personally prefer the least amount of characters when possible.
The tradeoff is to depend on another plugin and it's less obivous that the mapping is between ui- to data-[]

I'm on the fence
WDYT @thejackshelton ?

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