Indicate that a LESS file should not be compiled on save - css

I'm using Visual Studio 2013 with latest Web Essentials. I chose to partition my CSS into separate LESS files, and create a build.less which includes all my stuff. Now when I edit and save for example tables.less, Web Essentials will automatically compile it, adding a lot of "junk" css files to my web project.
I would like to exlude all of my LESS files from compilation except for the build.less one. Of course I know that as a side effect I have to always do a dummy CTRL-S on my build.less, but that's a fair tradeoff for being able to structure my code.
I've checked all of the options of WE related to LESS compilation without success till now. Are there any "hidden" tricks or some LESS preprocessor directives to make it work this way?

Rename the file to start with an _.

Related

Ways to reduce SASS changeset between developers

I'm working on a site that uses Gulp to compile its SASS, among other things. It was set up by another developer on my team. I am brand new to Gulp and don't use SASS much either. However, getting it up and running was easy.
The one problem, though, is that when I ran Gulp, even though I hadn't changed anything in the source files, it changed pretty much every generated CSS file in the project. Every file had /*! typey | GPLv2 License | https://github.com/jptaranto/typey */ added at the top, and there were many files where numeric values changed by a tiny bit (like skewX(0.39063deg) → skewX(0.39062deg)). And it also added hundreds of *.map files which didn't exist before.
This has happened to me before using Compass too. It pretty much makes looking at the diff useless to see any actual changes. Is there a way to unify the output of our Gulp so this doesn't happen?

Does CSS file sorting matter and if, why?

I have a website which uses 1 css file, it is called body.css and it consists of 841 lines. Should it be sorted in different files (header.css, footer.css page1.css, etc...), is it better in just 1 file or does it not matter?
The only thing I know for sure is sorting it in more files is a lot more readable.
Also if someone answers this I'd be most grateful for a little explanation.
My opinion would be one of two things.
1) If you know that your CSS will NEVER change once you've built it, I'd build multiple CSS files in the development stage (for readability), and then manually combine them before going live (to reduce http requests)
2) If you know that you're going to change your CSS once in a while, and need to keep it readable, I would build separate files and use code (providing you're using some sort of programming language) to combine them at runtime build time (runtime minification/combination is a resource pig).
With either option I would highly recommend caching on the client side in order to further reduce http requests.
So, there are good reasons in both cases...
A solution that would allow you to get the best of both ideas would be :
To develop using several small CSS files
i.e. easier to develop
To have a build process for your application, that "combines" those files into one
That build process could also minify that big file, btw
It obviously means that your application must have some
configuration stuff that allows it to swith from "multi-files mode" to "mono-file mode".
And to use, in production, only the big file i.e. Single CSS
Result : faster loading pages
maybe this will help you..
For optimal performance it is better to have only one css file.
But for readability it would be better to have different files for different parts.
Take a look at tools like SASS, which help do that without sacrifice performance. Additionally it has features to make your files even more readable by introducing variables, function and much more.
Using more files means more requests. It will take more time to load and make unnecessary requests to the server. I'd stay with one file.
The only good reason to have other css files would be if you have third-party components, to keep them separated and be able to update them easily.
The order matters: Rules loaded later will override rules with the same name loaded before (this is valid even for rules in the same file).
What do you mean that your website uses one CSS file? Normally you'd write your style definitions in multiple files, and they are concatenated (or not) into one file. My point is, what you are working on in your development environment should stay modular, readable, it shouldn't be influenced by what you have in production.
As for the order of the CSS files, yes, it matters, as you can overwrite your previous definitions.
For optimal caching I'd recommend you to build all the vendor CSS in one file, and your CSS in another file, versioned, so that if you change something in your code, only that file has to be updated by the browser.
But these things depend on the infrastructure. As the browsers are able now to send multiple requests simultaneously, having multiple files can lead to faster page load than only one. But I'm not sure about this.
you might want to take a look at gulp to automatically optimize, and minify your CSS code.
All css in one file is OK.
But it's free : you can make as many css file as you want.
However usually this is how it is:
1 global css file for the entire page. You put the common css in here that is useful for every page on your site. You can call it app.css or style.css or mywebsite.css or any name you want.
1 specific css file for a specific page when you want to specially separate this css from the global css file. Because it will contains css only useful for a few pages. For example you have a special component made by your own or a special functionnality. Example : you have made a spcial javascript code working with some html for uploading some file and you want to have your code js/css separate.
Usually, you can also have one css page for each page, but always one global css file for the entire site.
Note : Same question is also valid for javascript
Note 2 : You can also think about using a framework to minify your javascript and css into one single css / js file at the end. At work our technical boss use wro4j which works for java but it should exists many more other frameworks as you can search on google.

The easiest way to get css file based on urls to less files in Windows

I'm curious what's the easiest way to build total.css based on total.less file that contains list of another imported .less files.
P.S. there are many less files with complicated structure so online tool to get the css file is not a choice in our case.
In my opinion, the easiest way to compile LESS into CSS is using the LESS.app for mac. Alternatively, the Offical Documentation for Less has a number of other tools you can use, such as the NPM command line utility.
If you wanted to compile LESS in your browser, you could also set up less.js for compiling LESS to CSS on the client-side. (However, I only recommend this for development)

How do you use LESS with BlogEngine.net?

The LESS docs here
http://lesscss.org/#usage
say: "Make sure you include your stylesheets before the script."
However, BlogEngine.net seems to make that impossible by rewriting all the links to *.js file and putting them before the style sheets.
I've tried everything I can think of including putting the files in a subdirectory and using a relative path. I'm very hesitant to mess with the BlogEngine.Net code.
Is there any way to get LESS to work with CSS in BlogEngine.Net? Any way to force the engine to allow me to order the Javascript entry after the *.less reference?
Perhaps you could use the Tracking Script or the "Add custom code to the HTML head section" fields (you can find them in Admin -> Settings -> Custom code).
From what I can see in the code, these fields are rendered in the HEAD section after the stylesheets.
Is there any way to get LESS to work with CSS in BlogEngine.Net?
If you are willing to consider a different approach than using the client side less parser than I recommend trying the design time less parser in either Visual Studio 2012.2 or The Web Essentials Extension in Prior releases of Visual Studio 2012. It allows you to write your less file and have it compiled to css and minified css every time you save. Then you can just reference the output min.css file in your theme.

Best practice for working with less, or minified CSS

I'm considering using less in an upcoming project but have been trying to figure out the best way to work with it while in development.
Usually when developing a site I'll write my html and css then start testing it in the browser, see how it looks, refine, reload, and repeat the whole process until I'm happy with how everything looks.
A crucial part of the process is using the Inspect Element feature in the browser to identify the piece of CSS I need to change. Usually just by looking at the line number I know exactly where to go in my CSS file.
But if I use Less (or any other method of combining/compressing my CSS) it makes the line numbers useless. I know I could use Find to search for the section of code but line numbers are much faster.
This is especially true when working on a project that involves other developers or large CSS files.
I just wondered how others deal with this, or maybe there's a better process?
Minified CSS really should only be going out to the production version of your site. When you're performing tests/changes etc, this should all be done in some test or development version of your site in a secondary server area where you can have the line-numbers version of css available. The same would go for JavaScript. On the production viewable copy, you want it minified. In development, you don't.
In any event, you should always have 2 copies of your css. The first copy is the primary source copy that is your development copy. It has all of your properly formatted styles with line-breaks in it. The other is the very latest minified version of your css that went to production. This will allow you to switch between the 2 files rapidly in the event that you need to work something out, assuming your site uses some sort of templated delivery (layout pages, master pages, or whatever).
The minified version will only be useful in the final delivery. All other needs should use the master copy. It might not be a bad idea to put a configuration in server-side portion of your site that determines what style sheet to use. That way you can simply change a configuration setting and go into a "debug" mode.
I agree with Joel - that's how I handle it. A build script minifies the CSS (and JS) before each release is FTP'ed to production. I just have a switch in PHP like:
if ($config->prod()) {
// incldue the minfied css
} else {
// include all the original files
}
Personnaly, I use an ant build script to make a production version:
it "condense" multiple css files in one
then it minify them with YUI compressor
same for scripts
(page recomposition to point to the newly generated files)
this way you divide your http request for those files, and gain some bandwith from 30% to 70% i'd say. depends on gzip also.
in my case, the dev version have:
18 css weighting 178ko
reduced down to 1 css at 96ko in the production version
I personally use tools to minify and inject the CSS into the browser each time i save my Less file. So i see each change immediately. This way it's pretty clear what just happened. I don't need the referencing line numbers that much any more.
I recently started using source maps, to see the correct file and line numbers (of my less files) when inspecting CSS in the browser again. I think that is what you are looking for. I personally don't need this extra fanciness that much.

Resources