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

[Tailwind CSS] Enable color exact values for standard tailwind colors via tailwind css config export. #102

Open
nicolas-cherel opened this issue Jun 10, 2024 · 10 comments

Comments

@nicolas-cherel
Copy link

nicolas-cherel commented Jun 10, 2024

Hi, I very much like your plugin, but while finishing my last pass of usability evaluation I've hard time to figure out how to make sure that the tailwind class for colors would match colors from our design.

Seems that I stumble on a blocker: tailwind classes seems to go through a nearest value of the actual ones on the design. I've seen some alternative to that, such as tailwinds bracket colors for non standard colors, but this is too not a viable solution.

It looks like that the right solution would be a 2 stepped one: somehow, exporting a tailwind configuration for the project colors with their name, and then having FigmaToCode use those names in the tailwind class names.

There are questions left opened with such an approach, such as how to handle colors names collisions, especially for figmas designs that are use in a single tailwind project.

I'dont event know if it's feasible with figma plugin, but it looks to me that any figma tailwind code generator will have to tackle this to achieve a really valuable output

@bernaferrari
Copy link
Owner

bernaferrari commented Jun 10, 2024 via email

@nicolas-cherel
Copy link
Author

nicolas-cherel commented Jun 10, 2024

Well I don't know the extent of tailwind colors configuration complexity, but if I could import colors in a format compatible with tailwind colors configuration it would certainly to, as some figma plugins claims to be able to export that. Importing a complete tailwind.config.js would bring quite a bunch of problems I suspect though, I'm not sure I'd be confortable with the idea.

@nicolas-cherel
Copy link
Author

nicolas-cherel commented Jun 10, 2024

After reflection maybe we could try to skip the config import add do a mix & match of using colors alias of the boundVariables and fallback to bracket syntax ([color:#994455]) for unknown colors.

That way unnamed colors cannot be exported properly by any ways, and FigmaToCode doesn't have to deal with probable configurations mismatches.

Does it looks sound to you ?

@bernaferrari
Copy link
Owner

so if you have a color variable, and it doesn't match 100% a pre-defined color, I use bg-[#ff1122]. Well, I could just put in the "round to tailwind values" that any color not matching will show the raw value, don't even need to restrict to color variables. I could also add a new property "round to tailwind colors".

@nicolas-cherel
Copy link
Author

It looks like I greedily would like two feature, the one you describe "round to tailwind colors" to be able to disable it, and another "colors alias", that would use aliases when one is available. But I see how it can be a bit of work after reading the code.

@bernaferrari
Copy link
Owner

how would color alias work? Because most people wouldn't have a corresponding name in Figma, I guess.

@nicolas-cherel
Copy link
Author

Yes exactly, to be of use, this alias feature requires to add the colors to tailwind, either manually or exported from figma, eg by using such a plugin

@bernaferrari
Copy link
Owner

bernaferrari commented Jun 10, 2024 via email

@nicolas-cherel
Copy link
Author

If I made only the "disable color rounding" would you be happy already? 🥺

Yes I think it would be a good feature to have.

I tried to experiment with naming and colors variables things got hectic pretty quickly, I think I'll comme back to you with proposal and code.

@davestewart
Copy link
Contributor

davestewart commented Jun 27, 2024

Another option here might be to import the TW file and convert all values to library variables, then in future the user could update the variables rather than the plugin having to manually manage configuration.

In fact, this plugin looks to already exist:

Could use that, then export token names as-is.

See other issue linked above.

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