Switching from LESS to Sass
At work we currently use the LESS preprocessor to build our CSS framework and have been finding lots of situations where Sass @extend would help us better optimise our outputted CSS. This is a short write up of the pros and cons of each for our context:
Pro neither
- Bootstrap is built on LESS, there is a Sass branch
- The syntax can be easily switched:
- LESS @ is directly equivalent to Sass $
- When writing mixins: LESS .border-radius() {} would become Sass @mixin border-radius() {}
- When using mixins: LESS .border-radius; would become Sass @inlcude border-radius(); OR @extend border-radius();
- Both have a large community
- Both are seeing active development, Sass used to be more active but LESS has recently seen a surge in development
Pro LESS
- With regard contributing to the projects: Sass is built with Ruby and LESS is built with JavaScript. Our JavaScript skills are stronger than our Ruby skills
- As we currently use LESS, no additional work would be required
Pro Sass
- FireSass (Firefox) and Sass Inspector (Chrome) and powerful debugging tools, nothing like these exist for LESS
- Autocompile is a standard feature in Sass, WinLESS can autocompile but has problems with @include
- CSS3 helpers and spriting are built in to Compass
- Sass is seen as the “jQuery of the preprocessor world” by Jonathan Verrecchia, and the community, therefore is probably the better choice for personal development
- @extend can help to optimise our CSS output, massively
- If statements can be used to keep IE hacks in the context of the CSS module, but then pull them out at build time into a seperate CSS file
- Sass has actual logical and looping operators in the language. if/then/else statements, for loops, while loops, and each loops
- Sass has nicer @media support as you can name the breakpoints
Sass FYI
- Putting an underscore before the filename tells Sass not to generate a CSS file
- Scout is a free GUI compiler but it does not support –debug-info, Compass.app does but costs $10. Command line supports it and is free, but its the command line
Resources
Font Icons
Ever since Chris Coyer opened my eyes to the advantages of using fonts for icons, I have been a firm believer that icon fonts are the way forward for creating beautiful resolution independent interfaces.
Recently I have had the opportunity to create an icon set of my own and thought it would be beneficial to document my workflow and the problems have come across.
Workflow
After a brief period of failed experimentation with the font icon generation tool Icomoon, the workflow I recommend is based on that set out by Heydon Pickering.
- Create the icon
My tool of choice for creating the icon is Adobe Illustrator, although any vector application should work just as well. Steps to make your life easier:
- Set all measurements in points
- Use a 1000 point x 1000 point canvas
- Align everything to the grid (point based)
- Create objects using fills and not strokes
- Export the icon as an SVG
- Map the font to characters
I found using Inkscape to be the easier way to map characters in the font to the SVG exported from Illustrator. Again using a 1000 point canvas and exporting the output as an SVG.
- Convert the SVG to TTF
I had no problems using freefontconverter to do this.
- Generate the font-face kit from the TTF
I used Font Squirrel to generate the font-face kit.
- Add the characters and classes to the CSS
You should use an entity conversion chart to work out what CSS content should be generated by the CSS.
@font-face {
font-family: 'Font Icons';
src: url('../fonts/fonticons.eot');
src: url('../fonts/fonticons.eot?#iefix') format('embedded-opentype'),
url('../fonts/fonticons.svg#fonticons') format('svg'),
url('../fonts/fonticons.woff') format('woff'),
url('../fonts/fonticons.ttf') format('truetype');
font-weight: normal;
font-style: normal;
}
[class^="icon-"]:before, [class*=" icon-"]:before,
[class^="icon-"], [class*=" icon-"] {
font-family: 'Font Icons';
padding-right: 4px;
font-size: 1.1em;
-webkit-font-smoothing: antialiased;
font-style: normal;
speak: none;
vertical-align: -2px;
}
.icon-zoom-out:before {
content: "\0039";
} |
<i class="icon-zoom-out" aria-hidden="true"></i> |
Problems and Pitfalls
Support for icon fonts is very good, the problem comes with using CSS generated content to insert the font characters, Internet Explorer 7 does not support this. Thankfully there are a couple of options for a partial work around.
- Option One. Use Modernizr to check for CSS generated content and polyfill as necessary.
- Option Two. Use CSS expressions, ala Foundation.
The reason for terming this a partial work around is that whilst both methods work reliably, they both run on page load. Meaning that should you insert any additional data through JQuery or an Ajax call, the icons on those elements will not receive the CSS generated content and will not work in Internet Explorer 7. I have not yet found a way around this.
The second problem is one that seams from using this particular workflow. The best font icon sets map the icons to the private use Unicode characters to prevent them from being read aloud by screen readers. It would appear that you are unable to map icons to these characters using Inkscape and instead are restricted to using standard characters which will get read aloud by screen readers.
Any solutions to either of these problems are most welcome.
CSS Performance and Maintainability
Secificity wars, duplication and stale rules all result in CSS bloat, an issue which I have found to be common when working on large projects. This is an issue which has a huge impact on CSS performance, not only in terms of load time but also in terms of the additional effort involved in maintaining the code base.
The principles laid out in SMACSS and OOCSS can go a long way to combating this and restoring order to unmaintainable CSS. If you have noticed this phenomenum in the projects you work on then these presentations from Nicole Sullivan are a great place to start.
