Improve the CSS situation

[ktecho]

(this comes from #51 (comment), which is a closed issue, so I opened a new one here so we can comment on this)

In my opinion, we should make something to fix the CSS mess. This are the problems I'm seeing:

1- Conflicts with other libraries (#71). I fixed this partially by nesting all the lexical.css classes inside another class:

.lexical-div {
    body {/**/}

    header {/**/}

    header a {/**/}

    header a {/**/}
}

In this way, I put the Lexical editor inside a lexical-div div, and classes in this file only affect the editor. If I don't add this, the lexical.css file is changing a lot of classes very used in apps, like body, dropdown, modal, switch, toolbar, etc.

But I still have the reverse problem: external libraries changing svelte-lexical behaviour by defining classes like modal, dropdown, etc.

2- Output of Lexical converted to HTML cannot be displayed in the same way as it's in the editor, because in PlaygroundEditorTheme.css, all the classes are defined with a prefix. So I'm thinking on just duplicating the PlaygroundEditorTheme.css file and removing the prefix, so it can be used in standard html... But that's ugly.

So, to fix both problems, I think we should do this:

1- In lexical.css, put lexical-specific class names, like it's done at the end of the file with Modal__content or ToolbarPlugin__dialogActions. In this way, external libraries cannot break this plugin, and this plugin doesn't break external components.

2- In PlaygroundEditorTheme.css, we remove the prefix (changes in code needed, of course) and wrap everything inside a super-class, so we don't have the problem we have in 1).

@umaranis what do you think?

I could help with a PR if you think this is a good idea.

[ktecho]

@umaranis Did you had a second to give a look to this?

@PaddiM8 If you have a moment, I would like you to also give a look to this.

Thanks!

[PaddiM8]

Wouldn't there still be the problem of external styles changing the styling of entire HTML components (eg. dropdown {...). I feel like this is the kind of issue the shadow dom was made for, but I don't know if there is some way to do that idiomatically with svelte.

[umaranis]

Sorry for the delayed response @ktecho

Here is my view on the issue. We don't want to style the components out of the box (in the library itself) because often users would like to style them according to their design system and CSS framework. That's why styles are provided separately and help in getting started. They are good enough to suffice in some of the use cases.

Now, how do we provide the users with the ability to style components as they like without having any conflicts? For the core editor (excluding dialogs, toolbar etc.), this is done with PlaygroundEditorTheme.ts file in playground/src/theme folder. This provides full control to the users to specify any styles for the various elements shown inside the editor (no hard-coded class names). The sample styling is provided in demo projects to get started. It uses prefixes with class names to make any conflicts unlikely for those who are getting started or experimenting with svelte-lexical. The styles are provided in a simple CSS file and it is left to the library users to adjust them according to their preferences and CSS framework. Because there are no hard-coded class names inside the library, we can avoid conflicts.

When it comes to other UI components like the toolbar, dialogs etc. we have a few issues:

• Class names are hardcoded. We need to apply the same logic to styling these UI components as was applied to the editor. It has a precedent in facebook/lexical repo where it has been done for comments panel.
• The styling provided in demo projects should use a prefix to avoid conflicts for anyone getting started with the library.

@ktecho does it make sense? Would you like to take it up and apply the same styling logic to UI components as applied in the editor? Thanks.

[codenoid]

yes I agree with @umaranis