search

arikchakma / maily.to

Craft beautiful emails effortlessly with Maily, the powerful email editor that ensures impeccable communication across all major clients.
https://maily.to
MIT License
1.44k stars 74 forks source link

Shipping global styles cause conflicts #27

Closed BigDog1400 closed 8 months ago

BigDog1400 commented 8 months ago

Hello!

First of all, I'd like to extend my gratitude for the tremendous effort put into developing this package—it's truly impressive.

Currently, at my job, we've started integrating @maily-to/core into our application as a dependency to incorporate an email editor with a robust UI. However, I've noticed an issue: the package bundles global preflight reset styles, which are causing conflicts with other elements in our app. I suspect that this may also pose a problem for any other application that attempts to use this package.

I'm not entirely certain about the long-term objectives of this project—whether it's intended solely as a playground or as a package meant for broader usage—but if it's the latter, the global preflight is a significant hindrance. It appears that Tailwind CSS is being used to style the components, so perhaps a solution could be to implement more inline styles, thus mitigating the need for global preflight styles.

I'm very interested in your thoughts on this matter and would like to know if there's a way I could contribute to resolving this issue. My preference is to collaborate directly on the core package, rather than creating a fork for our specific use at work.

arikchakma commented 8 months ago

Hey,

I'm aware of this issue.

I decided to take this approach due to the issue discussed in #5969. Currently, I'm loading the styles onMount. To resolve this issue, we could expose the styles using @maily-to/core/styles.css. Though we are also using this package in our other applications, we haven't faced any issues.

What do you suggest?

BigDog1400 commented 8 months ago

Delivering a file with the CSS output would likely result in the same issue as it would still apply globally.

I guess that your project is using tailwind so, it would not clash with the preflight since it is almost the same rules, in my case, we have a boostrap theme :/

I don't want to suggest changing tailwind for something else, so after doing some research, i found this article on scoping normalized preflight CSS: https://dev.to/ajscommunications/scoping-normalized-preflight-css-c29. It suggests scoping the preflight to specific elements where a parent has a particular classname. I've tested this approach here: https://github.com/BigDog1400/maily.to/tree/feat/scope-preflight-styles. After running pnpm run, I copied the index.mjs to my project and it seems to work. I wasn't able to fully test it locally due to time constraints, but I anticipate everything should continue to function as expected.

arikchakma commented 8 months ago

Okay, I got it. Would you mind creating the PR from that? And instead of the class name preflight, maybe mly is fine. What do you think?

BigDog1400 commented 8 months ago

Sure. Give me a couple hours . I will like to test it locally to validate that everything if fine

arikchakma commented 8 months ago

Sounds good, let me know if you need any help.

BigDog1400 commented 8 months ago

There is the PR. Today i checked other approaches in others packages, and i think that maybe the best thing will be to ship a .css file with all the styles and use a class name like .mly-toolbar, .mly-button...etc in the components. So the user can import the default styles from the library, change the .mly-button if they wish or just write up the styles from scratch.

Right now it's not easy to change specific styles

arikchakma commented 8 months ago

We can specify these for the bubble menu, and toolbar. Unfortunately, we can't customize the main email components yet because of the compiler. We also have to modify that one. I do have plans for this feature later on. Currently, I'm focusing on building more components.