I’ll be showing you how to do a trap door navigation, which I’m sure has been done before. But I’ll be showing you how to do it in jQuery AND Ext. Why? Because I had to do it in both at work. A trap door navigation is basically a two image system where the ‘li’ gets one image, and the ‘a’ tag gets another so that as the link expands, the image grows with it. When you rollover each navigation item, the images then change.

Why thought can’t you do this with just CSS? You could try like I did using something like ‘li:hover’, but the problem occurs on when the images actually change on rollover. There are issues with the ‘li’ image changing because the ‘a’ tag is on top and that is what you are rolling over. Javascript is used then to correct the issue. Check out the result:

View Demo

What you need to start with, is a cut up image (I prefer slicing, but you do it however you want). You need to versions: what the buttons will look like normally, and what they look like on hover. You end up with 4 images – 2 for the normal, 2 for hover. Below is what I did for the rollover image:

Sliced nav image

The slice with the number 2 is what goes on the ‘li’, while the ’1′ goes on the ‘a’ tag.

Here is the basic HTML you need:

<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About Us</a></li>
<li><a href="#">Services</a></li>
<li><a href="#">Our Really Kick Ass Blog</a></li>
<li><a href="#">Contact us</a></li>
</ul>

Below is the CSS you need (any other tags don’t matter for the tutorial). As you can see, the ‘li’ has a background call for the image that is seen normally, and it is the longer image of the two. The ‘a’ tag has a background call of the shorter image.

li {
	list-style: none;
	background: url(images/trapOff_02.jpg) no-repeat right top;
	float: left;
}
 
a {
	text-decoration: none;
	color: #000000;
	display: block;
	float: left;
	text-transform: uppercase;
	background: url(images/trapOff_01.jpg) no-repeat left top;
	padding:11px 16px 3px 13px;
}
 
a:hover {
	color: #ffffff;
}

Now onto the jQuery, which I’ll explain after you look over it:

$('ul>li>a').hover(function() {
        $(this).parent().css('background-image', 'url("images/trapOn_02.jpg")');               
        $(this).css("background-image", 'url("images/trapOn_01.jpg")');  
  }, function() {               
       $(this).parent().css('background-image', 'url("images/trapOff_02.jpg")');               
        $(this).css('background-image', 'url("images/trapOff_01.jpg")');                  
  });

The break down

All it is, is a basic hover() method. The first line above, searches for the ‘a’ tag in a list item within a ul (ul>li>a), and puts the hover() method on it. The second line finds the ‘a’ tag, but get’s its parent, which would be its it containing ‘li’. It then uses the css() method to change the background-image to the rollover state image. The third line does the same for the actual ‘a’ tag.

The callback function, then reverses the images so that when you are not hovering over the navigation item, it goes back to normal. That is all there is to it.

Ext – The Extra Terrestrial

To do the same exact thing in Ext JS, some of the stuff changes. I won’t go over it, because most of you probably don’t even know the library exists, but you can see the differences.

Ext.select('div#slot-navigation>ul>li>a').on('mouseover', function(e,t,o) {
        Ext.fly(t).parent().setStyle({
          'background-image': 'url("/images/trapOn_02.jpg")'       
        });               
        Ext.fly(t).setStyle({
          'background-image': 'url("/images/trapOn_01.jpg")'       
        });    
  }); 
 
  Ext.select('div#slot-navigation>ul>li>a').on('mouseout', function(e,t,o) {               
        Ext.fly(t).parent().setStyle({
          'background-image': 'url("/images/trapOff_02.jpg")'       
        });               
        Ext.fly(t).setStyle({
          'background-image': 'url("/images/trapOff_01.jpg")'       
        });                  
  });

Final thoughts

Sometimes CSS isn’t enough to accomplish a certain effect. In this case, I wish it was because it seems like such a simple thing. But, it doesn’t take much javascript to make this work. Hope you learned something!

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

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');
});

If you are not using Spoon, well…you should. It’s what I use to test in any freakin’ browser. I’ve wrote about it before, so go check it out. Anyway, Spoon’s Browser Sandbox added Firefox 4 Beta, IE9 Preview, and Chrome 6 Beta to its list. I had to take a look at FF4 Beta just to see what all the hype was about. Let’s talk about what I was able to see, shall we?

Is that a Chrome skin or what?

Looks like FF took a page out of Chrome’s playbook, cause there are a lot of similarities. I actually really dig the look, which you can see in the image below. Granted, there is not much to see, because there are no plug-ins installed, but you get the idea. The icons are what I noticed first, and that is why I draw the Chrome likeness. If anything, it looks more sleek than it ever has. As far as speed though, I couldn’t tell if there was an increase or not. Since this is a beta though, I’ll leave final judgements for when the official release comes out.

Tabs, tabs, tabs!

I was disappointed to see that in this beta version that Tab Candy hasn’t been put in, cause that is one of the things I really wanted to check out. It works basically like Apple’s Expose, but with some cool additions. Tab Candy lets you view all your open tabs in one window (you see them as thumbnails), and choose which one you want to pull up. You can also drag n’ drop them into groups so that you have seperate tab groups you can open at one time…very handy if you are like me and have more than 10 tabs open at a time. Oh, and they are now at the top of the browser window, but that can be changed to look more like they do now, if for some reason you preferred that.

You can also make any tab into what they call an App Tab, which basically puts the tab to the front of the list, and instead of the title showing in the tab, it displays its favicon. I have also read that Tab Candy will do something special with tabs you turn into App Tabs, but never actually what that will be.

Additional Features

Well, one thing to note is that FF4 will have a built in Inspector like Chrome does. Let me tell you though, you will want to stick with Firebug. It is basically the poor man’s version of it, with very little info and ability. Pure crap if you ask me. It’s like they tried, but only because everyone else is adding one. I will take a gander that this is because they know everyone will use Firebug anyway, so why put in the time. I would prefer they just skipped this part.

There is a Heads Up Display under Tools now, which is basically another console type thing. You can view CSS Warnings, Errors, Network Info, Logs and what not. Doubt I will use that one, but its there. I’m guessing this is like Firebug’s console log. Didn’t really try it out much.

CSS3 Transitions and Transform

Ok, I checked out css-tricks.com because I know his new redesign has CSS3 transitions and transform in it. Transitions pertaining to CSS properties seem to be working fine like color/padding/background changes, but moving things, say, to the left or right is a no go. Transform is also a no go, so no image flips in this build. I am not sure if they are going to include that or not. Sux if they do not.

Coupon Code: webmachine

jQuery issue?

If you look back to the image above, you will notice the yellow cog in my logo in the middle of being animated. That is not just a screen capture misfire. That is actually what it looks like as it moves across the screen. I have no idea what is going on there, and I won’t know until the official release comes out. Hopefully it is because FF4 Beta is still being worked on. If not, I am a little scared, because I am not really doing anything fancy with that script. We shall see. Just wanted you to know what I saw. Everything else seemed to work ok though.

In conclusion…

I like what I saw and I look forward to the release of Firefox 4. The tests seem to show that the javascript engine is much faster, though not as fast as Chrome 6 Beta, Safari 5 or Opera. I believe even the IE9 build at the moment is better. If you have been able to play a little in any of the new Beta’s, let me know what you thought. I opened up the IE9 preview, but that is all it was, not an actual full working browser. Be aware though that IE9 will not work on XP.