Add user stylesheet

[ironyman]

Implements the feature request from #459

[vincen]

I'm vscode fans, but to be honest, Brackets's interface is better than vscode. I'm look forward this pull-request.

[OutThisLife]

🎉 Let's make this happen.

[bpasero]

Thanks for this PR but we decided to not allow these kinds of modifications to our CSS directly. Rather, we think that our theming story should be evolved to allow more user configurations. See #26128, #26129 and #26130 for example.

The two main issues with this approach here is:

• basically this makes all of our CSS class names API (in the same way all of our themable colors have become API). we do not want to commit ourselves to keeping the CSS class names stable. rather we should find those styles that we want to make themable and then explicitly announce them as API (same as we did and do for colors)
• the other issue is that bug reports we receive will be harder to understand if users run with custom CSS changes that we are not aware of. we think that we should be in control of which user styles can be changed and provide explicit support for instead of opening the door to any CSS changes that are possible with this approach

[usernamehw]

@bpasero

1. But users already use Custom CSS and JS Loader and it's worse because it requires reload every update, admin rights and corrupts install.

   Conduct some kind of vote if users wishing to have this Feature agree not to complain about changing CSS names and close all issues about changed naming as dupliates with reference to that vote.

2. Make something similar with --disable-extensions: --disable-custom-css

You can't make 10ⁿ configs to change every minor CSS setting.
It doesn't even have to be a permanent solution: users will change CSS and wait for the implementation of some feature in the core editor.

[jens1o]

I'm a bit disappointed :c
I was so looking forward to see this happen...

[ironyman]

@bpasero

1. Let's put a warning at the top of the file that the class names are unstable. I don't think atom provides any guarantees of stability either.

2. We could tell users to disable custom css (and probably extensions too) before sending bug reports. There are already some popular extensions that change css (in far less reliable ways as @usernamehw mentioned) that already could make bug reports terrible. Allowing users to see the custom css and disable it should improve bug reports rather than make it worse. Regulation over prohibition should be a concept familiar to many.

3. Furthermore, this would address other popular issues as well, e.g. tweet feedback button - make it hideable #7893, Add some API to support GUI customization #1833 . This PR seems to be aligned with what many VS Code users want.

[chrisdothtml]

@bpasero

we do not want to commit ourselves to keeping the CSS class names stable

I don't think anyone expects you to. Just like with Atom, classes change all the time, and users should expect to have to adjust their custom CSS accordingly.

My use-case for custom CSS isn't changing the entire skin of vscode, it's tiny things like wanting to change the border around the bracket matchers because I don't like how they render next to the cursor

the other issue is that bug reports we receive will be harder to understand if users run with custom CSS changes that we are not aware of

I think this could easily be solved by a strict enforcement of not allowing bug reports while custom CSS is enabled. Similarly to how you may ask someone to disable plugins/extensions, people should also disable their custom CSS

[bpasero]

@chrisdothtml I suggest to file enhancement requests for these little things that you want to see different and we can think about adding an option for it specifically.

[felipenmoura]

Well, you really think that's the best solution?
Every time someone wants to change something VSCode hasn't an option for, there should be a long discussion about it, involving a lot of people, then to (perhaps) allow it as a new option in the next update?!
You seriously think that is the best option?
I still believe that "giving developers the power to customize" would be simpler, faster, and make a lot more people happier :)

[chrisdothtml]

@bpasero is the decision to not implement custom CSS a branding thing? It would make sense if the team wanted to maintain a consistent appearance for vscode (and it would explain why the theming is so limited in general).

It just feels like the reasoning given for not doing it doesn't hold water. This is a tool for people who like to hack their tools and make them their own. I agree with @felipenmoura that it would be much more extra work to go through a feature request for every tiny tweak to the UI.

Quite a lot of development tools allow for this (either natively or via an extension) because it makes the authors' jobs easier! Why waste time addressing everyone's opinion on the UI, when you can just let them make any adjustments they want

[AshGrowem]

End war the on user customization

@bpasero My points have already been stated, but seeing as the issue hasn't been solved yet I will reiterate and expand. This will be direct, but I write in all friendliness and am directing this not just to you but the entire VSCode team.

we do not want to commit ourselves to keeping the CSS class names stable

We aren't asking for stability, just the option to enable user stylesheets. Just add a disclaimer notification upon toggling the proposed editor.userstylesheet setting that this option is unstable, unsupported, and that CSS class names are prone to breaking changes. That plus editor.userstylesheetlocation is all you need to start. Over time you can add further functionality by just copying from work already done by amazing extensions like Custom CSS and JS Loader.

the other issue is that bug reports we receive will be harder to understand

That is already happening because you have despoiled the commons and forced users underground. Anyone who was intending to add user styling has already done so through bootstrapping 3rd-party solutions like Custom CSS and JS Loader. Adding a user stylesheet setting will not change the amount of people hacking their vscode, it will just change the way they do it. In fact, it will do it in a much more controlled way that you can eventually seamlessly fully integrate and iron all the issues out of.

Furthermore, you have spawned a plague of unnecessary issues (ex. #46403) that could have been cured with a single core setting. Now, instead of users just typing a single line of CSS in their local stylesheet, they are forced to pollute your Github with numerous requests for minuscule changes to their VSCode appearance, making your jobs harder, not easier! It is infinitely easier to write some local CSS than to convince Github maintainers to implement a core solution, and it is way easier to just allow user customization than to meticulously review PR's and Issues, and write fresh code where no one is contributing.

You can rest assured by virtue of sheer human laziness that all of us editor hackers will prefer to just continue editing our user stylesheets than arduously voting, commenting, and creating PR's and Issues. Allowing this will drastically cut down on issues.

I suggest to file enhancement requests for these little things that you want to see different and we can think about adding an option for it specifically.

Why does it have to be one or the other? Why not both? We already wrote the code for you, you're literally creating more work for yourselves by disallowing user styling.

As @ironyman pointed out so succinctly "regulation over prohibition". You have prohibited us, so the people have taken to the streets, over 150,000 of them (Installs on Custom CSS and JS). End war the on user customization.

[kiwi0fruit]

@bpasero Is there a way to define custom font in the CSS via @font-face { ... } so that it can be used in VSCode settings?

[AshGrowem]

@kiwi0fruit Install Custom CSS and JS Loader and then follow the instructions to add the following to your imported stylesheet:

.settings-editor * {
  font-family: Ubuntu !important;
}

You can experiment with and without the * universal selector, as well as !important. Use Developer: Toggle Developer Tools in the Command Palette to find the areas of GUI you want to edit.

I'm not familiar with @font-face so you'll have to implement that yourself.

[kiwi0fruit]

@ashrafhadden Thanks. But I meant setting in the standard interface in settings. Not playing with themes. And I also prefer to do that without Custom CSS and JS Loader.

I guess that not possible but I'm at least curious if it ever would be possible.

[jabacchetta]

@bpasero

allow more user configurations

The problem is, with over 5,000 open issues, many of the theming feature requests are being closed, with the reasoning being that they won't be implemented any time soon. So while more configurations would be nice, realistically, that might not happen for years, if ever. This would have been an instant solution.

bug reports

As others have already stated, extensions that allow you to hack this problem are already contributing to this

By the way, for anyone looking for a less-hacky solution, Customize UI works well.