I recall @rouk1 complained about the way we were doing our CSS there. Was it this way you thought it would be better done?

From memory, I had the $id because I did not know how dynamic the CSS would be in the future. For example, lets say we had a CSS very specific to a particular estimator, then the id prevents that CSS from impacting all the other estimators.

In this case, I think that we should do something similar to skrub by having a shadow DOM. We already have some side-effect depending on the IDE like jupyter or vs code that define some CSS variable that alter the behaviour of the estimator. Having the CSS scoped to each estimator seems to be something desirable.

(An interesting follow is to only write the CSS on the first repr call that is also in Jupyter, so it does not get copied over and over again.)

@thomasjpfan It would be great, that's what I wanted to do here*: RFC: Potential improvement of HTML Display's css logic. But Olivier thought that it wasn't possible. Moreover, Guillaume prefers to aim for the shadow DOM.

*Just sharing for background.

I recall @rouk1 complained about the way we were doing our CSS there. Was it this way you thought it would be better done?

Using a class is fine, as stated above the only edge case is if something uses the same class name. So I advise to use something long and semantically consistent to avoid collision.

Using a shadow DOM cover this edge case but adds complexity that's a tradeoff...

Note: vscode uses iframe to render cell outputs so serializing only once the css code will lead to un-styled estimator.