Xterm.js: Consider moving CSS file into JS

[Tyriar]

Moving all the CSS rules into JS to be applied at the time Terminal.open is called would simplify use of the library and prevent people experiencing issues like this https://github.com/xtermjs/xterm.js/issues/3045. Overriding would also still be possible via !important.

This would need some verification work after (checking VS Code still works) and documentation updates.

[jerch]

@Tyriar Thb I dont like this idea for a simple reason - CSS is there for styling, we should not move things that can be styled with predefined rules away from the domain, that is meant for that purpose. (I'd go a step further and actually think that terminal themes should be in CSS as well.)

If ppl have issues to get CSS correctly loaded, then either our documentation is bad in this regard, or they should learn how to correctly embed CSS. Sorry if this sounds harsh, but for me moving away from CSS and doing everything in JS is a clear antipattern.

[Tyriar]

I'd go a step further and actually think that terminal themes should be in CSS as well

Interesting idea, I worry that it would make things harder to use though as then in addition to the static xterm.css file that the user should not change, they need to configure the terminal in their own CSS, separate from the existing config (options).

Extracting the styles would also be a little more complicated, I think we would need to create dummy elements to pull the styles from since the canvas renderer just uses a single canvas element.

Sorry if this sounds harsh, but for me moving away from CSS and doing everything in JS is a clear antipattern.

In general I agree, especially for client applications. For libraries I think it's a little more nuanced though:

a. The UX of the library isn't great at the moment as people need to install the module, and then link to the CSS file. This is mentioned in the README but it's not always expected and we get the occasional issue about this (the textbox is above the terminal).
b. The majority of styles are dynamically defined and can also be tweaked independently per-terminal, we cannot define these statically.

Since we already must do the styles via JS for b, we could make xterm.js easier to use by merging the small amount of rules in xterm.css into JS for a. The fact that we don't expect users to change xterm.css is another reason for this.

That's not to say it doesn't have downsides, like keeping styles in CSS as you mention in addition to how xterm.css are global styles while the JS ones are mostly terminal-specific that get duplicated. I'm fine to close this out if you still feel strongly.

[jerch]

@Tyriar I see why themes are not in CSS currently, and yeah - it might be cumbersome to get it working nicely with the pure JS renderer. (Still the browsers got way better in querying/observing CSS rules, so it would be theoretically possible to let ppl tag theme settings per CSS to the terminal element.)

I dont know why ppl miss the CSS part xterm.js, even in react libs, that provide custom output components, it is the normal way to do things.

Why I feel strong about it, is a separation of concerns. xterm.js is a JS lib with strong output notion, thus I would expect CSS usage. Writing it in JS is like building a wall from bricks every time, while the browser already has a building block for this particular task with CSS (which is further optimized in render handling). Maybe web components is worth a shot for xterm.js, they have really nice logic and style possibilities without ignoring common browser caps, and it would result in an easy to use "carry bag" (including logic and styles).

[mofux]

IMHO defining the terminal colors (themes) in JS provides us with the biggest flexibility, so we can use these settings across all renderers and vary the theme between terminal instances. I've also never heard someone complaining about this.

The xterm.css on the other hand provides the static styling for the terminal elements. I can't really think of a use-case where you would have different terminal styles for different terminal instances, so loading the style once should be enough. There may be cases where the css would not be required at all, e.g. when only using xterms parsing logic without actually rendering anything.

I think loading these styles should be a concern of the implementor, there are so many ways to bundle an application nowadays, and I personally hate it when libs start putting random styles in my document in a non-deterministic order.

[Tyriar]

Sounds good, let's close this out with as designed then since we already call it out pretty prominently in the readme 👌