When you're in flow, it's hard to stop yourself and make sure all the css properties you are using have the right compliance.
Is there a way to analyze css files, and see where I could have used compass mixins to maximize browser compatibility?
SassMeister is a playground that specializes only in Sass-related stuff.
http://sassmeister.com/
Of course, SassMeister lets you choose the syntax you feel more comfortable with and you even can choose the output style (expanded, compressed, and so on). Most importantly, because SassMeister is specific to Sass, it allows you to import Sass libraries (Compass extensions actually). You can even propose your own extensions if you think they should be added.
Related
I'm a full stack developer that uses sass (.scss) for styling. However, my backend crew, when they have to make front end changes, use css because they are comfortable with it.
I have to convert the css to scss every time manually or else I will overwrite their changes. Is there a way to update my scss file to pull in css changes automatically?
My IDE is PhpStorm (if that helps anybody)
SASS version 3.4.24
I don't see a plugin for PHPStorm to do that; you might have to make one yourself. But even if you do, the SCSS it'd produce probably wouldn't be much better than the CSS you already have. It's silly to convert to SCSS only to compile back to CSS. The whole point of SCSS is so that you don't have to write CSS.
You could convert the CSS to SCSS with sites like this one. Again, results will probably not be much better than if you just kept it CSS.
My solution would be to split the CSS file. One part would be for the stubborn devs, while the other one is the CSS compiled from the SCSS you like to use. So, they can work in CSS, and you can work in SCSS.
You probably need a workplace solution before a technical one.
We currently use SASS to pre-compile CSS which consists of various SCSS files.
How does one remove the implementation of SASS so that CSS files are managed directly?
As a side question, is using SASS just personal preference or is it best practice for smallish projects? Why would I want to work in several files when I can just work out of one in a syntax that I'm familiar with?
Cheers
Just remove the sourceMappingURL in your main css will do.
You can also, should you wish, reconstruct traditional CSS by looking at what was being accomplished in the SASS files and rebuilding from scratch. This is cleaner than beginning with the compiled CSS ... but it is not for the faint-hearted: it's kind of like picking out stitches. But if the number of SASS files is few, you'll be better off.
CSS preprocessors (sass/less) were always a solution in search of a problem, in my opinion. They were likely designed by developers who were given sloppy CSS from designers who may not have had good coding practices - but in general, there is very little reason for them, and they add one more bit of unnecessary tooling. I've used them, don't like them, and will never use them again. Totally unnecessary. Good structure in one's CSS will always win.
Using sass helps you organize your code in a better way. And ease the development by using nested selectors and using mixins,variables and much more which you code once and re-use many times.
One will simply go to concerned file and change the contents easily if it divided to multiple meaningful files.
And coming to your question, you can move away from sass very simply. Generate a css file once and from next time onwards start coding in your css local copy rather than extending your sass files again . :)
If you just want to move away from SASS to return to the pure CSS, you have to use the compiled stylesheet. If you compile it via command line, then you would have got the compiled CSS. Anyway, you can use an online tool to compile it, such as this.
Once a time you have the compiled CSS, you just have to import that rather than the SASS stylesheet you've been including in the HTML previously. Just insert this in your <head>.
<link rel="stylesheet" type="text/css" href="Your pure CSS stylesheet URL">
I know Bootstrap and Foundation are CSS frameworks, but I'm not sure whether LESS and SASS are CSS frameworks or preprocessors.
What is the difference between CSS frameworks and preprocessors?
From http://lesscss.org/:
Less is a CSS pre-processor, meaning that it extends the CSS language,
adding features that allow variables, mixins, functions and many other
techniques that allow you to make CSS that is more maintainable,
themable and extendable.
From http://sass-lang.com/documentation/file.SASS_REFERENCE.html
Sass is an extension of CSS that adds power and elegance to the basic
language. It allows you to use variables, nested rules, mixins, inline
imports, and more, all with a fully CSS-compatible syntax. Sass helps
keep large stylesheets well-organized, and get small stylesheets up
and running quickly, particularly with the help of the Compass style
library.
Basically both are css pre-processors, as in they allow you to write style information that later compiles to css.
Frameworks, like bootstrap, on the other hand are more like pre-made style sheets that can be used to save development time. Rather than writing out custom sheets with similar styles over and over again, you can make use of prefabricated sheets. They usually have things like resets, basic layouts, and/or grid systems built in.
There are also some frameworks written in, and designed to be used with a pre-proccessor like Less Framework 4
If you're relatively new to this stuff, I would recommend starting with plain old css. Pre-processors can be helpful, but the learning curve is a bit steeper.
As said above, LESS and SASS allow CSS to follow the DRY(Don't Repeat Yourself) principles of coding. For example if you had a CSS file where you wanted 12 items let's say; h1, h2, h3, h4, p, a, etc all to have the same color of text(let's say a salmon color), what these preprocessors allow you to do is create a variable(let's say myColor), that you can then pass into the color attribute of each of these items.
This may not sound exciting, but where it really shines is when you want to say redesign the site or alter that color to say a 'sky blue' instead of now skimming through those 3000 lines of code to find those different items (h1, h2, ... , a, etc as listed above) you'd only need to change the myColor variable from the hex/rgb/rgba color code to the one for sky blue. Which in turn would change that value for each of those items.
So essentially you need to change 1 value that's easily found, as opposed to many, which may require a lot of sifting through code.
To note though, LESS and SASS cannot be read by a standard Internet browser, instead you must use a program that compiles your LESS/SASS code into standard CSS (these programs are easy to find and most programs such as Sublime, Brackets, Atom, etc have the functionality built in or allow a package to be downloaded that does it.)
Then when you need to edit your code, you change the LESS/SASS file and recompile again.
That's just the tip of what LESS/SASS can do, but it gives you an idea hopefully of their use. Programmers are lazy, copy and pasting isn't a good option generally, as you violate the DRY principle. So this is a happy medium explained hopefully in laymans terms.
I would have to believe I can accomplish the same results as pre-processors using jQuery(the most popular ui/ux framework).
However, depending on how many people are working on one project it may a case of teams learned in SASS or LESS scripts and may not know jQuery syntax as well. They are only focused on CSS effects, which could be a plus.
If I .addClass() to multiple DOM elements with jQuery... it may be even more efficient than having a preprocessor duplicate desired code all over a css file.
I have a preprocessor import problem. I have vendor css that i would like to copy functionality. Unfortunately, i don't control the html for this situation either.. so essentially i have vendor css & different vendor html, and i am trying to extend functionality of one css rule into another.
Now, the basic concept in many css preprocessors is to extend the rule.
// Vendor
.foo { font-weight: bold; }
.bar { text-color: red; }
// Mine
.bar { .foo }
In the above example, you don't have access to .foo or .bar, but with preprocessors, you can extend functionality from .foo into .bar, which works great for less/stylus/etc. The problem, is when the vendor rules are only defined in raw css.
So with that said, the most obvious solution is to have Stylus/Less import the raw css as stylus/less. However, neither seem to be able to actually do this.. that i've found at least. Less doesn't seem able to (#import "foo.css" directives are ignored) and while Stylus has an option to actually include the imported raw CSS, it did not seem to actually be processing it. That is to say, it would include the css, but #extend directives failed (perhaps i am wrong?).
The other option i could think of is simply renaming the .css files to the preprocessor language extension. Since we want to keep the vendor stuff out of our hands, allowing for proper versioning/etc, This involves a build process which copies the target css files and renames them into the target language extension, but this is error prone. Stylus ran into syntax errors immediately, and Less could just as easily (as not all CSS is valid Less. most is, but not all).
So.. any additional thoughts on this front? Hopefully there is an option i may be missing? Perhaps SCSS handles this better?
Currently, with what i have found is/isn't possible.. i feel the only stable way is to simply copy the raw css bits into my css code. If the vendor code changes, i'll have to update manually, but at least i don't run the risk of vendor stuff changing and all of a sudden the build process fails, because vendor introduced some CSS syntax not supported by less/etc. It is far from good.. but the worst that can happen is my css looks funny, and i need to update.
edit:
I'm going to try SCSS next.. we'll see how it goes. On the site, they claim all CSS(3 only?) syntax is valid SCSS
edit2: For clarity. My question is, give the above scenario, what would you do? Importing the .css files is not possible (See note below!), and renaming .css files to .less/.stylus can in turn be error prone, since less is not a perfect superset of CSS(namely due to proprietary features).
!Note!: I have since been digging around the less source to see what could be done to fix this problem, rather than work around it, and ran into a dozen support tickets on the matter. The main discussion of which seems to be taking place on #issue 1185, and more importantly, check out the changelog which *(i believe) addresses this issue! CHANGELOG 1.4.0 Beta
So with that said, the #import (less) "file.css" is likely the winning scenario here, even if it may have a few bugs due to the beta status. Yay :)
Your best bet is either what #Lee Olayvar said, or use the new ":extend()" feature in LESS. It sounds like you might have tried the extend feature, but you used the "SASS directive" syntax (which IMO is improper use of an at-rule), whereas LESS uses the CSS-like pseudo-selector syntax:
.foo:extend(.bar) {}
And if you are patient (in the coming days/weeks), you will see a new feature that is perfect for what you want to do, and it's unique to LESS. It will allow you to extend or mixin external "silent" styles. Meaning you will be able to "#import" and external stylesheet but the styles won't show up in your compiled code unless you extend them or use them as a mixin.
I'm on the core team for Less.js btw, so let me know if you have any other questions or if I can be of further help.
It looks like all imported .css files won't be prepocessed by less but will just be added with an #import at the top.
You can import both CSS and LESS files. Only LESS files import statements are processed, CSS file import statements are kept as they are. If you want to import a CSS file, and don’t want LESS to process it, just use the .css extension
Source: http://lesscss.org/
The best thing you could do would be the renaming I believe.
While still in beta, the newly added #import (less) "file.css" syntax should properly handle all CSS files. Due to the "official" support, it can also be expected/assumed that any proprietary syntax that breaks LESS would be fixed (though possibly not "supported").
So in theory this is the best option! Barring SCSS, which i have not tried yet in this scenario. Stylus still has issues though, in my tests.
For more information, check out this issue or this changelog.
Is there a structured language for declaring styles in a sensible way, which can then be rendered into browser specific css files, similar to what GWT does to Javascript?
It would ideally be a language that supports variables, deals with browser quirks and differences (e.g. filter:alpha vs opacity), provides an intuitive syntax for common tasks such as centering, and has a way to express fallbacks for less capable browsers.
Sass, as in Haml and Sass has some of what you're looking for.
It has variables, math, and other goodies.
The official version is Ruby based, but there are versions for other languages like PHP and Python.
It might not do EVERTHING you mentioned, but it's worth checking out.
GWT's ability to generate code on the fly and it's powerful "deferred binding" capability could definately be applied to stylesheets and allow for build-time optimization of CSS.
Right now, the "GWT way", according to styles is to include all the styles you'll need and use apply them by making use of "dependent style names". But this definitely leads to lost of useless CSS being included where it's not needed.
I know there is at least one attempt to optimize CSS at build time. This would involve combining multiple seperate stylesheets into one, and removing all non-essential whitespace (minifying). I think this might also allow you to make use of deffrred binding to essentially "optimize out" CSS from where it's not needed (ex: browser specific styles).
StyleInjector
To answer my own question (again): Less seems like one of the most interesting projects so far. CSS extension supporting variables, mixins (complex variables), nested rules, and simple arithmetic.
you might want to try HSS.
Thanks for your comments! Sass and HSS seem very similar in scope: simple and block variables, nested blocks, single line comments. HSS has the advantage of being a superset of CSS.
StyleInjector looks more ambitious and interesting. By leveraging GWT's deferred binding capabilities and introducing CSS syntax extensions like conditionals, this approach should make it easy to define not only browser specific but also locale specific styles. Also being able to reference other GWT resources directly, and automatically minimizing styles by removing and merging selectors is pretty cool. I'll definitely follow this project closely.