I'm developing a web app using python and twitter-bootstrap, and my CSS would really benefit from using LESS in order to generate my styles and themes. I want to inherit from classes provided by bootstrap, which means I've got to get the bootstrap source, and compile my LESS stylesheets against the boostrap .less files.
My question is two-fold:
1) The simplest way it seems to use LESS is not to actually compile stylesheets "on-the-fly" but to have a build step that I run each time I make changes to the styles. Is this typical? It seems like a lot of people run LESS dynamically in their server process, but it's an extra headache that I probably don't need, and I don't want to run less on the client side.
2) Thanks to LESS, my project now depends not just on bootstrap, but the bootstrap "source" - What's the best way to handle this in terms of my project management? I don't want to just absorb the whole of whatever the current version of bootstrap is into my git repos, because it seems like it would be a hassle to update it as newer versions of bootstrap come out (also feels icky!) Still though, I need to have at least the minified js/css in my project tree in order to deploy my app. How do people typically handle dependencies like this when developing web apps?
There are a couple of shoices:
You could use less.js in development, so you don't have to
compile each time you change your less code. You just use *.less files instead of *.css
You could use any of the GUI tools that will automatically recompile less code. I prefer LESS.app.
I use git submodule
I would have linked you to the same post as Pavlo above. Maybe there is no best CLEAN practice for this? Neither there is any magic "package manager" i think.
I went updates BS once and it was a bit of a hassle to find out all the variable names that have been changed in the LESS files.
Related
I'm thinking about changing the processCSS gulp task that Aurelia CLI creates to create physical css files, instead of including it directly in the app-bundle.
Are there any major drawbacks within the Aurelia framework to doing this?
I'm more comfortable with separate css files after preprocessing, but I don't want to do it if I'd be missing out on some performance benefits, or create other troubles down the road.
I don't think there's any major drawback that can't be reasonably overcome. However, I would try to evaluate the benefit of doing it your way, instead of bundling it together.
I'll list a couple of points I can think of, in no particular order.
It can be challenging to get the modules and paths set up correctly if you are requiring CSS from standalone CSS modules. If you are using plain CSS files, then you will need to included and maintain the Link tags in your host HTML page. All this is easier if the CSS is bundled directly into the app bundle. Especially when adding more CSS due to 3rd party libraries etc.
if you are using the organizational pattern where you create css-per-component instead of having one monolithic CSS file, then there are potential performance impacts to making http requests for each individual css file, although the impact is probably more thoeretical than practical.
when deploying, it is really nice to just deploy a minimum number of files.
when all css is bundled, you can add comments at top of each CSS source file to help identify the source file when looking at the CSS in the browser inspector.
One last thing, it may be worth your time to experiment loading the CSS in different ways, including as individual files and see which way works best for your environment.
I have a lot of legacy CSS files from what was a Rails 2.x app that got upgraded to Rails 3.2.8, and I want to switch over to using the Rails asset pipeline for stylesheets. The issue is, the CSS stuff is messy in terms of huge lines of code, duplicate file names, and unorganized folder structure.
After looking through individual pages, and trying to add individual stylesheets and folders into the asset pipeline and spending some cycles debugging, I realized there's probably a better approach.
Is there a way to test to make sure the old CSS matches up with the asset pipeline CSS? What are some good tools for testing and debugging CSS?
that is actually a pretty good question. i just know of one tool called wraith that takes screenshots of your page and compares diffs them. that allows for regression testing of your design. you will need to have a test for every page though.
if you look into your browser you also have the possibility to see which css selectors are not used. you could start by deleting the styles that are not used throughout your page.
i think that you will have to take the bitter pill and refactor your css bit by bit. sass and scss might help you with that.
at some point it might be better to start of with a clean slate though. just start with one page and create the css from scratch. at least you know how it has to look like...
I'm in a similar situation with a large legacy application. While I haven't made the transtion yet, here are the steps I'm anticipating:
Upgrade to latest Rails 3.2.x with asset pipeline disabled (done but still testing now)
Upgrade to latest Rails 4.x (because asset pipeline changed between versions)
Divide my css pages between those that apply to every page, and those that are page specific. For the asset pipeline, include ONLY those that apply to every page, and activate the pipeline.
Over time, rewrite the CSS so that page specific rules can be included in the global rules, until everything is in the first category.
I'm seeing advantages in upgrading to rails 3.2 that have nothing to do with the asset pipeline, so that's a win. I have a number of CSS and JS files that do (or could) get loaded on every page without conflicts, so getting to that stage should be some improvement. Transitioning the remaining stylesheets can be done over time and hopefully in a safe way.
Hope this helps. I look forward to seeing any other answers from people that have made this sort of transition on a less-than-trivial web application.
I'm new to SASS and Compass. I want to know if it's pragmatic to use them when modifying (heavily) existing CSS templates. If so, is there any markup I can apply to the existing CSS files to make them SASS/Compass friendly?
Thanks!
You have to remember that valid css could be used unmodified in .sass files, meaning that you could make your existing styles into sass files and optimize on your own schedule!
I'd suggest converting repeated values into variables first, than moving to replacing repeating code with mixins etc.
If you're using version control for the project (which I hope you are), I'd strongly advise you against making changes to styles and refactoring their structure in a single transaction. Ideally any heavy reorganizing (purely in terms of sectioning etc. or massive reformatting of indentation) would be done on its own, with future changes individually tracked. This would allow you to clearly see individual changes and regressions introduced by them if any, allowing for a more sane workflow.
On an unrelated note - if you're, for better or for worse, using Visual Studio, I'd highly recommend using a WebWorkbench plugin which takes care of sass->css compilation locally.
I understand what Less offers me with CSS and I also looked at the twitter bootstrap product. But can someone explain how these compare to Compass and SASS. I really only understand what SASS is right now. How about Compass, what does that do for me.
I'm working on a Windows platform with ASP MVC3(4). Can I use Compass and SASS on that platform also?
SASS and LESS are basically the same; the ability to use variables and mixins etc, and then compile that to normal css.
Twitter Bootstrap is a css framework (including some javascript plugins) with all kinds of different styles to get you up and running quickly by defining grids, typography etc. It does offer some LESS files, but that has nothing to do with LESS itself.
Compass is more of a framework that kind of combines the above. It uses SASS with a lot more helper functions than what SASS and LESS offer themselves. It also includes a similar css framework to Twitter Bootstrap named Blueprint.
With tons of functions, I'm definately going to be using Compass for all my upcoming projects.
It's also very well documented! http://compass-style.org/reference/compass/
And about .NET/MVC3 support, take a look here: http://thedevstop.wordpress.com/2012/01/08/integrating-the-compass-css-framework-into-visual-studio/
I haven't tried it myself yet, but it seems like the best solution I've seen so far.
TL;DR
I'd say Compass is the way to go!
Twitter's Bootstrap framework is quite popular and is based on LESS. I checked its github repo, and it appears to have at least twice the activity of that of Compass, and more people favoriting the project. Just something to be aware of, you'll most likely be OK with whatever you pick, both seem very solid.
What are the best ways to use LESS for CSS.
Basically should the Devs write a Less File and then have it compile for production
Should I link the LESS code and the javascript file.
Or should I skip the LESS rout altogether and just remake the classes
I am trying to wrangle together some rather sloppy css and want to get control of it before making major improvements. I think it would be very good to have site wide variable so Less seems like a good thing with the variables and nesting.
I am replacing a lot of the background images with css gradients and box shadows so I am also trying to get rid of the vendor prefixes.
Sometimes I see what kindof looks like class overload but is it bad to append a lot of classes to an element such as
<div class="comment dark-shadow round-corners"></div>
Less is a great styling language. I use it extensively, and it really helps with code maintainability, as well as with speed of writing the styles.
I personally feel that your styles should not be dependent on javascript to render, so I use the less.app to compile all my LESS into CSS. I rest more peacefully knowing that all my CSS is there and that it works correctly before I put anything "live".
If you are interested I have also been compiling a LESS mixin library that can be very useful: https://github.com/jdmiller82/-lessins-
I agree with Jonathan, I don't think you should depend on the users browser to render the styles.
I came up with a solution that uses node.js on the server to intercept requests like styles.css and try to find the equivalent .less file (in this case styles.less) and parse it and return it as CSS.
So on your server you would just have styles.less but you could request the URL example.com/styles.css and get the parsed LESS file. That way the integration is seamless for the rest of your application and it doesn't require the user has JavaScript enabled either.
You don't have to be using node.js for the rest of your app either. I did this in a PHP application.
You can read my tutorial here: http://programming-perils.com/155/parse-less-files-on-the-fly-and-serve-them-as-css/
I realize this answer is about two years later than the above ones but I think the question is still relevant.
I think there are use cases where compiling some LESS client side is a good idea (provided you aren't supporting IE 8 or below) and you have a use case that validates it. For example, an application I've worked on recently has a customizable, theme-able interface where text colors, etc need to be modified based on whether the background color they're on is light or dark and may eventually need to support the ability for the user to change them and see those changes reflected on the site in realtime. This is a great use case for client side LESS I think. Note that only a small LESS stylesheet is compiled and the rest of the application LESS that's not related to theming is precompiled. I haven't seen much of a perceived difference in performance.
So when you see comments like "you don't seriously think any decent developer uses less clientside do you?", I'd take them with a grain of salt.
The way to use LESS for a production website is to compile LESS files into CSS files.
For local development you can have a file-watcher that rebuilds the CSS files for LESS files that were changed.
If you have multiple CSS files to produce from LESS, you should separate them out.
For example, if you have 30 less files and they produce two CSS files a.css and b.css, you will want to separate those two jobs so that you can compile faster. It's faster for developing because you will only compile a.css if you change any LESS files that affect it.