The beginner’s guide to Sass

Imagem

sass

You may have heard of CSS preprocessing and be wondering what all the buzz is about. You may even have heard of Sass or LESS.

In short, preprocessing your CSS allows you to write more concise stylesheets which are formatted nicely and require less repetitive techniques commonly found when writing CSS code. The result is more dynamic styling and ample amounts of time saved when developing websites or applications.

If you already write CSS, then you can easily learn to preprocess your CSS. Once you understand the scope of Sass, you’ll wonder why you didn’t switch sooner.

How is Sass different to CSS?

Sass looks similar to CSS but has its obvious differences once you dive in. There are two ways of writing Sass and it’s ultimately up to you which style you prefer. I use the indented and bracketed style (.scss) in my projects because I like to really visualize where a block ends and begins when a lot of code becomes nested. Once processed the Sass code compiles to traditional CSS automatically using a preprocessing engine.

There are many apps available which allow precompiling your Sass to be seamless and downright easy. To install, you can use the command line as long as you have Ruby installed on your machine. If you’re not comfortable with the command line there are other options (more on this below) and if this is over your head visit Sass-lang.com to learn how to do this in an easy step-by-step format. In the end, using any method be it command line or app, the Sass installation will watch your changes and automatically compile down to traditional CSS for you.

I highly recommend using apps such as CodekitLiveReload, or Mixture which help you set up a Sass project on a Mac from scratch or if you’re a Windows user I recommend PrePros. Codekit, my choice of preprocessor, helps me by preprocessing my Sass as well as validating and minifying your code to allow your website to run quickly and effectively. (The ability to create Compass or Bourbon based projects within Codekit is also an awesome feature but is beyond the scope of this article.) After you get more comfortable with Sass be sure to check out how to use Compass and Bourbon in your Sass projects.

So what is Sass?

Sass stands for Syntactically Awesome Stylesheets and was created by Hampton Catlin. Sass introduces new concepts like variables, mixins, and nesting into the CSS code you already know and love. These concepts ultimately make your CSS awesome, easier to write and more dynamic. All of these features combined, speed up any designer’s or developer’s workflow.

What commonly confuses people is the alternative ways to write Sass. You will see other tutorials or explanations of Sass using the .SCSS or the .Sass extension for their Sass files. This is apparent because there are two ways of writing the code which produce the same output. The most common I’ve seen, and the method I currently use is the bracketed version known as .SCSS. Another method is the .Sass extension which relies more heavily on indentation rather than punctual elements and is white space dependent. With this syntax there’s no need for semi-colons or brackets as you see in CSS and the .SCSS syntax.

Check out the example below.

.CSS

#container {
        width:960px;
        margin:0 auto;
}
#container p {
        color: black;
}

.SCSS

/* Same as CSS but has variables and nesting. */
$black: #000000;
#container {
        width:960px;
        margin:0 auto;
        p {
                color :$black;
        }
}

.Sass

/* Same as SCSS without semicolons, brackets, and more dependent on indentation. */
$black: #000000
#container
        width:960px
        margin: 0 auto
                p
                        color:$black

Structure

Okay so now you’re probably wondering how to get Sass setup for your own projects. The process is pretty easy, especially if you use Codekit or a similar application to help you along the way.

A typical file structure of a Sass project looks like the outline below. This may look daunting but I promise that your workflow will improve once you wrap your head around how things work together. In the end all of your Sass gets compiled down to one CSS file which will be the file you include inside your working documents be it HTML, PHP, etc…

stylesheets/
|
|-- modules/ # Common modules
| |-- _all.scss # Global level styles
| |-- _utility.scss # Basic utility styles
| |-- _colors.scss # Global Colors
| ...
|
|-- partials/ # Partials - use these to target specific styles and @import on _base.scss
| |-- _base.scss # imports for all mixins + global project variables
| |-- _buttons.scss # buttons
| |-- _figures.scss # figures
| |-- _grids.scss # grids
| |-- _typography.scss # typography
| |-- _reset.scss # reset
| ...
|
|-- vendor/ # CSS or Sass from other projects
| |-- _colorpicker.scss
| |-- _jquery.ui.core.scss
| ...
|
|-- main.scss # primary Sass file - where your main Sass code will likely be.

How you set your structure up ultimately depends on you. Start with a basic structure and fine tune to your own needs and workflow.

@Import

Sass extends the CSS @import rule to allow it to import Sass and SCSS files. All imported files are merged into a single outputted CSS file. In addition, any variables or mixins defined in imported files carry over into the main file which means you can virtually mix and match any file and be certain all of your styles will remain on a global level.

@import takes a filename to import. As a last resort Sass or SCSS files will be imported via the file name of your choosing. If there is no extension, Sass will try to find a file with that name and the .scss or .Sass extension and import it.

If you have a typical Sass project setup you’ll notice some @import rules within a base file. This simply allows you to have multiple files which sync effectively once they are compiled, for example:

@import "main.scss";

or:

@import "main";
@Partials

If you have a SCSS or Sass file that you want to import but not compile to CSS, you can add an underscore to the beginning of the filename, which is otherwise known as a Partial. As the code is compiling Sass will ignore partials when processing to CSS. For example, you might have _buttons.scss, no _buttons.css file would be created and you can then @import “buttons”;

Best practice is to create a partials directory and place all of your partial Sass files inside it. Doing this insures you won’t have any duplicate file names which Sass will not permit, for example, the partial _buttons.scss and the file buttons.scss can’t exist in the same directory. Using partials is a great way to stay organized at a global level. As long as you @import the file, the Sass you write is usable throughout the entire project. Typically inside partials I create mixins or variables to use throughout my project. I name them based on their contents and the elements they are styling.

Variables

Variables in CSS are a breakthrough in modern web development. With Sass you can create variables for things such as fonts, colors, sizes, margin, padding, etc… The list is endless. If you write JavaScript or PHP the concept is fairly similar in terms of defining variables and conventions.

So why use variables? Easy, variables allow you to use an element more than once, similar to a class in HTML or a variable in JavaScript. For example, say you define multiple divs with a specific background color. You can use the variable which is easier to remember instead of the traditional hex code or RGB calculation. Making a variable with an easy to remember name allows for less copy and pasting and a more productive workflow. The same concept applies whenever a variable can be implemented, and with Sass that is virtually anywhere, for example this .scss:

#container {

        /* Here we define our variables */
        $basetextsize: 12px;
        $container-space: 10px;
        $red: #C0392B;

        /* Variables are applied */
        font-size: $basetextsize;
        padding: $container-space;
        color : $red;
}

will result in this .css file:

#container {
        font-size: 12px;
        padding: 10px;
        color: #C0392B;
}

Operations and functions

The cool part about variables is that they are extremely similar to those used in scripting languages. Variables inside Sass can be used inside both operations and functions. The standard math operations (+, -, *, / and %) are supported for numbers. For colors there are functions built into Sass which target lightness, hue, saturation, and more.

Having this functionality makes your code more dynamic than ever. For example, If you wanted to change the overall link color of your site you could simply change the variable, re-compile, and your site will update dynamically throughout. Check out another example below for a reusable navigation list, this .scss:

nav 
{
        $nav-width: 900px;
        $nav-links: 5;
        $nav-color: #ce4dd6;
        width: $nav-width;
        li 
        {
                float: left;
                width: $nav-width/$nav-links - 10px;
                background-color:
                lighten($nav-color, 20%);
                &:hover
                {
                        background-color:
                        lighten ($nav-color, 10%);
                }
        }
}

will result in this .css:

nav {
        width: 900px;
}
nav li {
        float:left;
        width: 170px;
        background-color: #E5A0E9;
}
nav li:hover {
        background-color: #D976E0;
}

Nesting

Nesting is a huge reason why I love Sass. You write fewer lines of code in the end and all of your code is easy to read due to the nested formatting. (The same concept of nesting is also found in LESS.)

There are two types of nesting:

Selector nesting

Selector nesting in Sass is similar to how you would nest HTML:

<div id="container">
        <div class="main">
                <h1>Main Content</h1>
        </div>
        <aside class="sidebar">
                <h3>Sidebar Content</h3>
        </aside>
</div>

The Sass version of nesting:

#container {
        .main {
                width:600px;
                h1 {
                        color: $red;
                }
        }
        .sidebar {
                width: 300px;
                h3 {
                        margin: 0;
                }
        }
}

would result in the following CSS:

#container .main {
        width: 960px;
}
#container .main h1 {
        color: #C0392B;
}
#container .sidebar {
        width: 300px;
}
#container .sidebar h3 {
        margin: 0;
}

Property nesting

The second type of nesting is property nesting. You can nest properties with the same prefix to better target elements which results in less lines of code, for example this:

#container {
        .main {
                font:
                        weight: bold;
                        size: 12px;
                .intro {
                        font:
                        size: 20px;
                }
        }
}

would result in this CSS:

#container .main {
        font-weight:bold;
        font-size: 12px;
}
#container .main .intro {
        font-size:20px;
}

Mixins

Of all of the Sass features Mixins have to be the most powerful. Mixins are similar to a variable but on steroids. You can define a complete style of an element and re-use those styles throughout your project.

Mixins are defined using the @mixin directive, which takes a block of styles you created before and applies it to the selector of your choice using the @include directive. Below is a common CSS pattern used for creating a horizontal navigation menu. Instead of writing the same code for every navigation instance, just use a mixin and later include it where necessary. This concept can be done for anything you use over and over such as buttons, typography, gradients, etc…

/* Here we define the styles */
@mixin navigate {
        list-style-type:none;
        padding:0;
        margin:0;
        overflow:hidden;
        > li {
                display:block;
                float:left;
                &:last-child{
                margin-right:0px;
                }
        }
}

And here we include the mixin with one line of code:

ul.navbar {
        @include navigate;
}

which results in this compiled CSS:

ul.navbar {
        list-style-type: none;
        padding:0;
        margin:0;
        overflow: hidden;
}
ul.navbar li {
        display: block;
        float: left;
}
ul.navbar li:last-child {
        margin-right: 0px;
}

You can even go as far as creating customizable mixins which use arguments to update dynamically. On top of that you can include mixins within other mixins or create functions using mixins and more. The power behind these is absolutely huge.

There are some popular pre-defined mixin collections in which I mentioned earlier called Compass and Bourbon. With a simple @import in your project you can have access to already generated mixins commonly used throughout the web. There are so many options that it’s hard to cover everything available but it is definitely fun to experiment and get your hands dirty developing custom animations or transitions with a few lines of code rather than a screen full. Mixins make cross browser development a breeze if you don’t feel like typing browser defined prefixes over and over inside your CSS.

For example, here we create a mixin with arguments allowing it to be customized.

@mixin my-border($color, $width) {
        border: {
                color: $color;
                width: $width;
                style: $dashed;
        }
}
p { @include my-border (blue, lin); }

which gives us this CSS when it’s compiled:

p {
        border-color: blue;
        border-width: lin;
        border-style: dashed;
}

Summary

While Sass has a learning curve, I truly believe that once you understand the methods and syntax, you’ll never want to go back to writing standard CSS again.

Sass is extremely powerful and I have only covered the basics here. With traditional CSS, we’ve all encountered the copy and pasting or find and replacing tasks which waste so much time in the development stage of your project. Give Sass a try and discover how to build an effective workflow in your future projects.

via Webdesigner Depot

Anúncios

15 Inspiring Videos for Web Designers

THE BEST TALKS ON WEB DESIGN AND DEVELOPMENT FROM 2013

There is a recurring tendency among many web designers, developers, and agencies to get stuck in the occasional rut, become stagnant, and sometimes even lose perspective about the evolution and direction of web design today.

We believe it is absolutely fundamental to dedicate time to listening to the great visionaries of your chosen field who can help you see things from a different, innovative, and enriching viewpoint. These forward thinkers can help you attack projects with a renewed determination and encourage you to step out of your comfort zone – dive in head first to an unfamiliar sector, or experiment with the latest technology or programing language!

We have hand-picked 15 videos of the most important creative thinkers for today’s article which features the likes of Jeffrey Zeldman, Ethan Marcotte, Simon Collison, Shelly Bowen, or Bruce Lawson. We hope they can inspire you and give you a clutter-free vision of the current state of all-things web.

Content First by Jeffrey Zeldman – An Event Apart Boston: The rules of design engagement are changing. You may no longer be in control of the user’s visual experience. Learn the number one job of every web designer, how to persuade clients and bosses not to subject users to dark patterns, why the days of “Best Viewed With…” are finally behind us, and how a mobile (or small screen) strategy can help you improve your content, rethink your web experience, and put the user first.

 

Ethan Marcotte – The Map Is Not The Territory – Build Conference: When we create for the web, we participate in a kind of public art. We code, we design, we build for an audience, and our work feels successful when—if—it’s met with their delight. We shape digital experiences that provide a service, or that create joy, or that simply connect readers with words written half a world away. But in this session we?ll instead look at some ways in which our audience reshapes the way we think about our medium, and see where they might be leading us—and the web—next.

 

The Curious Properties of Intuitive Web Pages by Jared M. Spool – An Event Apart Boston: When a web page works, your users know exactly what to do. Everything makes sense, and they accomplish their goal, pleased with your site. Yet, often pages don’t work, and users get flustered and confused. It turns out that intuitive web pages abide by a set of curiously unintuitive properties. Watch Jared explain how to merge interaction design, visual design, information architecture, and other skills together to assemble web experiences that delight your users.

 

Simon Collison — Crafting the Progressive Web // Ready to Inspire’12: For many of us, the work we most value is imbued with a sense of craft, honesty, and purpose. We’re at our best when responses are instinctive, not bound by rigid tools or inflexible methodologies. Craftsmanship makes our work more meaningful to us, and more valuable to those who commission or consume it.

 

Shelly Bowen — How Content Strategy Makes Design Shine // Ready to Inspire’12 A cohesive, effective design depends on all the parts in play … including content. But content is often left until last, isn’t well thought-out or well crafted, and then may even compromise the integrity of the design and the business. Shelly Bowen will share 5 simple steps to integrate content strategy into your process to ensure all the parts stick together nicely (and your business goals are achieved).

 

RDO – Bruce Lawson: Bruce Lawson is a married, 40-something year old English graduate and web developer. He has lived in Turkey, Thailand, India, Bangladesh and Russia, but now lives in Birmingham, UK. Bruce works for Opera as an evangelist of Open web standards, based on his firm belief that the web is a revolutionary communication mechanism and should be available to all

 

Karen McGrane: Adapting Ourselves to Adaptive Content – An Event Apart: For years, we’ve been telling designers: the web is not print. You can’t have pixel-perfect layouts. You can’t determine how your site will look in every browser, on every platform, on every device. We taught designers to cede control, think in systems, embrace web standards. So why are we still letting content authors plan for where their content will “live” on a web page? Why do we give in when they demand a WYSIWYG text editor that works “just like Microsoft Word”? Worst of all, why do we waste time and money creating and recreating content instead of planning for content reuse? What worked for the desktop web simply won’t work for mobile. As our design and development processes evolve, our content workflow has to keep up. Learn how to adapt to creating more flexible content.

 

Jason Santa Maria – On Web Typography – Build Conference Achieving a thorough grasp of typography can take a lifetime, but moving beyond the basics is within your reach right now. In this talk, we’ll learn how to look at typefaces with a discerning eye, different approaches to typographic planning, how typography impacts the act of reading, and how to choose and combine appropriate typefaces from an aesthetic and technical point of view. Through an understanding of our design tools and how they relate to the web as a medium, we can empower ourselves to use type in meaningful and powerful ways.

 

Tim Brown — Universal Typography // Ready to Inspire’12The web is universal, so we should practice a typography that is equally universal. By focusing on traditional typographic principles, embracing progressive enhancement, and understanding how fonts, CSS, web-enabled devices, and user contexts coexist, we can reevaluate what it means to successfully set type — and inform the decisions we make about typefaces, font sizes, and white space. Let’s practice future-friendly, responsive typography.

 

Brad Frost — Death to Bullshit // Ready to Inspire’12More information exists now than ever before. 72 hours of video are uploaded to YouTube every minute. 10% of all photos ever taken were taken last year. 700,000 apps in the App Store. The list goes on. We’re being inundated with more information than ever, but there’s still only 24 hours in a day. With more stuff out there, people are forced to focus on what truly matters to them, and their tolerance of unnecessary noise is rapidly diminishing.

 

Tiffani Jones Brown – True Story – Build ConferenceWe are all storytellers. Everything we create—from opinionated tweets to designed products—says something about who we are. At their best, these stories help us relate and call us to great acts. At their worst, they reduce us to absolutes like “Top 10 ways to win” or “Here’s how to fail” when the truth is rarely so clear-cut.

 

Mandy Brown – The Cut – Build ConferenceTo edit is to cut: to remove, to shear away, to crumple up on the floor. We edit so that the message can get through, so that what we say is clear. It’s a necessary skill no matter the medium in which we work. Whether editing words or film or designs, a good edit requires the right combination of timing, compassion, and ruthlessness.

 

Luke Wroblewski – Mobile To The FutureWhen something new comes along, it’s common for us to react with what we already know. Radio programming on TV, print design on web pages, and now web page design on mobile devices. But every medium ultimately needs unique thinking and design to reach its true potential. Through an in-depth look at several common web interactions, Luke outlines how to adapt existing desktop design solutions for mobile devices and how to use mobile to expand what’s possible across all devices.

Google launches Web Designer, and its free! (beta)

Imagem

googleweb

30 September Google launched a new advertising application in beta called Google Web Designer. The company says the tool is for creating “professional-quality design” HTML5 ads and campaigns accessible to everyone from the designer to the dabbler.

HTML5 is widely seen as the standard that everyone on the Web should adopt. In case you didn’t know, Google describes HTML5 as a “universal language for building beautiful, engaging content that can run across desktops, smartphones, and tablets.” It is thus the company’s hope that Google Web Designer will help make HTML5 accessible to people throughout the advertising industry, getting Web developers closer to the goal of “build once, run anywhere.”

Screen Shot 2013 09 25 at 9.02.41 AM 730x330 Google launches public beta of Web Designer, a free design tool for creating HTML5 ads and campaigns

Here’s the current feature list for Google Web Designer beta:

  • Create animated HTML5 creative, with a robust, yet intuitive set of design tools.
  • View and edit the code behind your designs and see your edits reflected back on the stage automatically.
  • Build ad creatives seamlessly for DoubleClick and AdMob, or publish them to any generic environment you choose.
  • Receive updates to the product automatically, without having to re-download the application.
  • Access all of this entirely for free.

If you prefer the visual version, Google has provided multiple YouTube videos to show off the tool. Here’s one of them:

If this piques your interest you should read the getting started guide. Google is also asking for feedback, which you can provide on its user forum and Google+ page.

Again, this is just a beta, although Google does use the tag with little regard for its meaning. That being said, the company says it is “working hard over the next couple quarters to add new features and improvements.” We’ll let you know when its stable release is available.

via thenextweb