Allow custom stylesheet about hyper

[rauchg]

Continuing this conversation here: #14

[bastilian]

Ps.: If that is an acceptable solution, i'd prepare it in a PR. :D

[leo]

Great idea!

I would recommend using a styles.css file, because it prevents people from complaining about having to use a specific subset of CSS (like Less). If someone wants to use Sass/Less, they can still set up a simple build task and compile it.

Maybe we should also put a config.json file into ~/.hyperterm/ then? The readme states "Define approach to conf management" as a todo item.

[bastilian]

.less is just a different format, essentially, that extends css rather then limiting it. It also comes with features that could be beneficial, like variables, that could be useful when it comes to theming.

I think if with this a ~/.hyperterm/ directory is introduces it would make sense to also use it as the location for a config.js. The directory can also hold things like themes, packages/plugins, caches and logs.

[leo]

.less is just a different format, essentially, that extends css rather then limiting it. It also comes with features that could be beneficial, like variables, that could be useful when it comes to theming.

I'm aware of Less' features 😊

However, I generally don't think that it's a good choice since Sass saw the light of day. If you look around the web, you'll notice that the majority of projects have already made the switch to it or PostCSS.

And because I don't want to start bikeshedding about what's the best choice when it comes to choosing a build tool (Sass/PostCSS/Less/whatever), my personal recommendation would be to simply go with normal, plain CSS.

This also has the great side-effect that we won't have to compile the code before loading it into the application. And as I said: If someone really wants to use one of these tools, there's still the possibility to set up a simply build task using a build tool.

What I do think as well is that variables could definitely be useful when it comes to theming. However, I think we're generally better off with using CSS variables. They can be modified in realtime! 🤘

Since Electron already runs Chromium 51, we should be able to easily take advantage of them.

[bastilian]

You are totally right, that plain css would be the right way to go. I wouldn't find it a bad idea though to offer .less as an option, with the compiler included and configured, as some find it more readable than plain css, but that could also be solved via a package/plugin.

[leo]

Okay! But then we'll have to offer an option for Sass, PostCSS, etc. as well. And IMHO, that's just too much and only confuses people.

Also keep in mind that we wouldn't just have to include and configure the compiler, but also make sure that it gets all the predefined theme data (variables, etc.) from somewhere. And this mechanism would have to be different for each of these build tools...

I think the perfect setup would be to go with CSS (I think we both agree on this now), but also to not somehow barricade/block the use of tools like Less, Sass and PostCSS (I'm talking about compiling files to CSS before they get loaded into the application).

If people really want to use them, they should be able to! 😊

[bastilian]

Okay! But then we'll have to offer an option for Sass, PostCSS, etc. as well. And IMHO, that's just too much and only confuses people.

One option, doesn't imply the other(s). Atom offers style.less, but not Sass and PostCSS for example.

The variables wouldn't be used for theming, but are a useful feature of less, which in css are CSS variables. Pre-compilation would be triggered on app start if a sytle.less file exists and or is updated, and would cache the compiled version for inclusion in the app.

And as said, "maybe" .less, the focus in this issue is adding a way to customise the style easily, style.css the primary solution/approach, everything that can compile to this is an idea and optional.

[leo]

One option, doesn't imply the other(s). Atom offers style.less, but not Sass and PostCSS for example.

Exactly! And in my opinion, that's a more-than-bad approach. Simply because of the fact that it forces the user to use a certain syntax even if he/she doesn't want to (as bad as forcing CoffeeScript).

I think we're basically wasting performance by compiling stuff on runtime. But like you said, let's just implement the basic mechanism for CSS and then see how it goes from there!

[zouhir]

I think CSS is enough and we most likely will not need a preprocessor for couple reasons:

• we don't have a lot of selectors nesting
• not so many font styles and variations in font sizes, etc..
• we can work around not using mixins for colours, sizes, etc.. easy

Hyperterm is 1 consistent and clean window. Atom has so many things going on starting from their settings/packages page to the sidebar with project treeview etc..

However, the idea is really great! I love it.