Use Sass for vscode's styles

[Tyriar]

@bpasero thoughts on this? I'd like to give this a shot at some point if everyone is cool with it. The reasons for doing so are:

• libsass is very mature and on par with the original ruby lib in terms of features

• Significantly reduce the size and complexity of our development css files through leveraging nesting, for example this:

  .monaco-workbench .panel.integrated-terminal .xterm {
  background-color: transparent!important;
  position: relative;
  }
  
  .monaco-workbench .panel.integrated-terminal .xterm:focus {
  outline: none;
  }
  
  .hc-black .monaco-workbench .panel.integrated-terminal .xterm:focus {
  outline: 2px solid #f38518;
  }

  becomes:

  // In a shared file
  $hc-outline-color: #f38518;
  
  .monaco-workbench .panel.integrated-terminal .xterm {
  background-color: transparent!important;
  position: relative;
  
  &:focus {
      outline: none;
  
      .hc-black & {
          outline: 2px solid $hc-outline-color;
      }
  }
  }

• We could leverage Sass variables (compile time) for non-themeable colors in addition to CSS variables for themeable colors (#8151). Sass variables can also be used for reusable images, media queries, margins, etc.
• Use of // comments are not included in compiled CSS, meaning we can add more documentation to complex styles without worrying about it ending up in the resulting file
• Mixins for commonly used styles/media queries/etc.
• It's way more fun to write in Sass

/cc @bgashler1

[iam3yal]

@Tyriar Just a naive question, why not Less.js? :D

[bpasero]

@Tyriar what about introducing CSS variables for all of this here?

We would still need a shim for standalone editor though...

[Tyriar]

@bpasero introducing Sass would be about more than just using variables, it would be best to use both pre-processor variables (for non-theming uses) and CSS variables (for themes) (#8151)

@eyalsk personal preference (syntax is nicer), popularity (community and commits), libsass is very mature so no longer needs ruby.

[iam3yal]

@Tyriar gotcha.

[yisibl]

Sass is a very good choice, especially in strict compliance with the CSS syntax.

We may need to pay attention to avoid excessive nesting of the selector. Then you can also introduce Autoprefixer to automatically generate the prefix, now there are too many do not need the prefix.

[felixfbecker]

@Tyriar @eyalsk I always prefered Less because I never met anything that wasn't possible with Less. Less is written in JS, so you can simply npm install it and it will run in JS. With Sass you either need to install Ruby or use libsass (which uses C). Sass is still very tied into the Ruby world though. For example, Less has the relativeUrl option to rewrite URLs from imported stylesheets (needed when you import libraries like font-awesome from node_modules that reference fonts). When the same feature was suggested to Sass, the developers just said "you don't need this because Compass provides asset helpers", completely ignoring that there are poeple out there who use Sass without Ruby/Compass with other package managers like NPM.

[iam3yal]

@felixfbecker I also prefer Less but that's their decision to make not ours. :)

However, I can relate to what @Tyriar said, many people prefer to use Sass not to mention that bootstrap 4 is rolling with Sass.

[Tyriar]

They both solve the same problem at the end of the day, it would probably be put to the team which one to use in the end.

[felixfbecker]

@eyalsk yeah I know, Sass is "in" at the moment. I wouldn't count Bootstrap 4 as an argument though, it's been in alpha for ages now while Bootstrap 3 is written in Less. However, there was a Sass version of Bootstrap 3 that worked perfectly fine, and I bet there will be a perfectly fine Less version of Bootstrap 4. If not, you can still import the compiled CSS. But that's off-topic

[iam3yal]

@felixfbecker yeah, I didn't use that as an argument really but many people are influenced by Bootstrap so it's more of an example. :)

There's also a technology called PostCSS that seems to be great and faster but yeah whatever makes them happy.

[felixfbecker]

@eyalsk PostCSS is a great complement for Less or Sass, you can autoprefix your styles, minimize them, etc... But it doesn't add new syntax. CSSNext is aiming to be the Babel for CSS, adding the new variable syntax etc.

[iam3yal]

@felixfbecker Yeah, I know. ;)

[chrmarti]

The flexibility of Less or Sass make it more likely to end up with large amounts CSS. Is that a concern? Any experience with that?

[Tyriar]

@chrmarti it's completely avoidable if you know how the CSS is produced though, staying away from mixins and placeholder selectors unless you understand the resulting CSS? Also I don't think heavy CSS has that much impact, at least compared to web, since everything is read off disk.

[rebornix]

@Tyriar @chrmarti the only thing I think is useless and redundant is auto-generated -moz-, -ms- prefix properties as we are using webkit inside VS Code and it's totally avoidable :)

[iam3yal]

@rebornix I'm not sure but maybe they are doing it because the Monaco editor is now available as standalone so people may want to run it on the browser.

[bgashler1]

@eyalsk that's correct. However, we could eliminate the need to have these prefixes in our repo by using an auto-prefixer on top of using SASS. Then our code readability and simplicity will be much better.

[iam3yal]

@bgashler1 Yeah, I totally agree, I mean doing things manually isn't efficient so I'm sold on automation! ;)

[dstorey]

I have a few cents on this, although my opinion doesn't count much as I'm not developing the code base each day.

IMHO moving to SASS at this stage, especially after much of the CSS is already written, isn't the best approach to take.

1 problem is it splits the community as some devs (myself included only know pure CSS), while others prefer LESS, or SASS, or Compass, postCSS, or whatever flavour of the month will come out next. I was going to help on another project we did and the code was like hieroglyphics, even for such a simple project, so I gave up.

Another is how you lose control of the code that is output and can lead to bloated code. It is mentioned above that heavy code isn't so much of an impact as it is read off disk, but this is only partially true, as it can still lead to more memory and perf issues having more code, but more so isn't it possible to host VS code online (wasn't it vs online or something?) and Monaco is certainly included in online projects. I'm not sure how much this will impact Monaco or if it is only for the UI frame? It is something I've been looking to use for the Edge dev site (we're very performance focused and our CSS is only 10k for the entire site including our framework we wrote. Not using less or sass helped here greatly...the other reason we didn't use is to dog food the latest CSS features).

But mostly we're getting to the stage where pure CSS is getting the features of CSS pre-processors, so in someways it would be like moving to Coffeescript just as ES6 was maturing. In my mind it would be better to use the modern CSS features like custom properties and apply (improving editor support for these at same time where appropriate) and use something like postCSS (which is the new hot thing over SASS in some respects) and the CSSNext (cssnext.io) plug-ins for the features used for when used outside Blink. (although I'd probably avoid things early in the standards process that are not in a browser or stable-ish spec). Custom properties for example is now in every modern browser except Edge, but we're currently implementing it.

[Tyriar]

@dstorey thanks for the feedback, see responses below:

1 problem is it splits the community as some devs (myself included only know pure CSS), while others prefer LESS, or SASS, or Compass, postCSS, or whatever flavour of the month will come out next.

The majority of the codebase would remain plain old CSS, just with a new extension. Also I don't think Sass or Less should really be referred to as "flavour of the month" since have been around a long time and have proved their value.

Another is how you lose control of the code that is output and can lead to bloated code.

I would argue the opposite; a pre-processor allows the reuse of styles, making it much easier to spot styles in which are no longer necessary. Currently if you look at the styles there is a hell of a lot of repetition in selectors, images, etc. which can also lead to inconsistencies. You are in complete control of the output provided you know how it works (like most things in software), the main thing here is be wary of features like @mixin and @extend in Sass unless you know that it's what you want.

But mostly we're getting to the stage where pure CSS is getting the features of CSS pre-processors

I think you're missing the big part of why pre-processors are beneficial. They pre-process your CSS, you can still target as high-level CSS features as you want, they are designed to accomodate new CSS features. They just add some syntactic sugar that allows you to manage your CSS far better and keep it DRY in large projects.

One of the biggest misconceptions when talking about this subject is that pre-processor variables = CSS variables, this is not true at all. Pre-processor variables get compiled down to plain CSS values, meaning they are identical to CSS primitives only that they just need to be specified once. CSS variables are scoped and can change at runtime so they are more functional that pre-processor variables, but they will often take up more bytes (you mentioned bloat).

There are some things that native CSS simply can't do as good as pre-processors since they're essentially compilers, such as:

• Reducing the verbosity and improving readability of styles:

  .monaco-workbench .panel.integrated-terminal {
  color: #333;
  .vs-dark & { color: #CCC; }
  .hc-black & { color: #FFF; }
  }

  vs

  .monaco-workbench .panel.integrated-terminal { color: #333; }
  .vs-dark .monaco-workbench .panel.integrated-terminal { color: #CCC; }        
  .hc-black .monaco-workbench .panel.integrated-terminal { color: #FFF; }

  The default terminal colors 16-255 is another good example of reducing verbosity as a function could be written that outputs this CSS only in a handful of lines (similar to the previous implementation which was in JS).

• Sharing logic and variables across multiple unrelated files using mixins, placeholder selectors and variables

[joaomoreno]

I feel a link is missing in this thread: http://cssnext.io/

[Tyriar]

@joaomoreno as I understand it it's much less clear what the generated CSS is when using cssnext as it tries to polyfill rules that aren't supported widely. Bloat was one of the concerns raised.

[joaomoreno]

That seems to be customisable, though: http://cssnext.io/usage/#browsers

[Tyriar]

This option enables or disables features according to caniuse database

I'm confused, does that mean it's just regular CSS with an auto-prefixer if you set this to a particular browser version?

[joaomoreno]

Not sure. My understanding is that it works like a sort of build target.

[Tyriar]

Some interesting data on the topic http://stateofjs.com/2016/css/

[equinusocio]

CSSNext is the future. Since vsc use electron you have to worry only about -webkit-, that supports almost everything. You can configure what it should be compiled and what not.

So, css custom properties (vars) can still remain as is and you can update its value live. This kind of approach also allow you to set a variable value by its parent, live (maybe through settings). You can also use css nesting, custom media queries, css mixins and a lot of css native features. If you use only custom properties, you don't need to compile.

The main benefit is that your css codebase is native, always supported and future proof, no custom-syntax like preprocessors, no breaking if you will want to use a preprocessor. And if you use PostCSS, you can add a lot of functionalities.

[vscodebot[bot]]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that have been on the backlog for a long time but have not gained traction: We look at the number of votes the issue has received and the number of duplicate issues filed. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!