So, here I am, feeling a lecture coming out of me. Or a cranky old lady rant? Or some common sense?

You decide.

As you may (or may not) remember, I am an html/css specialist. Javascript is for interactions. That’s my philosophy. You click on something, you do whatever you need to do on the back end, add a state class to a DOM element, and use CSS to handle the rest. Like hiding/showing/transitioning.

Lately, at work, I’ve been given designs that are impossible to realize using just CSS. But because I’m anal about not using script for layout, I try my darndest to make it work that way, first. Trying everything I know, googling for ideas, trying new things.

Sometimes I get up A LOT from my desk to take a walk. That’s what happens when my mind is stretched. It needs a lot of clearing.

I tell designers that this is not good. But they see these kind of designs out in the wild. (Thanks a lot Pinterest and Google+ and all the rest of you – you know who you are.) So my arguments don’t hold up. And other developers are on board, too. We can do this, yes we can! It’s a mindset of being up for a challenge. I love a good challenge myself. But not at the expense of compromising the code.

Has anybody ever thought about these things….?

If we create designs that are easy to code, we would be done with web UI in a fraction of the time.

If we create designs that are easy to code, it would cost way less money to develop and maintain them.

If we create designs that are easy to code, we have code that is really solid, and less error prone.

If we create designs that are easy to code, our code would be more lightweight, loading faster, which is important for mobile.

Plus web-friendly designs leave more time to make sites responsive, animated (not over-animated), and to focus on content, which is king.

Personally, I think all this stuff makes a website really cool!

Keep it simple. That is – and will always be – my motto.

Hugs,

Gert

I’ve been learning a lot of new things at work these days. A LOT of new things. As a matter of fact, I’ve been waking up thinking of code. This. has. got. to. stop. I just had a couple of books come today from Amazon, so I’m looking forward to taking a break from the code and diving into them tonight.

But first, I want to write this blog post about SASS. It just really blows me away how much power it has. I came to SASS from LESS. I thought LESS was enough. But, now that I’ve seen the power of SASS, and now that I’ve seen how complex stuff other people have written that I’m trying to “install” is, I’m looking forward to writing some plain ol’ mixins and functions that can be plopped into a directory on my site without needing to go through some huge front-end dev complex install/build brouhaha. Kind-of like how I’ve always used jquery plugins. Pull them down from the web, plop them in a directory. Link to them. I like it like that. (Expect a future post from Gladys and I on this whole new era of front-end dev complexity.)

So, in preparation to go a little deeper with SASS, I decided I should learn all the parts of the language first. And there were many places I went to for that, and wound up taking copious notes and trying things out. I figured I’d share, because I’ve written them up in a different order than the official SASS documentation. And I’m sure I’ll be revising things as I learn more, but here is where I am with this right now.

SASS documentation, Gertified

As far as I can tell, the .sass syntax isn’t used much. One site said nobody uses it. So all this is based off of the .scss syntax.

And stuff in blockquotes is from the official SASS documentation (found at sass-lang.com).

@IMPORT

• Used to import other .scss files and partials into a .scss file.
• Put these statements at the beginning of the file, in the order you want them included. It is also possible to nest them in a selector, but that restricts what is allowed in them.
• Use the correct path to file.
• _partial.scss – files beginning with an underscore aren’t compiled to .css files.
• Don’t include the underscores for partials nor the .scss extensions in the file names.

NESTING
& (the ampersand)

The & is replaced with the parent selector. In addition to what is shown above, you can also do this:

@at-root

This can come in handy for flattening CSS specificity while still making it so you can group your selectors. It writes the selectors inside it out to the root level of the document. You can also use it for single selectors, like

@at-root .section-head { … }.

Read more about @at-root, here: http://sass-lang.com/documentation/file.SASS_REFERENCE.html#at-root There are also “with” and “without” modifiers when using nested directives like @media queries, which can be nested in CSS rules and inside each other. The latter will result in a combined media query…

@media screen and (orientation: landscape)

SassScript

SassScript allows you to define properties using variables, math operators, functions, etc. Following are the features of SassScript…

VARIABLES

• Variables are scoped to the container they are defined in, unless you use the !global flag.
• Variables defined outside of any selectors are global.
• You can use !default after a variable assignment, which will make the assignment as long as the variable wasn’t already assigned or has a value of null.

Note the #{ } interpolation syntax, which allows you to use the value of the variable as part of a selector or property name. When using interpolation, quoted strings are unquoted.

It’s also possible to use #{} to put SassScript into property values. In most cases this isn’t any better than using a variable, but using #{} does mean that any operations near it will be treated as plain CSS. For example:

p { $font-size: 12px; $line-height: 30px; font: #{$font-size}/#{$line-height}; }

is compiled to:

p { font: 12px/30px; }

MIXINS

If a mixin doesn’t contain any arguments, or isn’t passed any values, you can omit the parenthesis.

EXTENDING

You can extend a placeholder or a CSS selector. The % syntax defines a placeholder. It is not compiled to actual CSS, it is only valuable if used. But it allows you to extend a set of styles without basing them off of another selector. It’s sort of like a variable for a set of styles. In this example, column also extends sidebar, which means it picks up those styles as well as the stretch placeholder styles.

Extending makes use of selector combining so, if you don’t have to pass variables, use placeholders instead of mixins for repeating chunks of styles to generate less code in the compiled CSS.

You can’t extend concatenated selectors:

However, you can do stuff like this:

You can play with this stuff at http://sassmeister.com/ to try and wrap your head around the nitty gritty of @extend.

The !optional flag after the extend is supposed to make the extend fail gracefully if there isn’t a class found to extend. No CSS was output in this case.

My thought is that for best practices – and understandability and maintainability – keep those extends simple! As I always say, just because you can do something doesn’t mean that you should.

FUNCTIONS

• Functions are like mixins, only they return a value rather than styles. And you can do lots of processing in them.
• Functions are called without the @include statement that mixins use.
• Functions can be called with or without explicit keyword arguments. Keywords come in handy when you have a long list of arguments to pass and/or don’t want to pass all of them. (Named arguments can be passed in in any order.)

There are lots of built-in functions, too lengthy to list here. But these are the categories of functions:

• Color functions – for manipulating RGB, HSL, and opacity values
• String functions – a lot of these are similar to javascript string functions
• Number functions – again, similar to what javascript offers for numbers
• List functions – for manipulating lists of values, traversing, replacing values, joining two lists, etc.
• Map functions – all list functions work on maps, too, treating maps as lists of pairs. Plus there are some additional map-specific ones.
• Selector functions – work on CSS selectors, still trying to wrap my head around this.
• Introspection functions – these really help you figure out if features, variables, functions, other things exist, or what type of data you are working with
• Miscellaneous functions – there are only two if() and unique-id()

See all of them here: http://sass-lang.com/documentation/Sass/Script/Functions.html#list-functions

DATA TYPES

SassScript supports seven main data types:

• numbers (e.g. 1.2, 13, 10px)
• strings of text, with and without quotes (e.g. "foo", 'bar', baz)
• colors (e.g. blue, #04a3f9, rgba(255, 0, 0, 0.5))
• booleans (e.g. true, false)
• nulls (e.g. null)
• lists of values, separated by spaces or commas (e.g. 1.5em 1em 0 2em, Helvetica, Arial, sans-serif)
• maps from one value to another (e.g. (key1: value1, key2: value2))

OPERATIONS

Arithmetic

• +, -, /, *, % (addition, subtraction, division, multiplication, modulo) – these can also be used on colors
• expressions are evaluated left-to-right, with multiplication and division taking priority over division and subtraction. You can also use parenthesis around operations to add clarity. Spaces are not required but also can add clarity.
• You can’t multiply two pixel values together- e.g. 2px * 2px
• When multiplying percentages, leave off the % – e.g. use $width * .75 instead of $width * 75%

A special note on division. Since CSS supports the / in separating numbers (as in font-size/line-height), There are rules to make it used as division. When in doubt, add parentheses!

Equality (for all types)

== and !=

Relational (works on numbers)

<, >, <=, >=

Boolean

and, or, not

Concatenating 

• The + operator works to combine strings
• If you combine a quoted and unquoted string, whichever comes first determines what you wind up with (quoted or unquoted).
• If two property values are concatenated, they are concatenated with a space in between them.
• Interpolation can be used to place dynamic content inside a string (null values are interpreted as empty strings)

DIRECTIVES

Many of these have been covered already, but here are some more…

@debug, @warn, and @error that you can use with complicated SASS to help you debug.

@supports, but this is for the future (when CSS supports it, haha), to allow you to wrap CSS in @supports curly braces to supply alternate styles. For example:

@if, @else, @for, @each, @while – these are like javascript control structures

The if() function is a shortcut for a simple @if/@else. Like so:

You can pass content (stuff inside curly braces) to a mixin and specify where it goes in the mixin with the @content directive. The classic example is a media query mixin:

Is there more? Yeah, there’s more. But this covers a lot of it. Go, read, play in Sassmeister and learn. There is great power here. Be safe!

Sources:

• http://www.sass-lang.com/
• http://www.sass-lang.com/documentation/file.SASS_REFERENCE.html
• http://www.sitepoint.com/sass-mixin-placeholder/
• http://www.sitepoint.com/sass-extend-nobody-told-you/
• http://12devs.co.uk/articles/handy-advanced-sass/

Phew, that was a long post, huh? Well, I am known for my gift of gab. I do have to apologize, though, this post isn’t fully accessible because I used a lot of SassMeister screenshots. It was the easiest way. Please use the official Sass documentation if you need a more accessible reference.

Hugs.

I’ve been writing CSS for a long time. I’ve gone through many revisions of how I write it. It’s interesting how it has evolved over time.

THEN…

Like not using underscores in class names because they caused issues in some browsers (I can’t remember the particulars, that was awhile ago).

Like putting all properties on one line with tight spacing. This had the dual effect of being able to see more related classes without scrolling and keeping the file size down. (Now with preprocessors that can minimize your files this is a non-issue.)

This:

.title{margin:0;padding:0;font-size:24px;}

Instead of this:

.title {
  margin: 0;
  padding: 0;
  font-size: 24px;
}

I know, most people hate the tight one. But you got used to it, really. I did it that way for years.

Like using ids instead of classes for layout elements (e.g. #banner instead of .banner) until I learned that that the developers at my company needed to use ids for javascript handles. Ids also make the css have higher specificity. So now I use classes for most styling.

Like using object-oriented css (OOCSS) and making use of inheritance.

Like taking advantage of existing elements instead of classing everything.

Like writing a lot of reset styles.

Like nesting a lot of LESS styles to see the structure of a component.

UNTIL…

I saw unintended consequences of some of the choices I made.

A guy named Matt showed up at my company and started questioning some of my ways. (This was a good thing. Hi Matt.)

I found SMACSS. Or maybe Matt did. Not sure, we read a lot of the same stuff.

And this style guide.

And it was funny, reading these, that their styles have also evolved, and that some of what they do I do, too.

NOW…

Here’s where I am with my CSS. Which is some of what I have learned along the way, some new stuff, and some still-to-be-determined-if-it-sticks stuff.

I write minimal reset styles. I found that aggressive reset styles force you to write more overrides. And there was one issue with Internet Explorer where if you set a property, it could never be set back to auto. I can’t remember which property that was, sorry, it’s been awhile. But I’m guessing it was an issue with buggy IE 7.

I format CSS the way the rest of the world does. But I group my properties in a certain order, which makes it easier to find them when there is a big block of them. Like box model styles first, then visual styles, then fonts, etc. If I weren’t working with other people, I’d most likely also lump some of them on the same line, like so:

.box{
  position: absolute;
  top: 0; left: 0;
  width: 100px; height: 100px;
  border: 1px solid #eee;
  font-size: 12px;
}

I use more classes. I got in trouble with OOCSS and using elements instead of classes. So now I follow the SMACSS guidelines of creating a component where the name of the component is in the child styles. At least for the main child components. This also allows me to flatten my CSS. And it’s the opposite of where I was, trying not to class everything. I’m not sure where I’ll ultimately land but, for now, I’m leaning towards adding classes. It seems to be more future-proof.

So now I’m doing this:

.section { … }

.section-header { … }

.section-body { … }

instead of:

.section { … }

.section h1 { … }

.section div { … }

Yeah, you can already see the issues, right? .section div { … } is not smart. I wasn’t usually that generic, but for a small component where I thought there would only be one div or span or link or image, I fell into this trap. And usually got burned.

I use the is- prefix for state changes, like .is-hidden, .is-selected, etc. And ids are only in the html, for javascript / aria purposes.

I use a namespace for styles I create, so they don’t clash with any css I bring in externally. Like gert-btn, gert-heading, etc.

I’m trying the SMACSS l- prefix for layout classes. The thing is, I feel like sometimes the layout / component dividing line is gray, and I’m not sure I want to take the time deciding which bucket to put something in and then wishing I hadn’t. So this one is kind-of experimental at this point.

I comment, comment, comment. That’s one thing that’s never changed, since I was a young whipper snapper cranking out code. Only now I mix /* */ comments with // comments. The latter are used in LESS and SASS and don’t get written out to the final CSS file. Sometimes I want a comment to wind up in the CSS, but usually the disappearing comment is good enough. It just tells someone else – or reminds me – why I did something the way I did. I also like using them at the end of code blocks, in case indenting gets messed up. I really hate spending time finding matching braces. I do this same code block commenting with html comments.

Also, with preprocessors, I’m starting to put media queries right near where the adjustments need to be made.

And I’m using variables for colors, typography, and oft-reused styles, like standard padding. But I’ve seen this overdone, too, with variables for everything you might possibly want to change and variables using other variables. It can make things way more convoluted than they should be. But variables are great for theming!

Lastly, instead of integrating hacks – because there aren’t many needed anymore – I’m starting to use a hacks.css file. Or, as some like to call it, a shame.css file. Its for things you put in place in a hurry that you know can be done a better way but you just haven’t figured it out yet.

You know of what I speak.

So, do you think about your CSS? Or do you just write it any old way? I feel like having a system makes coding simpler and faster and easier to maintain.

Only don’t get set in your ways! Because there are always things that work and things that don’t. And things that change over time with browser and CSS capabilities.

Now go get stylin’!

You’ve got to try your own thing, I know, but it’s still worth listening to your elders and learning from their experience of what works and what doesn’t. And elders can also learn from the youngsters and their new ways of doing things. People who are open to learning and sharing make better coders. They make better everythings, really.

Hugs.