Make import of defaults css files optional? about glsp-theia-integration HOT 4 CLOSED

I see.. I understand that they broke! But wouldn't styles defined in the ecore theia integration have higher prios than the ones imported in glsp-theia base? If yes, could the issue in ecore-glsp be addressed by adjusting the styles in ecore-theia accordingly? If they would be written now from scratch, we could achieve the same style in ecore-glsp also with importing the css from @eclipse-glsp/theia-integration, right?

What I'm getting at is that:

1. we want to give full flexibility to the custom diagram implementations, so the custom diagram implementation must be able to overwrite everything
2. we want them to get as much styling as possible by default where it makes sense (e.g. command palette, palette, editor looks such as background, default line and border color so that it works with Theia styles, ...) without having to worry about Theia styling etc.
3. we don't want them to having to know which css files they need to import (this would have to be documented additionally). Ideally they just say, I want the theia integration and the command palette by adding the node import but then they don't need to have to explicitly import the css.

What do you think?

from glsp-theia-integration.

If they would be written now from scratch, we could achieve the same style in ecore-glsp also with importing the css from @eclipse-glsp/theia-integration, right?

If think so yes, but the class definitions would have to be quite precise (ie. complicated). The main problem here is that the "sprotty" css classes and the css classes provided by the server via the "classes" property of 'SModelElement' are not necessarily applied on the same element.
e.g. for rectangular sprotty nodes the "sprotty-node" class is applied on the rect element whereas the class "ecore-node" would be applied on the parent <g> element

from glsp-theia-integration.

and as a consequence a previously
simple definition like: .ecore-node
would have to be defined as something like g .ecore-node > .sprotty-node

from glsp-theia-integration.

Wouldn't it also work then to just assign an additional class to .sprotty-graph such as .ecore-graph and then do a: .ecore-graph .sprotty-node? With that it should already be more specific than the default css we're importing in glsp-theia. As it is just the stroke of edges and stroke/fill of nodes, I guess it wouldn't be interfering with custom layouts a lot.

I'm not opposed to removing the fill: var(--theia-editor-foreground); of .sprotty-node. Imho this is the only thing that might interfere. Setting the stroke as --theia-editor-foreground will most likely be ok in 99 % of the scenarios and adds the benefit of not having to worry about switching themes.
The rest (selection color and editor background) is something theia-editor specific that most likely will not be overwritten by diagrams anyway, right?

from glsp-theia-integration.