I have an existing Django project which uses regular CSS. The style sheets are broken up by functionality, so there is a nav.css, course.css, default.css, reset.css, etc. All of these are imported in a main.css, which is referenced from the html pages.
I would like to use Compass in this project so I can make the style sheets more manageable and also make it easy to skin the UI.
Before checking out Compass, I looked into Sass, and created .scss files for all my style sheets.
Now I realize that it may be better to use Compass than just Sass, because I will get all the default styles that come with it. However, I am a bit confused about how to start the refactoring process.
What would be the right process to refactor (in baby steps) an existing project which already has its styles defined, to get it to use Compass?
Much of the refactoring work is the same with or without Compass and you'll see the benefits that Sass offers sooner than those of Compass.
Compass creator Chris Eppstein did a write-up of how he went about refactoring digg's CSS. To sum up:
Extract partials. You're well on your way with this one, since you already have separate stylesheets for different functionality. Go further and pull out independent sets of rules to make them easier to manage and break down the refactoring project into smaller steps.
Analyze styles. Look for repeating patterns and inheritance relationships in your new partials. Wherever you have selector duplication could be a good place to start the next step.
Extract base classes. This is where you DRY up your CSS with #extend. Pull out duplicated declarations into a base class and extend.
Apply nesting. Nesting is a great Sass feature to make your stylesheets easier to read.
Extract mixin. If you found common styling patterns in step 2, this is the time to extract them into mixins.
Now you can really start taking advantage of Compass and its reusable patterns. Familiarity with the Compass documentation will help to identify which of the mixins are applicable to your project.
Related
I'm using CSS Modules (Sass) with rollup on a component library project, which is working well. Each component ends up with a dist folder containing a single JS bundle file, and a corresponding CSS file with the scoped CSS classes so consumers of the component don't have to worry about CSS class name conflicts. All they do is include the JS bundle and the CSS file and everything is great. Yay CSS Modules.
The problem I'm now facing is that some components really need separate "themes" - ideally, separate CSS files, one per theme. So consumers can continue as they've been doing: including the JS bundle, but now choosing which CSS file to include to pick a theme.
I'm not sure how to get this going with CSS modules & rollup, and whether this is even the sort of approach others are taking. From what I can see, rollup always handles bundling things together, whereas I want separate CSS files, all of which get their classes renamed identically during the build phase. That way, if within my JS I refer to styles.myclass, if myclass had gotten renamed to scoped-myclass by CSS modules for the original CSS file, for a second CSS file it would also get the same name.
This would keep consumption of the component extremely simple - just a matter of including a different CSS file.
Any suggestions?
Awfully late, but let me answer this 3 years on. So what I ended up doing was totally detaching the CSS generation step from rollup and relying on the Sass CLI to handle that portion of the build process. It felt a bit klutzy, but I remember it wasn't awfully hard to do and solved the problem I outlined above. I don't believe there was a plain rollup solution at the time, nor do I think there's one today.
However... in my case the whole approach was kinda mistaken. This certainly won't be everyone's scenario, but let me spell it all out because hey it may be useful and it definitely wasn't obvious to me at the time.
This was for an in-house shared component library, where each component and its corresponding CSS was a separate npm package stored in our Artifactory. When it grew, plenty of internal references popped up, e.g. multiple components would reference the Button component, and over time they'd reference different versions of the Buttons component - each of which needed its own properly scoped CSS, unique to that package-version.
So what I found was that by doing it this way - having the CSS generated as part of the npm package dist files - I had to write an additional layer for the consumer applications that would parse their node_modules/ folder for our own internal components and combine all the different CSS files, such as the multiple versions of buttons. e.g. the main application would directly import buttons v1.0.0 in its package.json file, but the Dialog component (also included in the package.json) could include buttons 2.0.0 as its own dependency. For every version of the package, there was a uniquely scoped version of the CSS - so the consuming application HAD to include every version otherwise the styling would be borked.
So all in all, it ended up being way more complex that I wanted. I thought I could make it easier & better with the separate generated themed CSS files as part of the package dist, but it didn't end up that way. If I could revisit that project today, I'd re-examine a solution used by Material UI and others which I kinda poo-poo'd at the time: automatic injection of the CSS into the page by the component JS, rather than generating standalone CSS files which required extra work by the consumer applications to gather up and add to the final webpage. Frankly, now I regard it as the "least crap". There are definite downsides to the injection approach (extra work done on every page render for everyone! Yikes!), but there's no doubt in my mind it hugely simplifies the job of the consumer applications. It's a balancing act, but in 20-20 hindsight I'd lean towards the injection approach. With that, scoping & theming is a different and much simpler problem.
If I got you right, consider looking at SCSS plugin: rollup-plugin-scss. It captures all spare .css files imported in the components, and then processes them through underlying node-sass. The catch is, it seems like you can write a custom callback function that'd handle your CSSs differently based on conditions you throw in.
Based on the example from the plugin's page:
import scss from 'rollup-plugin-scss'
...
export default {
input: 'src/index.tsx',
output: [...],
plugins: [
...
output: function (styles, styleNodes) {
// replace this with conditioned outputs as needed:
writeFileSync('bundle1.css', styles)
writeFileSync('bundle2.css', styles)
},
]
}
I'm trying to sift through all the CSS options / packages available for EmberJS and am looking for suggestions. I suppose it will help if I list what I need:
SASS syntax (variables, nesting, creating mixins, and extending)
Ability to import other CSS libraries
Pod support (although I'm not positive I'll be using this feature at the moment, but I at least want to be able to have one CSS per route/component)
Autoprefixer
Is there an all-in-one Ember package that will give me all these? Thanks!
SASS syntax (variables, nesting, creating mixins, and extending)
You should think long and hard before taking the blue SASS pill. SASS is a technology trending towards obsolescence, which was designed mainly to support some bad CSS coding practices, as well as overcome some deficiencies in earlier versions of CSS.
Variables are supported by postCSS plugins in a standard way which is compatible with the upcoming CSS variable syntax.
Nesting is an answer in search of a problem. It promotes a bad style of coding involving excessive dependency on HTML structure. Properly constructed systems of CSS classes, orthogonal to HTML, make nesting unnecessary.
With regards to mixins, I have not seen a real-life situation in which mixins or other more advanced SASS features were actually necessary. Using them, you end up learning yet another (weird) programming language, which you have to debug, and make sure all the people on your team know.
When it comes to extending, CSS experts counsel against it. Besides potential issues of performance and code size, they hide the logic of the CSS code, and require jumping back and forth from file to file to maintain and extend and debug. Everything that is accomplished with extending can be handled with properly-designed CSS classes.
SASS is slow, is bifurcated (binary version vs. Ruby version), and can give rise to strange npm installation problems. My advice is to avoid it.
There is an interesting read about SASS vs. postCSS here.
Ability to import other CSS libraries
Ability to import other CSS libraries is not a function of any other decision you make, or what package you choose. You can simply import these.
Pod support (although I'm not positive I'll be using this feature at the moment, but I at least want to be able to have one CSS per route/component)
Indeed. There is at least one new-ish Ember add-on to do this (and probably more), which IMHO is designed extremely poorly and grossly over-engineered. It follows the Ember approach of doing way too much, in an opaque way, in the name of being "helpful" (until it isn't, at which point you're screwed). This is great if you want your CSS to be littered with classes like .my-component-a34fba.
Until there is a better alternative, I'd do this manually, which is quite easy. Simply place your CSS files in the pod, and then import, from your styles/app.css or equivalent file, the CSS files from the pods you want, such as #import '../pods/thingie/; to import its index.css file. Yes, you will have to do some maintenance of these imports yourself, but how many pods do you have?
What I do to avoid a huge styles/app.css that would require constant updating is to place an index.css file in each pod and import that. From there, import a stylesheet for that directory itself and any necessary subdirectories:
/* styles/app.css */
#import '../app/pods/thingie';
/* app/pods/thingie/index.css */
#import `./style`;
#import `./subdir1';
#import `./subdir2';
Autoprefixer
You need look no further than the excellent postcss/autoprefixer.
Is there an all-in-one Ember package that will give me all these?
It would be nice if all our problems could be handled by all-in-one packages. Unfortunately, all-in-one packages are always missing two features we wanted, and we can never figure out how to add them. They always do one thing we didn't want them to do, and we can never figure how to turn it off. They import old versions of their subpackages. They break when there's an Ember upgrade. They stop being maintained. The Ember philosophy itself sadly promotes this pernicious all-in-one mentality--all my problems can be solved by yet another add-on!
You are better off understanding individual technologies, choosing simple, bounded, reliable implementations of them, and weaving them together yourself. Just my two cents.
This might be the closest thing you're looking for:
https://github.com/ebryn/ember-component-css
Which supports using pods layout, and lets you use ember-cli-sass.
To use auto-prefixing, there are plenty of sass libraries out there to help you out, like Bourbon.io, which you can install via npm. Then, it should just be matter of configuring the import paths via the sass options in the ember-cli-build.js
I recommend PostCSS. Last I checked, it doesn't work out-of-the-box with ember-component-css, but you don't need ember-component-css to namespace your styles.
You can modify Ember's Component generator / blueprint to (assuming you're using pods):
Add classNames: ['component-name-here'], to the generated component.js file.
Create a _component-name-here.css file/partial in app/styles/components (or similar), with a class .component-name-here to contain all styles in the partial.
If necessary, #import that new partial in your app.css.
Then all your Component styles will be namespaced.
To handle variables, nesting and Autoprefixer, you just need to set up PostCSS with the right plugins, e.g.:
plugins: [
{
module: require('postcss-partial-import'),
},
{
module: require('postcss-nested'),
},
{
module: require('postcss-custom-media'),
},
{
module: require('postcss-custom-properties'),
},
{
module: require('autoprefixer'),
options: { browsers: ['last 2 versions'] }
},
],
I'm using ember-cli-css-preprocess, which gives you the option to use SASS as well (alongside PostCSS), if you wish.
I am a pure designer, so I totally new to the field of front-end development.
I have learned what is LESS, what is SASS.
But when I open a HTML template, there are some LESS or SCSS files, but also a lot of CSS files. I am quite confused what's the relationship between LESS/SCSS and CSS?
If LESS/SCSS is so good to use why people still write 10 thousand lines in CSS file, which is impossible for me to read through..?
Are those CSS files like "bootstrap.css" or "animate.min.css" just libraries for LESS/SCSS to use? Or what other relationship between them?
A lot of frameworks ship with not only the LESS and SASS files, but also the results of those files (the exported CSS files). In the case of Bootstrap, this is particularly true: none of the ".css" files are libraries for the LESS. They are the result.
The authors of these frameworks assume that some people want the LESS/SASS workflow, and others want to include the CSS and be done with it. So they include it all. In many cases, the ill-documented sprawling CSS files are actually demonstrating that the assumption about LESS ("so good to use") is not always true. Writing CSS without a preprocessor and with best practices will more often result in a smaller more readable (and well-documented) file than a LESS/SASS-based workflow.
Having spent some time with LESS, I think I might be ready to move back to straight-up CSS.
After browsing css templates in html5up.net, I am really curious as to how design sites/companies produce all their templates. With the amount they churn out, they would surely have to have some sort of efficient system. At first I was thinking that experienced designers might have a combination of coding by hand and copy/pasting large chunks from old templates to new ones. Basing new templates loosely off another in this way would yield some sort of speedy production... Then I thought, with how well organized the front end files are, they can't be coded by hand (or at least not most of it) - it would make sense that they are made from programming that generate the templates, sort of like a template for building templates. I would only go so far as to speculate the possibility, but I would like to know how a person churn out the templates like that. If this isn't the case, is it feasible?
This can be accomplished with preprocessed CSS.
At the simplest level, these languages/frameworks can be viewed as allowing substantial amounts of CSS to be output by making changes to core template files- through the use of variables, mixins, nesting and formulaic derivation / inline functions. Once the templates are set up, something like, say a site colour change, can be accomplished by only changing one or two variables.
You may want to look at SASS (wiki, article)
Sass is a scripting language that is interpreted into Cascading Style
Sheets (CSS). SassScript is the scripting language itself. Sass
consists of two syntaxes. The original syntax, called "the indented
syntax" uses a syntax similar to Haml. It uses indentation to
separate code blocks and newline characters to separate rules. The
newer syntax, "SCSS", uses block formatting like that of CSS. It uses
braces to denote code blocks and semicolons to separate lines within a
block. The indented syntax and SCSS files are traditionally given the
extensions .sass and .scss respectively.
There's also LESS (wiki) which works in a similar way.
LESS (Leaner CSS) is a dynamic stylesheet language designed by Alexis
Sellier. It is influenced by Sass and has influenced the newer "SCSS"
syntax of Sass, which adapted its CSS-like block formatting syntax.
LESS is open-source. Its first version was written in Ruby, however in
the later versions, use of Ruby has been deprecated and replaced by
JavaScript. The indented syntax of LESS is a nested metalanguage, as
valid CSS is valid LESS code with the same semantics. LESS provides
the following mechanisms: variables, nesting, mixins, operators and
functions; the main difference between LESS and other CSS precompilers
being that LESS allows real-time compilation via LESS.js by the
browser. LESS can run on the client-side and server-side, or
can be compiled into plain CSS.
Finally there's stylus (wiki)
Stylus is a dynamic stylesheet language designed influenced by Sass
and LESS. It's regarded as the third most used CSS preprocessor
syntax.
Is there a CSS minifier tool that can resolve #import statements?
I'd like to be able to load multiple CSS files on my local machine but have them all resolved into one file when the website gets pushed out into production.
I recently started using LESS, beyond imports allows you to use:
Variables
Mixins
Parametric Mixins
Nested rules
Operations
Color functions
Namespaces
Scope
Comments
Escaping
So far I'm glad with my experience using LESS.
It's easy to use and the page is documented with good examples.
You can use SASS, with the SCSS syntax. SASS is much more than a minifier: it is actually a CSS preprocessor which adds some goodies like variables or macros to the CSS syntax. But you can choose to simply ignore these features (although I advise you to have a look): any valid CSS file is actually valid SCSS.
SASS can then compile your SCSS in valid CSS, and it can manage multiple files and output a single minified .css file.
You can try it just as a minification tool for now, and start using the advanced features when you feel like experimenting.
css-compressor (based on yuicompressor) inlines #import statements - in fact that is its primary purpose:
https://github.com/samilyak/css-compressor
Granule library supports #import in CSS.
You can look it here http://code.google.com/p/granule/