Hi,
I was studying the core code and saw that we are using pure css. Imho it would be more dynamically to use Less. That makes it possible to change the color of the whole application by changing one value. It makes our code more complex but cleaner. For colors, gaps, icons and many more we can reduce the effort to change something.
Here is the homepage of that project: http://lesscss.org/
What do you guys think about that?
Here will come the names of all others css preprocessors, as sass, scss or stylus or any others, then wich transpiler with wich tasks runner is best (gulp, brunch, grunt, etc). 
But yes, that may be cool to have some tools for css. And a sytle guide ! (There’s a beginning here : https://doc.owncloud.org/server/9.1/developer_manual/app/css.html)
I agree with that, there are many more preprocessors than less. I like the simplicity of less. It looks similar to plain css but provides the most important features. I think we should use something very small to keep our code clean. Also less is often used in combination with angularJS which is a very modern functional script language.
But maybe there are arguments against less. Hope the community has a opinion to that topic.
The main problem is that it raises the barrier to entry. If an app dev uses Coffescript + sass + babeljs, he’s probably going to be the only one capable of submitting PRs and capable of testing them.
There are a multitude of tools for CSS and JS. The decision is that we want to keep the entry barrier low and therefore don’t rely on anything too special. This is only for core however, app authors can do as they please 
that’s why I wanted Less to be that tool. It is very simple and similar to plain css. In that case the barrier is not really existing. Someone who could contribute php and js code, could also work with less 
Imho the advantages outweigh the disadvantages, but in the end our core developers have to decide what is the best for the project 
Edit: we already talked about tools which could help to centralize resources like colors and images so we just have to change one single file if we want to change something. So there is a need for such a tool I think.
Less is more cool, sure. But you have to use transpiler for performance’s sake. Then to test his/her css modifications, any dev will have to know how to run the transpiler. That’s not so easy.
Anyone may create a theme without much difficulty, there’s no need for any tools except an text/code editor and some time. With less, you will have to search / read/ understand the doc to know how to compile your less in css.
What would be great is if someone would release a theme builder, like they exist on other platforms.
Add a logo, the few colours used for the identity, pick a font and you’ve got your own theme.
With a CSS preprocessor the theme builder would be no problem
Becuase just the less file hast to edited, instead of all css files.
The problem isn’t with Less itself, but the philosophical problem others have pointed out in raising the barrier to entry for contributors.
You say that Less is easy and has no barrier to entry, but that’s not strictly true. I personally prefer (and use on a daily basis) Sass and Grunt, but no matter how simple I feel these tools are once you’ve learned them and they’re all set up, the inescapable truth is that they are not as simple as plain HTML and CSS for new developers to get up and running.
The lower the barrier to entry for contributions, the more people can jump in and get involved with making Nextcloud awesome. And I think we should encourage that, even if it means forsaking some of the conveniences and power features from using pre or post-processors and similar tools.
I never used Sass and Grunt that’s why I don’t have an opinion to this tools. But you can also say php is a barrier, Learning PhP more complicated than learning to work with any css preprocessor. But ok lets say, there is a barrier for new developers. Using a CSS preprocessor would avoid the effort for them. They don’t have to learn css or html because they can use for example a theme builder which is based on our less file. Just changing one attribut could change the look and feel of the whole theme.
We have to weigh up positive and negative aspects. Maybe there are barriers for developers, but I think the advantages outweigh the disadvantages in this case.
PS: life is about to learn
While I understand that there is more to learn to understand LESS as well as straight CSS, in many ways I feel that it actually lowers the barrier to enty in other ways. For example, it’s far easier to hunt down exactly which line of code generates color X, because there is literally less code, and the one color code may end up being reused in dozens of other places. With traditional CSS, inexperiences designers will often find the hex code of the color they want to change, and then search for it in the CSS. With LESS it may be there once, where with traditional CSS it could be there a dozen times or more, forcing the designer to search, edit one instance, see if it does what they want, if not, revert and try the next instance. It’s a slow and painful process, made largely redundant by LESS.
Cc @jan because about this was talked a lot in the past. Generally the idea is to simply do a git checkout (and submodule update) to have a running node. We really focussed on getting everything up an running without anything more than git. Another tool would just heighten the barrier for setting it up
Aren’t CSS variables already supported BTW?
Oh, hello IE…
You’re making your own life miserable, all ie versions together are below 10%
unfortunately the problem is not only IE related. There are several browser versions which are not supported. But maybe in a open source project like this we can make the decision that older browser versions are not supported. the question is, what happens when somone use the website with an old browser and this css feature is not supported?
You could simply fallback to a default. Now you’ve got the best of both worlds
How would you do that with this feature? Sounds like you would need to do the work twice, once with variables and once with normal CSS, duplicating stuff everywhere.