mirror of
https://github.com/arikchakma/maily.to.git
synced 2026-04-25 22:25:51 +03:00
[GH-ISSUE #27] Shipping global styles cause conflicts #13
Labels
No labels
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/maily.to#13
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @BigDog1400 on GitHub (Jan 5, 2024).
Original GitHub issue: https://github.com/arikchakma/maily.to/issues/27
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/coreinto 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 on GitHub (Jan 5, 2024):
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 on GitHub (Jan 5, 2024):
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 on GitHub (Jan 5, 2024):
Okay, I got it. Would you mind creating the PR from that? And instead of the class name
preflight, maybemlyis fine. What do you think?@BigDog1400 commented on GitHub (Jan 5, 2024):
Sure. Give me a couple hours . I will like to test it locally to validate that everything if fine
@arikchakma commented on GitHub (Jan 5, 2024):
Sounds good, let me know if you need any help.
@BigDog1400 commented on GitHub (Jan 6, 2024):
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 on GitHub (Jan 6, 2024):
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.