For my website, I'm considering using Less.
Can I have some problem of compatibility in browser, problem with JavaScript or other problems? I know that is better than CSS but I don't know if I can have problems.
Although I prefer SASS over LESS (better syntax [loops and control structures] and it has some more capabilities => my opinion), it's generally a good idea to use a CSS-Framework. It safes time and unneccesary work. Just be sure to precompile your styles in Production mode. Don't do it clientside (might cause problems: disabled javascript, performance-issues...). If you precompile the CSS, you don't have to fear any problems, since native CSS gets delivered to the browser.
You can take a look at a good comparison here:
https://gist.github.com/820035
from the LESS docs:
As an extension to CSS, LESS is not only backwards compatible with CSS, but the extra features it adds use existing CSS syntax. [...] if in doubt, lets you fall back to CSS.
The best approach in production is to server-side compile it, while in development you can simply use the client-side javascript compiler:
http://lesscss.org/#-client-side-usage
also note that LESS is not strictly a framework (opposite of what Twitter Bootstrap is) but can easily be paired to one. Bootstrap itself has a LESS-enhanced version as well.
I agree with #Christoph. I prefer SASS too. Also Less or Sass aren't used to browser compatibility. They are used to add functionality to css.
You can look at that article here.
http://nittygrittyjs.com/blog/why-less-is-a-pain-in-the-sass/
Related
I am going through the code school course "Sass Foundation". I am on a level where the professor tells about the compass framework.
When I installed it I realized that the code which it generates does not include the -ms- and -o-.
That is why I would like to ask professionals for some tips, and information which I cannot find here on Stack and on the Internet.
Is the Compass dead now? If yes what should I use instead of it?
(to be sure that it will add -ms-, -o- etc.)
Is the Sass dead now?
I did some research and the people say that I should not use the .sass but .scss, but on the other hand, if I use the .scss I won't be able to use the indented syntax. Should I avoid the indented syntax? If yes please specify why.
Since none of the answers are 100% accurate, I will provide my own answer.
Is Compass dead? Yes, apparently. According to their GitHub page:
Compass is no longer actively maintained.
Compass seems to be dying because it is written in Ruby and there are much faster Sass transpilers written in C/C++, mainly LibSass.
What should you use now? Based on this GitHub issue conversation, I would recommend switching to Bourbon for a base set of utility mixins.
Is Sass dead now? No, absolutely not. Modern Sass transpilers, including LibSass, fully support the Sass specification and work great.
Should you avoid the Sass syntax? No. In my opinion, the Sass syntax is cleaner, easier to read, and is definitely easier to type.
You can mix Sass and SCSS syntax. So you can import Bourbon SCSS syntax into your Sass syntax document and use the mixins without issue.
In conclusion, use the syntax that makes you happier.
Compass is not, dead - it did what it did well - but it's now been replaced in most peoples' work flows. People started using CodeKit shortly after that- and now they generally use task runners and build tools like, grunt, gulp, brunch, broccoli etc.
What you want is pre-processing and something that has autoprefixer. This could be any of the things mentioned above and can usually be installed and configured with a collection of npm modules. It all depends on the project you're working on. I'd say that gulp is the most popular right now. (I use Ember, so Ember CLI does that for me)
.sass is just another syntax (the original one, I believe). Most developers use .scss and I'd encourage you to stick with that syntax because it's more like CSS and when sharing projects people will thank you. (although I prefer stylus)
EDIT
Afterthoughts... I'd say that "Sass Foundation" is what is dead. That course is going to cause you more trouble then help you. Just write scss and learn new bits as you need them. It's just CSS with some helpful features like variables and nesting.
Assuming I'm understanding what you're asking, yes, I would transition to SCSS instead of using SASS. Why? Generally speaking, SASS combines both Sass and SCSS. Sass itself is an older syntax that primarily deals with indentation (instead of brackets, etc.) and doesn't present any real addition to CSS. On the other hand, SCSS is meant to extend CSS3 by providing additional functionality such as variables, nesting, and others. The other bonus is that technically speaking, every valid CSS3 stylesheet is also a valid SCSS stylesheet.
So to conclude, I would definitely consider making the change to SCSS as you will find this is the standard among a lot of frameworks and tools used in the industry, plus it is a newer syntax in comparison to Sass and provides a good deal more functionality to make your life that much easier as a developer.
If you want to find out more information, just take a look at their website: http://sass-lang.com/
So to answer your questions specifically:
No, it is not dead, it has just been updated to follow industry standards. There are many alternatives available. For example, a popular one is Gulp.
Sass isn't dead either, however most developers have moved to SCSS instead.
I would go with SCSS, due to what I have described above.
On developing frontend-stuff in scss and html5 I have some routines that I rely on like display:inline-block, rgba, css-gradients and so on.
Now dependent on which project I have, browser demands change. I sometimes need to deliver something workable for IE7 and sometimes IE10 is alright too.
Of course I can (and do) real browser checks to check issues, but I thought having a routine upfrontal check wouldn't hurt. So I could run a search within my scss-files to check for the pattern "rgba" and replace it with something appropriate. But that doesn't sound neither very reliable nor modern to me.
Isn't there a way to generate a special set of pattern-fixes for each browser > run it > highlight it to me (or even better already fix it)
Would grunt/gulp be the topic I need to investigate therefore further?
Thanks
As deolectrix said you could look into compass, there is also bourbon, and less. Using grunt/gulp would be highly recommended. For many reasons like concating/minifying your code, or if you write JS you can use something like babel to write ES6 JavaScript.
For cross-browser css autoprefixer would probably help you out. For errors/warnings about troublesome css look into csslint. Hope that helps! It's just a starting point, enjoy diving in.
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.
Yesterday I asked a question here that got more momentum that what I thought it would. Here is the question link since it is related. I am interested now in the possibility of that using two frameworks together will be worst than using a JS framework and CSS from scratch or the other way around.
The question is clear, if you think there are arguments against using a CSS framework like Blueprint CSS please tell me what you think they are.
The main argument is that CSS is not really a programming language. A framework is meant to include reusable functions and data structures. CSS has neither of these constructs. A CSS "framework" is more akin to a template in a word processor. It provides ready-done design work, but it also imposes more constraints than starting from a blank slate.
Incidentally, this was what drove the development of Compass. It's similar to a CSS framework, but instead it uses the CSS metalanguage Sass, which does have functions and variables. Thus rather than (for example) having columns baked into the framework, you can write something like +columns(5) +column-margins(1em) and it will generate the appropriate CSS.
Browser compatibility? We're continually struggling to maintain IE6 support for the 1/3 of our clients that cannot or will not upgrade. Lots of CSS issues.
I use the YUI CSS libraries, but I'm not sure if that counts as a framework.
YUI handles the basics for fonts, layout (grids) and other formatting and makes it consistent across browsers and Operating Systems. It's under a free software license, also.
They also have a very useful interactive grid designer.
Is there anything that CSS Frameworks give that its not easy to make yourself?
The main use I have for CSS frameworks is that they tend to force you to think about how you're going to organise you code rather than provide you with indispensable tools for your day to day tasks.
For that reason, I'm a fan of boilerplate rather than things like blueprint as boilerplate tends to focus on how you structure your css stylesheets and imports rather than providing you with a collection of semantically confusing helper classes.
They are simply a convenience and as such are good for things like wireframing and rapid prototyping. They are probably also a good way to learn CSS layout aswell if you can familiarise yourself with the layout code.
What I don't like about CSS frameworks is that they encourage the use of non-semantic class names and are a bit heavy handed for a simpler designs. I still think it's very important to understand how CSS layout works and not to just rely on the frameworks because you'd be limiting your creativity and what you could achieve. Sometimes reading CSS files from the csszengarden site can teach you things you weren't sure of how to achieve.
For wireframing this is the most promising CSS framework I've seen:
http://designinfluences.com/fluid960gs/
I think that all depends on your own knowledge and the project. If you have a lot of small business clients, or for other reasons makes a lot of similar designs, I think it saves some time to use css frameworks. And you save time for browser bugfixing, but you should always test anyways.
But if your CSS skills are good, you know the most common IE bugs and how to hack them, I dont see any need of using a framework in most cases.
A reset stylesheet of some description is a worthwhile starting point.
For example:
http://developer.yahoo.com/yui/reset/
IE6 compatibility.
given that you are already familiar with one particular framework, it's easier and quicker to do certain common grid layouts. You might want to learn and try to stick with a framework if you are doing a lot of CSS.
Blueprint CSS is the CSS framework I prefer.
Yes, testing testing and more testing. Do you have time to test and debug your code in all browsers? If you have it's the best to write your own code. If you need quick solution you can use some framework. I wrote one post about this subject: http://www.vcarrer.com/2008/08/when-to-use-css-framework.html
It depends on the framework and your end-goal.
A lot of times they can work as guides with pre-defined templates to aid your development effort. But other times you just want your page to look nicer and not have to deal with actual work on CSS files. In the latter, you can skip the "make yourself" part altogether, and invest more effort into other parts of your project.
Take Skeleton and Tacit CSS frameworks for example. Both are pretty much minimal frameworks. The first is more centered on providing easy to use and adapt the boilerplate code and comes with a moderate amount of utility. Tacit on the other hand is a CSS framework for dummies, for people who, for example, have no interest in working with CSS but still want to get a nicer display look than the default CSS-less HTML display, and they want this out-of-the-box, not having to work with CSS classes.
i think that compatibility of any kind is best achieved when we band together, whether it be using CSS or Javascript frameworks, there's bound to be more chance that bugs will get fixed and wishes will get granted. there's also the chance that similar interfaces reduce the amount of training required for new users of your site.
I would never, ever use a CSS framework. They don't make anything faster or easier, increase code bloat and make debugging or testing much harder. If I do use a CSS framework to start with, it looks like this:
body {}
In what way would you ever need more than that? the baseline starting point should always be what the browser displays by default, nothing more.
Reset CSS stylesheets cause the same problems.
eg: http://withoutsubstance.blogspot.com/2008/09/why-you-should-never-ever-ever-use.html
I've worked with 960 a bit and found it's great for prototyping but I'm not a fan of putting it into production. I find the use of float makes my head hurt a little.
There's a common misconception that frameworks == bloat and another that a particular implementation of a framework represents the definition. A framework is just a tool. Here's an analogy: If you need a spanner to fix your car, you shouldn't throw away your screwdriver set.
If you've found that the frameworks you've looked at aren't suitable to the task at hand, you shouldn't write them off. You can easily make your own or use frameworks when they suit your needs.