Fixed a bug that corrupted the original webpage style

[sweep-ai[bot]]

Apply Sweep Rules to your PR?

• [ ] Apply: All new business logic should have corresponding unit tests.
• [ ] Apply: Refactor large functions to be more modular.
• [ ] Apply: Add docstrings to all functions and file headers.

[mubaidr]

Thanks, but i was wondering if there is any implications to user/ developer by using these prefixes?

[Blushyes]

Thanks, but i was wondering if there is any implications to user/ developer by using these prefixes?

When users are writing content scripts, Tailwind class names must include a prefix, such as "tw-flex." However, when developing in other environments, such as the popup, writing normal class names like "flex" is sufficient.

[Blushyes]

Thanks, but i was wondering if there is any implications to user/ developer by using these prefixes?

How's it going? Without a prefix, if the current web page being viewed does not use Tailwind but it contains some elements whose class names are the same as Tailwind's, this will lead to the plugin's Tailwind styles interfering with the current web page's styles, causing a mess in layout and appearance. For example, DaisyUI's btn, some websites might name their custom button styles btn too, but they do not use DaisyUI (of course, for DaisyUI itself, it has its own prefix configuration). After my testing, I discovered that some websites have custom flex and grid classes, which are not the same flex and grid from Tailwind, but the browser will apply the plugin's styles.

[mubaidr]

Thanks, but i was wondering if there is any implications to user/ developer by using these prefixes?

When users are writing content scripts, Tailwind class names must include a prefix, such as "tw-flex." However, when developing in other environments, such as the popup, writing normal class names like "flex" is sufficient.

First of all, thanks for the pull request and all that great info! Really appreciated!

But i am little worried that developer may have auto-complete broken for tailwind classes. (does it break though? )

[mubaidr]

Thanks, but i was wondering if there is any implications to user/ developer by using these prefixes?

How's it going? Without a prefix, if the current web page being viewed does not use Tailwind but it contains some elements whose class names are the same as Tailwind's, this will lead to the plugin's Tailwind styles interfering with the current web page's styles, causing a mess in layout and appearance. For example, DaisyUI's btn, some websites might name their custom button styles btn too, but they do not use DaisyUI (of course, for DaisyUI itself, it has its own prefix configuration). After my testing, I discovered that some websites have custom flex and grid classes, which are not the same flex and grid from Tailwind, but the browser will apply the plugin's styles.

I think this would be other way around case? Websites styles will affect content script pages not the other way around.

For example, if webpage has custom theme, styles or even custom flex/ gird defined, these will override content-script html.

Correct me if i am wrong, content-script cannot effect webpage styles as tailwind css is pre-compiled and our (content script styling, plugins, variables) does not get applied to webpage.

I believe there should be a way to limit, or force styling for our content script html. Which I think can be achieved using iframe for content script pages, but that limits/ effects the messaging system between content script and backgorund js (one has to go iframe -> content-script -> background) 😟

[Blushyes]

Thanks, but i was wondering if there is any implications to user/ developer by using these prefixes?

When users are writing content scripts, Tailwind class names must include a prefix, such as "tw-flex." However, when developing in other environments, such as the popup, writing normal class names like "flex" is sufficient.

First of all, thanks for the pull request and all that great info! Really appreciated!

But i am little worried that developer may have auto-complete broken for tailwind classes. (does it break though? )

Oh, I see. After my tests, it doesn't break autocompletion. When you write Vue components under the content-script folder, the class name autocompletion will include the prefix. However, when you are in places other than content-script, there is no impact.

[Blushyes]

Thanks, but i was wondering if there is any implications to user/ developer by using these prefixes?

How's it going? Without a prefix, if the current web page being viewed does not use Tailwind but it contains some elements whose class names are the same as Tailwind's, this will lead to the plugin's Tailwind styles interfering with the current web page's styles, causing a mess in layout and appearance. For example, DaisyUI's btn, some websites might name their custom button styles btn too, but they do not use DaisyUI (of course, for DaisyUI itself, it has its own prefix configuration). After my testing, I discovered that some websites have custom flex and grid classes, which are not the same flex and grid from Tailwind, but the browser will apply the plugin's styles.

I think this would be other way around case? Websites styles will affect content script pages not the other way around.

For example, if webpage has custom theme, styles or even custom flex/ gird defined, these will override content-script html.

Correct me if i am wrong, content-script cannot effect webpage styles as tailwind css is pre-compiled and our (content script styling, plugins, variables) does not get applied to webpage.

I believe there should be a way to limit, or force styling for our content script html. Which I think can be achieved using iframe for content script pages, but that limits/ effects the messaging system between content script and backgorund js (one has to go iframe -> content-script -> background) 😟

You can imagine that if there is a web page whose class name flex is like this (maybe he jsut want to add a flexible color):

.flex {
  color: whilte;
}

But because of our plugin who used Tailwind CSS, it will has flex:

.flex {
  display: flex;
}

So it finally like:

.flex {
  display: flex;
  color: white;
}

And then all its child elements are forcibly arranged.

[mubaidr]

Yes, you are right. If only tailwind css could inline the styles, this issue would not arise.

While your solution is perfect 🥇 I see we may have other option, I would like to discuss with you:

• We use important selector to content-script root selector (we already have crx-iframe but we can make it more unique, or even dynamically generate to avoid any conflict between multiple extensions). More details here: https://tailwindcss.com/docs/configuration#selector-strategy
• Disable preflight for content-script. Is this an optional step?

This means we can just use normal naming for tailwind utilities, no prefixes required.

What do you think?