Server: Switching to scss

[skjnldsv]

This is becoming more and more needed. The more we wait, the harder it will gets for us to make the switch later.

Sooooooo let's do this!

Why

1. Nesting and code readability. This is an insane advantage to have. Right now the code have a basic structure, but it's still very hard to find whatever you're searching.
2. Size. Scss files are significantly lighter than css. if correctly implemented, the generated css file should still be lighter than what we currently have.
3. Redundancy. Actually we have a lot of similar stuff that would be great to merge (inputs.css for example)
4. Variables. Will definitely improve the overall design guidelines for this project and allows pretty much anyone to quickly edit a global var for customisation.
   

   Goals

• Only increase the entry barrier with the scss language. No sass lib needed, no core compilation...
• Use caching for freshly compiled css
• Do not compress output if debug enabled (for devs)
• Rewrite all css into scss with proper nesting

• Convert and regroup similar used colours into variables

  Numbers

• First commit with a basic css to scss conversion and compression enabled saves 10.965KB

  Roadmap

• [x] Use on-the-fly scss compiler so no one has to install anything

• [x] Cache system
• [x] Detect and change url on compiled files
• [x] Convert css to scss
  
  
  
  • [x] apps.css
  
  
  • [x] fixes.css
  
  
  • [x] fonts.css
  
  
  • [x] global.css
  
  
  • [x] header.css
  
  
  • [x] icons.css
  
  
  • [x] inputs.css
  
  
  • [x] jquery-ui-fixes.css
  
  
  • [x] jquery.ocdialog.css
  
  
  • [x] mobile.css
  
  
  • [x] multiselect.css
  
  
  • [x] share.css
  
  
  • [x] styles.css
  
  
  • [x] systemtags.css
  
  
  • [x] tooltip.css
  
  
  • [x] update.css
  
  
• [x] Switch to AppData
• [x] Tests
• [x] Finish guest.css file
• [x] Cleanup scss files
  
  
  
  • [x] Fix copyrights
  
  
• [x] List and regroup variables into variables.scss

• [ ] Regroup and merge keyframes into animations.scss

  Optionnal

• [x] Compress css on compiling (if no debug mode)

• [x] Added original SCSS line numbers for better frontend debugging (if debug mode)

@Henni @MorrisJobke @BernhardPosselt @jancborchardt

[LukasReschke]

Use on-the-fly scss compiler so no one has to install anything

If that is possible: 👍

Otherwise that would be kinda of a bummer to tell people to do "just these 10 steps to change CSS files" ;)

[jancborchardt]

Yup, as talked about if we have an on-the-fly SCSS compiler it’s good. :) If not it’s a very annoying barrier.

[skjnldsv]

Yep! This is mandatory!

[raghunayyar]

well, this can be integrated with the task runners we use for the applications at-least. So, no additional steps for the app standpoint.
I am super happy for us to move to sass, it has been long pending.

[skjnldsv]

@raghunayyar you mean cron? How will we handle the compiling if the user load nextcloud but the cron hasn't started?

[jancborchardt]

@raghunayyar having a task runner for core development is exactly what we want to avoid ;) it’s about on-the fly CSS generation.

[raghunayyar]

@skjnldsv I meant something like grunt / gulp / webpack. But @jancborchardt seems legit about avoiding that hastle in core. It can be taken in account for apps though.

[MorrisJobke]

@skjnldsv I meant something like grunt / gulp / webpack.

No way. We will not introduce such stuff - it only confused people - new ones in the same way as existing contributors.

[Espina2]

Really nice that you guys switch. I agree 200% with @raghunayyar we should have a task runner to.

@MorrisJobke I don't think you can confuse people if you only to run one command to run the taskrunner. Grunt serve, or Gulp serve its very easy and remove complexity. It bring not only the sass compiler but the server, the minify tools (for image and code) and all other stuff you have to manually. But since this are PHP based maybe compass are more "nice".

[skjnldsv]

No we won't implement this. This has been discussed sooo many times before, and we want to avoid that. Having a direct compilation and a cache system is the easiest way.

[Espina2]

As you guys want, its a step forward anyway. Just thinking in what is more easy. I just think its more easy to new guys have the project if you have taskrunner that install all the depencies. But it can be only me.

[Henni]

@Espina2 @skjnldsv is working on a way to integrate scss without any development dependencies at all. Instead nextcloud will compile scss to css on the fly.

[Espina2]

@Henni

I know what it is. This are introduced in nextcloud website, but removed after some time. I don't think this are a good practice have a script that compiles the code. It will load all the page with only html and after some time it compile the code. If you are in a slow network this will hurt a lot.

So if this script is only for develpment I think its okay, if are for production I don't think so...

[skjnldsv]

As far as I can tell, my server isn't having any trouble. And it's a one-time compilation. Lambda user won't have any issue.

[BernhardPosselt]

@Espina2 afaik its compiled using PHP, not the JavaScript compiler

[Espina2]

@BernhardPosselt @skjnldsv
I'm not sure, but i guess that work's in the same way. It always have to check if the file have differences, so How its possible to compile one single time?

[skjnldsv]

Well, on a non-dev user installation, the scss won't change except maybe after an update. So only a single compilation will ensue.

[Espina2]

So what you are saying is when this are released you only have the css compiled in the folder, and further "tweaks" should be done in that css file?

[BernhardPosselt]

I suppose the first web request will compile it

[MorrisJobke]

@skjnldsv I think this one is done :) We could refine based on the current state step by step if needed. Thanks for this awesome contribution :)

[skjnldsv]

@MorrisJobke 💘