Spike: Validate compatibility of Tailwind-based editor

[lornakelly]

Description

Investigate the compatibility of a Tailwind-based editor component when embedded within applications.

Motivation

Ensure the editor can be reliably embedded in host applications without unintended styling conflicts

Proposed Implementation

No response

Definition of Done

• Implementation: Fully implemented according to the Serverless Workflow spec.
• Unit Tests: Comprehensive unit tests are included and passing.
• Integration Tests: Verified within the monorepo and target environments (Web/VS Code).
• Documentation: Updated README.md, ADRs, or official docs.
• Performance: No significant regression in editor responsiveness.
• Accessibility: UI changes comply with accessibility standards.

[fantonangeli]

@lornakelly @handreyrc @kumaradityaraj @ricardo
cc @JBBianchi
I created an experiment on a monorepo with:

• packages/tailwind-child: A Tailwind component built as a library on Vite
• packages/patternfly-parent: A PatternFly Webapp importing tailwind-child in the page, without using iframes, just as a normal React component

Repository: https://github.com/fantonangeli/tailwind-patternfly-spike
GH page preview:

• patternfly-parent: https://fantonangeli.github.io/tailwind-patternfly-spike/patternfly-parent
• tailwind-parent: https://fantonangeli.github.io/tailwind-patternfly-spike/tailwind-parent

This experiment monorepo is structured to allow us to do more experiments, if needed, in the future.

In the screenshot below you the red box is the Tailwind component and everything outside is PatternFly:

Because this is not a PR, I ask you to comment with a "LGTM" after you review, so we can close this issue.

[JBBianchi]

Thanks a lot for putting together the spike @fantonangeli, this is really helpful to have a concrete experiment to look at 🙌

I think it would help to slightly clarify what we want to prove with this issue, because there are two related but different concerns mixed together:

1. “Can a Tailwind-based component render inside another app?”
2. “Can the editor be embedded without unintended styling interactions (in either direction)?”

From what I see in the spike, we’re successfully demonstrating (1): the Tailwind child can be imported into a PatternFly app and renders fine in that setup.

However, I’m not sure we’re fully addressing (2) yet.

In the current approach, the child’s CSS is imported into the parent app and merged into the same global stylesheet/cascade. So Tailwind and PatternFly are effectively just coexisting in the same document, without any real isolation mechanism. That means we don’t yet have guarantees that:

• the child won’t affect the host
• the host won’t affect the child
• the result won’t depend on import order or specific framework combinations

So while there’s no obvious visual conflict in this example, I’d read this more as a coexistence success case than as proof that embedding is safe in the general sense.

I also think it’s important to separate the Tailwind-specific part from the broader global CSS problem. Tailwind Preflight is one possible source of bleed, but the underlying issue is not unique to Tailwind: any component package that ships global CSS can create the same class of problem.

For example, in this exact spike, if we added something as simple as:

div {
  color: red;
}

to FeatureSelection.css, that rule would not stay confined to the child component, it would affect divs in the PatternFly host as well, because the child stylesheet is being imported globally into the parent app. That would be a very concrete illustration that the current setup demonstrates compatibility, but not isolation.

So maybe the scope of this issue should be framed a bit more explicitly around:

validating that the editor can be embedded in host applications without unintended styling side effects, and defining what strategy we want for that (scoping, packaging, Shadow DOM, iframe, etc.)

If that sounds right, I think the spike is still a great starting point, it just may not be enough yet to close the issue on its own. A useful next step could be to extend it with a few intentional conflict tests like the example above, so we can verify both host → editor and editor → host behavior in a more explicit way.

[kumaradityaraj]

Can't we scope the tailwinds component css through shadow DOM?

[lornakelly]

Can't we scope the tailwinds component css through shadow DOM?

We could for true isolation but might also be good enough to scope styles for now as we will not have much custom styles outside of react flow for MVP and could add shadom DOM in future if needed - we can discuss as well though

@JBBianchi Thanks for your feedback - I performed some tests as well on Fabrizio's repo, summary below that I think answers some of your questions?

Summary

• Added a parent Tailwind setup with custom global styles, and embedded a child Tailwind package inside it
• Scoped the child package using a dec prefix and a .dec-root wrapper, with its own custom styles
• The child includes Tailwind preflight by default via @import "tailwindcss" prefix(dec);

Findings

• The parent’s global styles are not overridden, even though preflight is also included in the child. This is because Tailwind places preflight in @layer base, while the parent’s global styles are defined after the import and outside any layer, so they take precedence
• We won’t add any unscoped global styles in our component. All styles in our component will be wrapped under .dec-root (e.g. .dec-root h1, .dec-root h2 { ... }) to avoid affecting the host app. We will make sure not to add styles not embedded in our wrapper class
• Because of this scoping, our styles wont get overwritten by global style. A selector like .dec-root h1 is more specific than a global h1 from the parent
• One caveat: if we don’t explicitly style an element (e.g. h2), and the parent has a global style for it, that style will still apply inside our component. This is expected - we can either define styles for those elements or allow them to inherit from the parent where appropriate - this could even be desirable in certain cases

Screenshots

Child styles:

Parents styles:

Clear to see that the child and parents styles are separate and dont override each other:

---

If child doesnt specify header and p styles

Inherits styles from parent

[fantonangeli]

I updated the gh-pages branch with the 2 webapps:

• patternfly-parent: https://fantonangeli.github.io/tailwind-patternfly-spike/patternfly-parent
• tailwind-parent: https://fantonangeli.github.io/tailwind-patternfly-spike/tailwind-parent