Limit scope of global styles / reset

[marbemac]

Moving #115 (comment) over here.

Global css reset might cause issues in consuming applications - what are our options?

--

Separate the reset css out to separate file / functions that end user would be expected to include themselves if they are not using their own reset.

Downsides are:

1. more work/complexity for consumers that don't already have their own reset and
2. what if consumer's reset doesn't do all the things mosaic is expecting?

---

Option to customize reset scope somehow. This is tricky because:

1. at least for the JSV use case the scope would probably have to be very specific (targeting just JSV containers).
2. what to do about portals / other things that are mounted outside of the regular tree (for example dialogs, popovers, etc)

[marbemac]

@Fox32 no rush but whenever you have a moment could you expand a bit re how you're integrating JSV (and thus mosaic) into your application? Curious to learn a bit more about your use case to help inform decision making here.

Oh also a few examples re which bits of the global CSS are causing you the most issue would be helpful as well to get an idea of the potential problems!

[Fox32]

Good news, it's all open source. The plan is to integrate it as a viewer for json schemas in the api-docs plugin of Backstage.

I created the following PR: backstage/backstage#5532 (now reverted, but I'm happy to reland it later).
Backstage is using material UI react which is what mosaic is clashing with.

As I'm using mosaic only for the viewer I only need the styles locally. However, as you already mentioned above, this is an issue with popovers, like the select box. Maybe it would also be an option to provide it as a web component which might provide better style isolation.

[Nabeeh-AlSawaf]

any news on this ? i really dont want to include the whole mosaic styles only for this

[BelfordZ]

related to stoplightio/elements#2250