I’m not a huge fan of CSS frameworks. Not to say they are bad or anything, I just don’t care for them. I’ve tried a couple, and I thought the 960 grid did a pretty good job. There has been a lot of hype lately though for responsive design, so I thought I would take a look at one that has been getting a lot of respect and talk – Skeleton.

Skeleton’s CSS syntax

The creator of Skeleton, Dave Gamache, deserves a lot of credit for what he has done with it. For one, I’d like to thank him for using easy to remember class names like ‘one-third’ and ‘two-thirds’. I had a hard time remembering 960′s class names with .grid-whatever. He also uses things like ‘offset’ which is easier to tell what it does by reading it, than ‘push’ or ‘pull’ ever did. Looking through Skeleton’s grid CSS made me really happy when I first opened it, so props to Dave.

It’s a starting point, not the end line

The creator says it best in his blog:

“Responsive design is not a silver bullet, but it is the strongest solution to the rapidly growing set of devices web designers and developers have to account for. It would be impossible to design for individual devices and screen sizes these days – instead let’s be smart and essentially “bucket” devices into categorical sizes and design appropriately. Skeleton does just this.”

Skeleton isn’t the end all be all, but it does a great job at what it does – create responsive layouts. It supports a lot of browsers, and if you are building a nice clean site, everything scales nicely. One thing to note, in IE it will not scale, you will just get the standard grid styles. Which I think is fine, people get than for the most part anyway, so IE users won’t notice anything different.

Some cool features

Skeleton has some nice additional things included such as Buttons and Tabs. The Buttons are just nicely styled, well…buttons. All you have to do is add the class “button” to an ‘a’ tag, and you have a CSS3 gradient styled link. You can obviously do that kind of thing yourself, but hell its included and free, so stop bitching.

The tabs are created by putting the ‘tabs’ class on a ‘ul’, and creates a nice tabbed navigation, which scales down beautifully when you get to smartphone screen size. While they don’t exactly look all that fancy, the Tabs are clean and work well out of the box. It does require jQuery in order to work (which is already linked to in the HTML file), but the script is so ridiculously small, if you have worked with the library before you should have no problem modifying it should you need to.

On top of that, there is also a simple HTML form, and an example on Skeleton’s website if you need to view it.

So how is it really?

Well, if you are creating a nice, clean and basic styled website, Skeleton is easy to use and kick ass at what is for. Everything is easy to use, compatible, and sizes perfectly. If on the other hand, if you are creating a site that I think most developers do, which uses a lot of CSS background images, you could be in for a lot of pain.

See, background images don’t resize. Images hard coded into the HTML do, but not one placed by CSS. So guess what that means? Ya, different versions for each screen size Skeleton hits. On top of that, just shrinking a graphic doesn’t mean it just works. I tried a basic test of just rebuilding portions of my home page, and just downsizing the image and writing the style it need for the appropriate screen size didn’t mean everything looked fantastic. It worked for desktop, but the design failed once it hit 760px. Everything was just to small.

The navigation was also hard, because it was absolutely positions within a div at the top. Well, when things move in when you resize, the top of my nav disappeared as it lined up block style from inline. So I had to rewrite the styles for that. Do you see where I am going with this?

If you go to Skeleton’s website and resize the window to whatever, everything plays nicely. But the site is plainly designed. No real graphics or anything. Start throwing in background images, and anything positioned to somewhere specific, and all of a sudden you are not only writing styles for one screen size, but for ALL of them. Your CSS file becomes huge, and you are basically creating a new site for each size. I mean new too, because your design for one size might not look that great just scaled down to fit a smaller one. You might need two or three different looks.

Will it be rewarding when you are all done? Hell yes, but just after some playing around with it, it is no simple thing to do for a more complicated design. Once I really started noticing what was going to be involved I quickly realized how important it was to just stop and rethink some things. If you are going to use Skeleton on anything other than a basic site, spend a lot of time planning and visualizing how everything is going to flow and scale, or you will screw yourself later if something doesn’t work out the way you thought it was.

Final thoughts

Still, this is the first CSS framework I would actually seriously consider using. It’s easy to understand, clean and a very good starting point. Personally I would replace the HTML5 shim with Modernizr, but that is being nit picky, and total opinion. I really enjoyed playing around with Skeleton, and I recommend you looking at it if you are thinking about building a website using responsive design. If anything, do a small test yourself, and you will learn a lot within a half hour of building something out with it.

Coupon Code: webmachine

I know it has been like a week and a half since I last posted, but my life has been busy. Very busy. Today started out crazy, with a person in the UK wanting 63 psd files sliced and built. Ya, you read that right….63! I thought to myself “Self, this could be some good money.” All had the same outer shell, but the content areas were insanely packed with forms, icons, lists, navs…seriously a ton of work. Was for a online gaming company. You know how she found me? Googled “how to slice a psd” and I showed up on the bottom of one of the pages, she came here, clicked contact…and there you go. The problem? Budget was $1200 and needed it in 2 weeks. I actually felt bad turning that down, but there is no way I was going to go through that stress, and that amount of work for $1200. I was think at the least 5-6k.

Anyway, here is the list of goodies I’ll comment on later:

• CSS3 -moz-crisp-edges, and -webkit-mask
• CSS3 Gradient lines under links
• CSS Regions

jQuery Fly Out Menu Update

New story now, still with me? A couple of days ago I received an really cool email from a guy that searched for “jquery fly-out menu” and got to my post here. He thanked me a lot for the menu, but was having problems with it in IE7 and 8 after doing some modifications to it. I had already tested it in those browsers and there were no problems. Unless of course you bring the width in so that the sub menus appear above the main menu. The problem is that in IE7/8, they appear below the other main nav li’s. I thought it would be a simple fix, but after 2 hours last night, I was getting really pissed. I solved it through random guessing and some head slapping.

That menu puts a position: relative on all the ‘li’ within the menu. Works fine if you don’t screw with my code because of the way I animate it. The solution? Couldn’t have been easier. Remove the relative position off of the ‘li’s and create a class that adds it back on hover (using jquery), and removes it on roll off. You can see the updated code on A Simple jQuery Fly Out Menu post. Soooo…”fixed” the menu, and I got to see someone use my menu on their site. Was very cool. He also noted that I was the only developer to actually help him, and that this was the 5th menu he’d tried. Also cool was the fact that his boss was excited to put me on paid retainer to help out when needed.

Recent Web Development Goodies – FF and Webkit are going nuts!

Let’s start off with CSS3 -moz-crisp-edges, and -webkit-mask. Smashing Magazine had a pretty good article about The Future of CSS: Experimental CSS Properties. It talked about some cool new stuff, and the first one I liked was -moz-crisp-edges. This is cool if you are doing responsive design, where the images scale as your window size shrinks/expands. It avoids blurry edges on the image as it is being manipulated by the browser. The CSS looks like this:

html  { image-rendering: -moz-crisp-edges; }        /* all images, videos, background-images */
img   { -ms-interpolation-mode: nearest-neighbor; } /* all images, IE */

You can read more about it and a few other properties on Mozilla’s image rendering documents.

The second one I liked was -webkit-mask. Basically it allows you to mask an image using an element with a CSS3 gradient applied to it, or a semi-transparent png. Very cool, and I can see myself using something like that with the gradient, but if I was going to go through the trouble of making a png to mask it, I might as well just create the entire thing in Photoshop. Here is what the CSS would look like:

.element2 {
	background: url(img/image.jpg) repeat;
	-webkit-mask: -webkit-gradient(linear, left top, left bottom, from(rgba(0,0,0,1)), to(rgba(0,0,0,0)));
}

CSS3 Gradient lines under links

I don’t know about you guys, but I build a LOT of different kinds of navigations. A very common thing I see come across my desk is to use a line between the links, or under them to show they are being hovered over. I’ve been using images to get the effect going, but this cool cat wrote some nice styles to do it with just CSS. He’s got a version that does not use pseudo-elements too! Read it and thank me for passing this on to you. Oh, and scroll down on his page and check out the link about adding depth to a website. Easy, simple, and I can’t believe I haven’t seen more of that.

CSS Regions – Ask and ye shall receive!

A while back I wrote about wishing you could create shapes using CSS. Weird ass shapes, like polygons, circles or whatever. Well gues what? Adobe, of all people obviously reads my blog, and because they respect me sooooo much, decided that was a GREAT idea. It’s called CSS Regions. There are a TON of different properties invovled, but here is a list from their site about it:

• Story threading — allows content to flow in multiple disjointed boxes expressed in CSS and HTML, making it possible to express more complex, magazine-style threaded layouts, including pull quotes and sidebars.
• Region styling — allows content to be styled based on the region it flows into. For example, the first few lines that fit into the first region of an article may be displayed with a different color or font, or headers flowing in a particular region may have a different background color or size. Region styling is not currently implemented in the CSS Regions prototype.
• Arbitrary content shapes and exclusions — allows content to fit into arbitrary shapes (not just rectangular boxes) or to flow around complex shapes.

You can download demos of it here and see some samples. The below CSS example is from a section of a pie chart, so this one line will make one piece of pie:

.slice4 .region {
-webkit-wrap-shape: polygon(217px, 225px 217px, 225px 217px, 0px 179px, 3px 143px, 12px 110px, 26px 80px, 46px 53px, 70px 31px, 98px 13px, 131px 0px, 167px 217px, 225px 217px, 225px )
}

Ok, I know I wished for it, but I really don’t want to plot all that out. This is one of those “cool” things, but totally impractical. Can’t see myself ever doing that even if it was supported by all modern browsers. Who knows though. Never say never.

They are good discussion pieces, but would you use them?

Honestly, these are all pretty neat. I would use the gradient lines and the -moz-crisp-edges, but the the shapes in CSS Regions…not so much. The documents talk about other things that might be useful, but I dislike things that only work in one browser.

What do you guys think?

Coupon Code: webmachine

Before I start my small discussion on “Are We Getting Dumber”, let me just say that there is yet even more kick ass things that have come out since I wrote the first part of this little series. Sass 3.1.0 came out, and is going by the name of Brainy Betty. It added some neat stuff to its already great ability, like getting the inverse of a color, Sass based functions, keyword arguments, and more. Granted I probably won’t use a lot of it, but it is still cool that it has been updated. You can read about the improvements it received on Sass’ changelog. Just to note as well, Haml and Sass have been separated into two different gems, so you can install them independently now.

Compass received an update as well, going to version 0.11.1. Some things have changed in this new version which might force you to go back and rewrite some things if you update, but I’ll let you know about that when I upgrade this week. I read the change log and a couple of things stand out. First, is that the linear and radial gradient mixins have been deprecated. We’ll use the background-image mixin instead, and pass it a gradient function. Here is an example of the old way (from my site):

#myDiv {
@include linear-gradient(color-stops($orange, darken($orange, 25%)), left); 
}

And what it will look like now:

#myDiv {
@include background-image(linear-gradient(left, $orange, darken($orange, 25%))); }
}

The second is that Lemonade has been merged into compass. If you’ve been using Lemonade, you need to upgrade your sprites to use the new Compass Sprites. Read Compass’ changelog to get more details on everything that has been added/removed.

Are web development helpers making us stupid?

I don’t literally mean dumb or stupid like your IQ is dropping, but more in the sense that, are we using certain tools to make our job easier but let us skip the learning process. Take CSS3 gradients for example. How many of you can actually write out a gradient style that has several color stops? Even webkit’s? The radial gradient as well? Both versions of webkit’s syntax (Safari 4 and 5+)? I could figure out the linear, but it would take me about 5 minutes to get everything correct. The radial though? Not so much. Mostly because I don’t use it that much. Even with linear gradients though, I use things like ColorZilla’s Ultimate CSS Gradient Generator, or the site CSS3 Please!.

All you hard-core zealots might laugh, but it is faster for me to put in two colors, copy the CSS, and paste it into my stylesheet. Of course on my freelance projects I’m using compass which uses really easy mixins (like I show above), but my point is that I save time by doing so. It would take a while to write out all the rules myself. I save a lot of time by using tools like that. In using these types of tools though, are we actually learning the new properties themselves?

Say you had to take a written test, and you had to write out all of the CSS3 properties you know. Then let’s say you get -1 for each you leave blank, but -2 for each you get wrong. How many new properties could you write down on a piece of paper and know you were right? I could get a few, off the top of my head: text-shadow, box-shadow, border-radius, a two color linear gradient. That is about it, and now that I know that, I’m going to correct this issue. Is this really a problem though?

Does it matter?

That is another question. I feel like we should be able to write out these properties off the top of my head. I also think we should use these tools if they save time. For me, any new rules I use I’ll be learning to write by hand first, and THEN use any tool I need to get it done faster. In the overall scheme of things though, how much does knowing how to write it out really matter? You could say “Maybe you don’t have access to those tools, then what? You are screwed! That’s what.” Really though, think of the last time you didn’t have the internet available to you when developing. I can’t think of many, and it didn’t end up mattering.

You could look at any abstract language like this as well. Is Compass and Sass dumbing my knowledge down if there is an easy mixin to use so I don’t have to write out the whole CSS? What about jQuery? CoffeeScript? Do you see my point now? We use a lot of things to speed our process up without knowing the whole picture ourselves. It reminds me of high school math where you would take a test and you had to show HOW you got the answer, not just get the correct answer. Think of jQuery as the calculator, where Javascript would be the written out method to get the same answer. Is knowing that make you more of a developer? Does just knowing how to make things work fine, or knowing HOW it works better? Hopefully you get what I’m saying there.

What do you think?

Coupon Code: webmachine

I’ve read a couple of posts/articles in the past week that REALLY got me excited again about CSS. A guy over at Google, Tab Atkins, has hinted at it, and then this article by Johan Brook talks about it as well.

What the hell am I talking about you ask? Well by the title of this post you should have figured it out.You know all those articles I’ve posted about my experience with Sass and how much I love it? Or maybe my artilce on LESS.js? There are other articles around the net where people commented their worries and complaints on why they didn’t need or use it. Well guess what…you might want to rethink that and start learning. Variables, mixins and nesting might be coming to CSS itself. If you didn’t read the article I linked to above, Webkit is thinking about it, and it may be here as soon as the end of this year.

What does this mean for web developers?

Adding these things into CSS would be a dream come true, and now that there is some actual discussion going on to make this happen (and from people at Google!), that dream is closer to reality. If Chrome (I assume Safari is included in that) adds this functionality in, I think Firefox will be close behind. That’s cool and all, I know, but what does that mean for us?

Simple answer: A whole lot of awesome! Smaller and tight stylesheets! Possibly quicker development time. Might as well start learning it now, cause its not hard, but you do have to put some effort into it to get it down.

CSS seems to be growing in what it handles and does, and faster than people are learning it. Trust me, I work with people who don’t even have CSS2 down and they’ve been working with it for two years. If adding things like this culls the heard a little, I for one am all for it.

What are these new features anyway?

Here is a real quick example of what I have used so far in my redesign of my website, so you can see what we have to look forward to. This is from my Sass file, and is for the right sidebar of my home page.

Below includes some variables, a couple of mixins, and some nested stuff:

/Variables
$dkgray: #2d2d2d;
$orange: #f15c22;
$wht: #ffffff;
$w: 1020px;
$r: right;
$l: left;
 
@mixin font ($size, $weight, $family: "Arial,Helvetica,sans-serif"){
  font: {
    family: #{$family};
    size: $size;
    weight: #{$weight};
  }
}
@mixin sprite($left, $top) {
    background:  url(../images/iconSprite.png) no-repeat $left $top;
}
 
#calltoAction {
	width: 260px;
	height: 181px;
	background: url(../images/calltoAction.png) no-repeat left top;
	color: $dkgray;
	padding: 25px 0 0;
	h1 {
		@include font(16px, "bold");
		color: $dkgray;
		text-align: center;
		text-shadow: none;
	}
	h2 {
		@include font(42px, "bold", "Bebas, Arial,Helvetica,sans-serif");
		@include sprite(210px, 13px);
		color: $dkgray;
		text-align: center;
		padding: 0 18px 4px 0;
		text-shadow: 2px 2px 3px #999;
		border: none;
		a {
			color: $dkgray;
			&:hover {
			color: $orange;
			}
		}
	}
	h3 {
		@include font(16px, "bold");
		color: $dkgray;
		text-align: right;
		margin: 0 20px 0 0;
	}
}

The tag with an id of #calltoAction has a variable call:

color: $dkgray

Now, $dkgray is set to #2d2d2d, but the best part is, I don’t have to remember the damn hex code for that color. Seems silly at first, but takes less thinking on my part, and really easy to change that color across the board if I have to. No find and replace needed.

You will also see that there is an h1 nested with in that #calltoAction, which only styles the h1 tags within it. This avoids repetition by nesting selectors within one another. Awesome. If you look at the above code you can see I’ve nested some things even deeper, to style the ‘h2 a’ styles.

There is also the mixin calls. If you look at the top of the code above, you see a mixin for the sprite. Anytime I want to use that same sprite (and I do quite often), I type something like this:

@include sprite(210px, 13px);

All that I have to change each time are the pixel numbers for the position. This means less typing and smaller file sizes when all of these things are used. A LOT less repetition goes on throughout as well.

What do you think about this?

Sass and Compass let me do this cool crap now, but if CSS gets this functionality, and compiling happens in browser, there is going to be a lot of happiness. Probably a lot of grumbling and haters as well, but who cares about them? CSS was becoming tedious to write for me without Sass. This will make it fun again for me, and a lot faster to write. I think it needed it, and this is long over due. What do you guys think?

Coupon Code: webmachine

That sums it up quite nicely I think. If you click on the demo below (my actual redesign) and look at it in Chrome (or Safari, though I didn’t look I’ll assume it works there), you will notice that when you roll over the social media icons in the right sidebar, they will change size. I was very proud of myself for accomplishing what I think very few web developers actually use. I’ll go over what I think about CSS3 Animations at the end of the article, but for now, let’s go over how I accomplished this.

View Demo

Cool eh? Until you actually see how much CSS is needed to accomplish this. Keep in mind that I wrote this in Sass (and using Compass’ built in CSS3 mixins), so it actually took waaaaay less lines to do. What I’ll show you though is the actual CSS output that you would have to write if you are NOT writing Sass…which is most of you. The icons are in an unordered list, just so you are informed

The first part are the styles for the li’s:

#social ul li {
list-style: none;
float: left;
-moz-transform: scale(1);
-webkit-transform: scale(1);
-o-transform: scale(1);
transform: scale(1);
-webkit-animation-name: resize2;
-webkit-animation-duration: .5s;
-webkit-animation-iteration-count: 1;
-webkit-animation-timing-function: ease-in-out;
}

As you can see I have a transform: scale on there that is actually keeping it the actual size it should be. That is because there is a hover on the li that will increase its size, so I need the un-hovered li to be at the default. After that you have a call to an animation called ‘resize2′. Remember that, because you’ll see what is going on with that in a bit. I want the animation to last a half second, iteration-count means how many times and I only want it to run once, and then I want it to ease in and out smoothly. So far so good?

Now for the li:hover styles:

#social ul li:hover {
-moz-transform: scale(1.1);
-webkit-transform: scale(1.1);
-o-transform: scale(1.1);
transform: scale(1.1);
-webkit-animation-name: resize;
-webkit-animation-duration: .5s;
-webkit-animation-iteration-count: 1;
-webkit-animation-timing-function: ease-in-out;
}

There are two things different here. First I am scaling the size to 1.1 of what the actual size is. This says that when you hover over the ‘li’, make it bigger. Second, I am calling an animation called ‘resize’. NOW for the fun stuff.

Animations – Think of Flash frames written out as text commands

That is exactly what came to mind when I was writing it last night. Remember when I said remember ‘resize2′? Well here are the two actual animations that the li’s are calling:

@-webkit-keyframes resize {
	0% {
	-moz-transform: scale(1);
	-webkit-transform: scale(1);
	-o-transform: scale(1);
	transform: scale(1);
	}
  100% {
  -moz-transform: scale(1.1);
  -webkit-transform: scale(1.1);
  -o-transform: scale(1.1);
  transform: scale(1.1);
  }
}
 
@-webkit-keyframes resize2 {
	0% {
	-moz-transform: scale(1.1);
	-webkit-transform: scale(1.1);
	-o-transform: scale(1.1);
	transform: scale(1.1);
	}
  100% {
  -moz-transform: scale(1);
  -webkit-transform: scale(1);
  -o-transform: scale(1);
  transform: scale(1);
  }
}

Looks like a sort of jQuery function or if/else statement…or something. Either way, it is crazy to look at, and it helps if you think of it as a Flash tween. The first animation, ‘resize’, is actually for the ‘li:hover’, which says at 0% (think frame 1 in Flash) start out at the default size, and at 100% (last frame in Flash animation) make it 10% bigger (the 1.1). The ‘resize2′ animation does the exact opposite which is called out on the ‘li’ (meaning when you are not hovering on it).

There is one side effect on this and that is that when you reload the page, it starts the animation ‘resize2′ because you are not hovering. Doesn’t bother me, and I find it actually cool so I left it the way it is.

Now that I’ve done it, what do I think?

Ok, I wrote my first actual CSS3 animation. I think it is cool, and I have rolled over it about 50 times just to give myself a pat on the back each time. What is your first thought when looking at all of that? That is a lot of css, isn’t it? Pretty much what I thought, and that is just to get the social icons to grow big and small on the hover. Now imagine if you have a ton of other crap that you want to do slick little animations to.

What made this a non-thing for me is that Sass and Compass make writing something like this easy. But writing it out like most of you would seems like a serious pain in the ass. I could have written something similar using jQuery in like 5 lines of code and in about 10 minutes. On the one hand I find it cool that this was done using only CSS. On the other, it is only supported in 2 browsers (Chrome and Safari) and 1 Beta…I hope (FF 4). It does the scaling in FF 3.6, just not the smooth animation. jQuery would have hit all of them.

I am torn between thinking how cool that is, and if something like this should even be in CSS. This goes beyond the basic styling of an element. This is doing some functionality on top, that to me can be more efficiently done in jQuery, so why in the world would I do this again? I will, but it is more of bragging rights than because I should.

My question to you though is two fold: Should CSS be handling this, and if yes, why would you when you could get it done quicker and with less using javascript?

If you want to read more on cool CSS3 animations, transitions and transforms – I highly recommend this.

Coupon Code: webmachine

So I’m in the middle of redesigning/rebuilding my main site, as you would know if you are keeping up with me here, and I am using Sass (SCSS syntax). I love it so far. There is a lot you can do to save you time during the build. There is also the “This new crap I’m using is awesome! I’m going to do this and this and this…”, which can get you in trouble. What kind of trouble you ask? The kind that over complicates your CSS of course. Stop talking and read please! Jeez, I’ll tell you how you can easily do that.

Think before you leap

A day after starting my build using this awesome technology, and no it isn’t new, but it is still fairly new to me. Syntactically Awesome Stylesheets has some cool features that you immediately want to dive into. Variables are the easiest, and it is kind of hard to abuse those. Mixins though, that is where I got into trouble. A good example, which you might have seen in my last post is a mixin I was using for ‘font’. Seemed like a great idea at the time! Let’s shorten that CSS so that I only have to type in the properties that will feed the mixin. What could be wrong with that? Well, technically nothing, but it also wasn’t helping me and I was just adding to the confusion with a completely stupid mixin (at least in this case). Here is what I am talking about:

@mixin font ($size, $weight, $family){
  font: {
    size: $size;
    weight: $weight;
    family: $family;
  }
}

To use that mixin, I then type out this SCSS:

.myClass {
@include font(18px, "bold", "Arial,Helvetica,sans-serif");
}

What is wrong with that? Well, let’s actually write out the CSS for it:

.myClass {
font: bold 18px Arial,Helvetica,sans-serif;
}

It’s actually shorter to write the CSS out rather than using the Sass mixin for it. That was my problem. And not just there. I had a few others with the same exact problem. How did I fix it? I sat there staring at the small amount of CSS I had and actually thought out everything. Where is Sass going to save me time, and where am I being stupid? So I thought about it, and rewrote the mixin. I changed it to have a defualt family since most of the time I am going to be using Arial anyway. The rare occasions where I won’t is where that variable will come in handy.

@mixin font ($size, $weight, $family: "Arial,Helvetica,sans-serif"){
  font: {
    family: #{$family};
    size: $size;
    weight: #{$weight};
  }
}

Now I don’t have to type in the family every time because that is my default. Why be repetitive? That is the beauty of using this. I then wrote this mixin for using a sprite over and over again:

@mixin sprite($left, $top) {
    background:  url(../images/iconSprite.png) no-repeat $left $top;
}

Now I just have to write “@include sprite(0, 0)” to get the sprite call’s position. This to me is being smart. Mixins should be used to reduce the amount of CSS you have to write later. Using Compass’ ‘@import’ to use some of the CSS3 stuff like border-radius and box-shadow was a good call too. When you use that and Sass together, it only takes one line to output the necessary 5 lines for browser pre-fixes. Brilliant! That is the kind of thing I needed to think about. I don’t want to use Sass just because it is cool, I want to use it the way it should be used – making dev time faster, and very easy to read/use stylesheets.

Just because you can doesn’t mean you should

This is my main point, and can be applied to any new tech we find or use in our development process. I imagine somewhere there are some people that used every dam CSS3 trick they could because they could, and because it was the new thing. You know, an element with box-shadow, text-shadow, border-radius, gradients, transitions…you name it, all on one thing. Why? For the look at what I did factor. I want to avoid that with my use of Sass. This build might take me longer than normal, but I want to make sure I’m not doing anything stupid, so I’m slowing down and thinking about what I am trying to do first. Where am I going to be calling the same thing over and over, and where will it matter?

I know that sounds silly, because shouldn’t we be doing that anyway? Yes. But how many times have you designed and sliced up a psd file, know exactly what divs/elements you need and just blaze ahead? I do most of the time. We just start typing away and plugging in everything – header div here, nav there, sidebar over there, footer here…need a ul for the nav and one for the footer, bunch of li’s and links. A lot of it takes no thought at all. You are done before you know it. While I am doing the layout like that no problem, the CSS is taking longer and I think it will help in the long-run. By slowing down and actually thinking about where a mixin would actually help, it’s helping me by thinking more clearly on my CSS.

I am hoping that by documenting what I am doing using Sass I will help you developers that are new to it, because honestly it is very hard to find information out there that is geared towards the newbie. Most of what I have found is written differently than what I am using (because they are using the original Sass syntax, where I am using its new one – SCSS) and written as if you are already familiar with it.

Again if you have any tips or pointers, please leave a comment and let me know. If you are just starting to use Sass/SCSS and want a good place to go to read up on it, check out Derek Perez’s blog. Tool around there and you will find some good info. I’d recommend following him on twitter as well, because he’ll tweet some good stuff. He is also very helpful if you have questions.

Coupon Code: webmachine

Note: I have included at the bottom of this article, the actual Sass/CSS I have written for my redesign. When I am completely finished with the build, I will post the whole thing for you to view. If you see anything I am doing wrong, poorly, or stupid, PLEASE inform me. I am learning too!
If you read my post yesterday, you will know that I will not be using the 960gs on my main site redesign. Not because it is bad, but because it isn’t going to fit with the project. What I WILL be using though, is Sass. I’ve done a couple of articles already on it, which you can read below if you wish:

• Test driving Sass 3…a second look at Sass
• Taking LESS.js for a spin, and how does it compare to Sass 3

My goal in using Sass for my redesign is to 1) get more familiar with it and learn the syntax better, and 2) well, to say that I did. Always good to learn, and if anyone happened to care, I can always stick it in the resume. One thing I have noticed is that there is no really good reference to using it. An e-book would be great, as it doesn’t need to be very long. Hell I would even settle for an article that posts the Sass styles for a complete site that uses all the CSS3 styles.

Take a look at what I have built so far:

View Demo

Speaking of CSS3 styles in SCSS

If you read my other articles, you will know that SCSS is the new syntax for Sass, and reads/writes pretty close to how you would write your normal CSS. Except for the fact that it has all the extra goodies. Anyway, I using Compass (which includes the blueprint framework – which I ditched) to compile the Sass into CSS, and while looking through its support and reference I read about CSS3 mixins. If you wanted to do a border-radius on something, you would write this in Sass:

.myClass {
@include border-radius(5px);
}

And the output into CSS would look like this:

.myClass {
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
-o-border-radius: 5px;
-ms-border-radius: 5px;
-khtml-border-radius: 5px;
border-radius: 5px;
}

Even if you only write 3 or 4 of those lines of CSS normally, you did it in 1 line of Sass. This is where I think the brilliance and power of Sass comes into play. Now, you can’t just get that to work by itself, the solution to actually get it to do that is by including this at the top of your .scss file and you are good to go:

@import 'compass/css3';

Nested styles

There is so much I still don’t know about the syntax and what it can do, what I do know is enough for me to want to use the hell out of it. Nested styles is one of those. Personally, I hate having to write styles for stuff like unordered lists, because you have to write out several styles (ie – nav ul, nav li, nav a, nav a:hover). In Sass, you can do it with one. Here is an example of what I have done with my redesign:

nav li {
	float: left;
	border-right: 1px $orange dotted;
	margin: 0 12px 0 0;
	padding: 0 12px 0 0;
	line-height: 18px;
	a {
	color: $orange;
	text-decoration: none;
	display: block;
	float: left;
	@include font(18px);
	.byline {
		@include font(14px);
		font-weight: normal;
	}
	}
	a:hover {
	color: $wht;
}
}

Here is the output in CSS:

nav { position: absolute; top: 225px; left: 35px; }
nav li { float: left; border-right: 1px #f15c22 dotted; margin: 0 12px 0 0; padding: 0 12px 0 0; line-height: 18px; }
nav li a { color: #f15c22; text-decoration: none; display: block; float: left; font-family: Arial,Helvetica,sans-serif; font-size: 18px; font-weight: bold; }
nav li a .byline { font-family: Arial,Helvetica,sans-serif; font-size: 14px; font-weight: bold; font-weight: normal; }
nav li a:hover { color: white; }

If you don’t know Sass at all, the above is going to be somewhat confusing, but I actually had to write less for the Sass styles AND some of what I did write (because it includes a mixin) is reusable for other styles. Nesting lets you put element styles within the parent elements. To quote the Sass site, “avoids repetition by nesting selectors within one another.

Mixins are awesome

So far, I am only using one mixin, and that is for declaring the font style. Here is what that looks like:

@mixin font ($size){
  font: {
    family: Arial,Helvetica,sans-serif;
    size: $size;
    weight: bold;
  }
}

If any of you reading this knows Sass, I have a question for YOU. While this is working for me at the moment, I would like to pass the family into the mixin as a variable, so when I call it later I can do something like this, but where I can change the family in the call:

@include font(18px Arial,Helvetica,sans-serif;);

When I tried doing it, it was not putting a comma between each, and therefore not recognizing it at all. If you know how to do this, PLEASE LEAVE A COMMENT!

Final Thoughts

I am really falling in love with Sass, which sounds weird to me because at the moment it is actually slowing me down. I can see though that once I master it, my development time will greatly improve. A few things on my wish list if anyone out there knows the answers to these questions:

• How do I toggle the line comments on and off in the compiled CSS?
• Can you change the format of the compiled CSS? Meaning from single line to block?
• I’m using Compass for the compiling, but developing in PHP. The config file doesn’t seem to be doing a damn thing. Why? Its in my root directory, but even if I change the lines about the locations, nothing breaks like I thought it would.

Here is the Sass file I have so far, in case you are interested (please leave pointers if you have any!)

@import "compass/css3.scss";
 
/*Variables*/
$dkgray: #2d2d2d;
$orange: #f15c22;
$wht: #ffffff;
$w: 1020px;
$r: right;
$l: left;
 
@mixin font ($size){
  font: {
    family: Arial,Helvetica,sans-serif;
    size: $size;
    weight: bold;
  }
}
 
 
body {
	background: url(../images/background.jpg) repeat-x left top $dkgray;
	color: $wht;
}
 
a {
	color: $orange;
	zoom: 1;
	outline: none;
}
 
a:hover {
	color: $wht;
}
 
h1 {
font: bold 24px Arial,Helvetica,sans-serif;
text-shadow: 2px 2px  5px $orange;
}
 
#container {
	width: $w;
	margin: 0 auto;
	overflow: hidden;
}
 
header {
	width: $w;
	height:  337px;
	position: relative;
	background: url(../images/jcIndex_01.png) no-repeat left top;
}
 
#contentRepeat {
	width: $w;
	background: url(../images/jcIndex_03.jpg) repeat-y left top;
}
 
#contentTop {
	width: $w;
	background: url(../images/jcIndex_02.jpg) no-repeat left top;
	min-height: 500px;
	height: auto !important;
	height: 500px;
	overflow: hidden;
	padding: 80px 0 0;
}
 
.ie6 #contentTop {overflow: visible;}
 
#contentLeft {
	width: 580px;
	float: $l;
	margin: 0 0 0 60px;
	padding: 10px;
}
 
#contentRight {
	width: 260px;
	float: $r;
	margin: 0 60px 0 0;
}
 
footer {
	width: $w;
	background: url(../images/jcIndex_03.jpg) repeat-y left top;
}
 
#footerContent {
	width: $w;
	min-height: 222px;
	height: auto !important;
	height: 222px;
	overflow: hidden;
	background: url(../images/jcIndex_05.jpg) no-repeat left bottom;
}
 
.ie6 #footerContent  { overflow: visible;}
 
/*************** Navigation Styles *****************/
 
nav {
	position: absolute;
	top: 225px;
	left: 35px;
}
 
nav li {
	float: left;
	border-right: 1px $orange dotted;
	margin: 0 12px 0 0;
	padding: 0 12px 0 0;
	line-height: 18px;
	a {
	color: $orange;
	text-decoration: none;
	display: block;
	float: left;
	@include font(18px);
	.byline {
		@include font(14px);
		font-weight: normal;
	}
	}
	a:hover {
	color: $wht;
}
}

Coupon Code: webmachine

NOTE: I am going to review it, not go into detail into how things work – there are plenty of tutorials on that (one of which is listed below.
If not for this tutorial by Joshua Johnson, I will have to admit that the 960gs is terribly confusing. He explains how the grid works in plain english, and what the push/pull classes do. I started my redesign build last night, and as previously stated before, I was going to try my hand at this whole grid thing. Follow along, and you will see what I think.

Learning Curve

Either I’m an idiot, or the 960gs is way harder than I thought it was going to be. How could I not understand what is going on under the hood from the get go? First, it didn’t help that I started with the 16 column while designing in Photoshop, only to realize that I wanted the 24 when I started building it. I am already down for the count, because the grids do not line up the same way, due to there being more margin in the 16 column version.

One thing that bugs the hell out of me is that the PSD files are at 1020px wide. Why is there nowhere that says why this is. Do I crop it exactly to 960? If so, why not just make the damn thing AT 960px? So what are you supposed to do? I designed it at the 1020px size and lined everything up at the column lines. I had stuff going beyond, but that was pure graphics stuff – nothing that needed to be lined up. This is the kind of thing that drives me nuts though…the site itself.

Here is the basic low down on learning how to use the 960 Grid System. The first time you use it, you will say to yourself “What the #@%#?” The second time you use it, it will be easier and things will start making a lot more sense. A few times in, and you will be pro. The problem though is that the tutorial I linked to above, was the first one that I actually understood on using some of the classes within the system. The actual site for it is not a great place for documentation.

Let’s start with the pros

I’ll start with the good stuff first, so you don’t feel I am trashing the system.

• CSS – once you understand what each class does, it becomes a breeze to make a layout. Full width column for header, grid 10 there, grid 5 there, push this one, and pull that one. The 960gs can really speed up development.
• Measurements are done for you – No thinking about widths, margins, positions…everything is calculated for you.
• Pre-made templates are great – other than the size issues I had in the PS files, they are easy, well done, and very modifiable.
• Insane amount of templates – Sounds the same but not…the 960gs not only comes in 12, 16 or 24 column templates, it has all the css, sample code, and there is a template for pretty much every piece of software you could possible use (Photoshop, Illustrator, Indesign, Flash, Fireworks…and crap I haven’t heard of).
• Templates/Prototypes – If you are making template based sites or just making a quick prototype, this is where the 960gs shines because of the speed factor.

The stuff I don’t like

Please read this knowing that it is my opinion. I am not bashing the 960gs, I am just telling you what I think the pros and cons are.

• Flexibility – If I want to shift things left, I have to modify the CSS. So what? Well, the damn thing is set at very particular sizes, and really, if I am going to have to adjust a bunch of the styles, I might as well have done it myself. A push or pull shoves the container a specified amount. I felt like if I changed the CSS, I was already ditching the grid.
• Semantics – while this doesn’t bother me much, if you had to hand this off to someone who didn’t know the system, they would look at the class names and scratch their head in confusion. I’m not pro at the semantic thing, but I do try.
• Classes – you can really start adding a ton of classes to the element you are styling. like “grid_5 push_1 prefix_2″…I am making that up, but you get the picture. I’ve read “Ya, but you put an id on it then”…so now I’m just cluttering crap up to make sense out of it?
• Extra containers – maybe this is just my not having enough experience, but if I put padding on say “grid_5″, I have to change the width of grid_5, but that hits all of them, so now I have to add a special class? Or add a container just to do the padding. I feel there is too much potential for divititis using the 960gs.
• Unused classes – there is going to be a bunch of classes that you will not use during a build, which then means you will most likely go through and weed them out.

Final thoughts

I’m glad I tried it out, as it gave me something new to learn. Once you have learned how everything works, the 960gs can really speed up development time. Will I use it for my redesign now that I have worked through it? Not on this redesign. Will I use it for a different project? Yes! I liked it enough to have a full go at it. The photoshop templates alone are good just for design purposes. I feel I have less control over the CSS using the 960gs, but if you use it from the start, and have a clear idea of where you are going, then this is a good tool.

Coupon Code: webmachine

I’m rebuilding my website, and I am learning multiple things at the same time while doing so. I’m using the HTML5 Boilerplate, HTML5 tags, the 960 Grid System (24-column), and will be using Sass. This isn’t a real post, just an update on why there won’t be one tonight. Tomorrow I will write a review on the 960 Grid System now that I have the hang of it. Does anyone know if the HTML5 Boilerplate has a Sass option? Meaning it has the CSS written in SCSS? Would be awesome, because I do not look forward to rewriting that. Anyway, I’ll have a real post for you tomorrow.

First off, we know for a fact that Safari and Chrome support Transitions, because we’ve all been using one of them to see the cool crap people have been doing. FireFox 4 will support it and they keep adding to it all the time. IE9, as of what I have read, will not. They are still missing a lot of other things, so this is not surprising. But since it is still too early to tell, who knows what the final product will have. The main thing to know is, if you haven’t started getting your CSS3 chops down, you should start. It won’t be long before we are using it on a regular basis. Personally, I use quite a few, but transitions is one that I have stayed away from.

The basic syntax

If you have used CSS3 styles, then you are used to the vendor prefixes. They might be annoying, but they make sense and it just means some additional copying. A simple transition you might have seen is to fade in the background color of a button. Here is what the CSS would look like:

a { 
width: 100px;
height: 30px;
text-align: center;
padding: 15px 0;
display: block; 
color:#ffffff;
background-color: #000000;  
-webkit-transition:background-color 1s ease-in;  
-moz-transition:background-color 1s ease-in;  
-o-transition:background-color 1s ease-in;  
transition:background-color 1s ease-in;  
} 
 
a:hover {
background-color: #ff0000;
}

It turns out that I had nothing to be afraid of, and neither should you. Type in the vendor prefix, then the colon, followed by the property you are transitioning, the amount of time you want the transition to take, and finally the type.

Skew, Scale, Rotate, and Translate

What? These are simple, yet cool. Ever create a button where the text was set at an angle, but you had to use Photoshop to do it? Well, Rotate will keep the text as actual text, and make it easier to fix if someone needs to change what it is saying. Here is what the CSS would look like for each of these:

Skew:

.box {
-moz-transform:skew(20deg);
-webkit-transform:skew(20deg);
-o-transform:skew(20deg);
transform:skew(20deg);
}

Scale – the numbers are percentages, where 1 = 100%:

.box {
-moz-transform:scale(1, 1.5);
-webkit-transform:scale(1, 1.5);
-o-transform:scale(1, 1.5);
transform:scale(1, 1.5);
}

Rotate:

.box {
-moz-transform:rotate(30deg);
-webkit-transform:rotate(30deg);
-o-transform:rotate(30deg);
transform:rotate(30deg);
}

Translate:

.box {
-moz-transform:translate(100px, 100px);
-webkit-transform:translate(100px, 100px);
-o-transform:translate(100px, 100px);
transform:translate(100px, 100px);
}

Easy right? Just remember that skew will distort, scale changes size, rotate turns, and translate moves. But what if you want to do more than one transition or transform? That’s what you want to know now, right? Well, good thing I did the demo that I’ll link to later, or I wouldn’t have known. There was a lot of trial and error, smiles and clapping, swearing and finger pointing at the screen, and….some discovery.

You can’t eat just one!

First thing to remember: you can only have one transform or transition…how do I say this without confusing the crap out of you…property ‘line’. Better if I show you…

This is the BAD:

-webkit-transform: scale(1.5,1.5);
-webkit-transform: rotate(30deg);

Why is that bad? Oh my god, I just pasted that in, give me a second you impatient lot. Because like every other property, the second one overwrites the first. For some reason I thought the above would be different though. They are different transitions right? Yes, but of course…no. Here is what it should look like:

-webkit-transform: scale(1.5,1.5) rotate(30deg);

There is one main syntax part to note when doing multiple transitions vs transforms: use a space between each different transform, and a comma to seperate each transition. You can view my little demo below (Safari or Chrome at the moment), and immediately after is the CSS for the bottom button.

View Demo

#backMovement a {
	color: #ffffff;
	display: block;
	width: 120px;
	height: 50px;
	padding: 15px 0 5px;
	text-decoration: none;
	text-transform: uppercase;
	-moz-border-radius: 12px;
	-webkit-border-radius: 12px;
	border-radius: 12px;
	border: 1px #f60 solid;
	text-shadow: 1px 4px 8px #F60;
	-moz-box-shadow: 1px 4px 8px #F60;
	-webkit-box-shadow: 1px 4px 8px #F60;
	box-shadow: 1px 4px 8px #F60;
	-moz-transform: scale(1.5,1.5) rotate(30deg) translate(50px, 50px) skew(20deg);
	-webkit-transform: scale(1.5,1.5) rotate(30deg) translate(50px, 50px) skew(20deg);
	-o-transform: scale(1.5,1.5) rotate(30deg) translate(50px, 50px) skew(20deg);
	transform: scale(1.5,1.5) rotate(30deg) translate(50px, 50px) skew(20deg);
	background: url(images/grid.jpg) no-repeat 0px -104px;
	-moz-transition: background-position 1s, color 1s ease-in, text-shadow 1s ease-in;
	-webkit-transition: background-position 1s, color 1s ease-in;
	-o-transition: background-position 1s, color 1s ease-in;
	transition: background-position 1s, color 1s ease-in;
}
 
#backMovement a:hover{
	background-position: 0 0;
	color: #F60;
	text-shadow: 1px 4px 8px #fff;
}

Let’s wrap this up

You can obviously see that there is a LOT of lines of css for this stupid button. It’s not even that great looking and it took 31 lines of CSS (block form of course)! Now, think about this…you want to add a gradient, use multiple images, and god knows what. I realize that realistically a lot of the CSS would be trimmed off of this button because most likely you are not going to rotate, skew, translate, color change, background position movement and who knows what else I put on there. BUT…if you think about it, most of that is not that far fetched.

Here is something else to consider. Let’s say you make the button in Photoshop and it is on an image sprite. Which can you do faster, the CSS method or the image method, and what will the actual file size contribution be? Meaning which will weigh more? You do still need the background image for the CSS method. What you do save in the long run, is time on any changes.

One thing I like about the making a button this way is that you can have chunks of the CSS stored in snippets, so that if you need a particular part, you don’t have to write it from scratch every time.

What are your thoughts on this? Let’s here ‘em!

Coupon Code: webmachine

$('.content').scroll(function() {
alert('You are scrolling');
});