/mike

Today a friend of mine found out his site got ripped. In this day and age ripping someone’s site so blatantly is the lowest of the low. And you’re going to get caught.

If you’re selling yourself as a designer or design agency you should either have enough talent to design something great yourself, or the money to pay someone else to do it for you. Be inspired by someone else’s work but don’t steal it, change some colours and two graphics, then call it your own.

It’s a popularity contest

If you’re going to steal someone’s design you should pick a good one. Here’s the problem, the good designs are usually popular and widely known. You’re shooting yourself in the foot right from the beginning because someone is bound to notice the theft.

Good design gets promoted. Good designers get promoted. People look at popular, promoted designs to get inspiration and learn from their peers, mentors, and idles. You’re seriously deluded if you think you won’t get noticed using a stolen design and passing it off as your own.

Make an excuse. Yeah, that’s the ticket.

When you’re stealing a design and you get caught — and almost everyone gets caught eventually — don’t use the excuse that you were “just seeing how things worked wasn’t going to keep it up[sic]” (source). Why? Because you’re lying. And you’re apparently really bad at it.

That excuse has been used over and over again. Every time I see another design theft when the thief finally reveals themselves and wants to win back some favour, they use that excuse.

“My bad. I’m just learning and wanted to learn from the best.”

“Oh, I only wanted to know how they did this or that.”

“This is just a temp site. I’m too busy to work on my own and needed something up right away.”

Anyone working in the web that is worth a damn knows about testing environments. Hell, anyone that’s built anything on or with a computer knows about testing. Using the “testing it out” excuse implies to me that you think you’re above testing your work. This reeks of immaturity and unprofessionalism. Would you build a client’s website and throw it on their live server just to see how things worked?! I don’t think so.

Grow up people. Get a better excuse. Better yet, get some talent.

Over the past several days I’ve been playing around with jQuery, trying to retool a couple things I’ve been working on. This is my first foray into jQueryland and it’s been pleasant thus far. I did, however, run into a confusing little issue with pageX and pageY.

What’s your vector, Victor?

The problem I was running into happened to be using e.pageY and it’s ilk. In my function they were returning the wrong coordinates. At least that’s what I thought. After much searching and patience — and a little frustration — I believe the problem is solved.

At first I didn’t realize just how far off the positioned element was when just using e.pageY and that’s why it was frustrating. After trying other options like offsetY, clientY, and el.offsetTop amongst others, I was no closer to a solution. I finally measured just how far off the positioned element was and low and behold, it matched the offset of the main parent div (in this case #container).

So, now I had to get the #container’s offset — #container is a set width with margin: 0 auto;. Once I had the offset of #container I could subtract that from e.pageY.

Just how did I get #container’s offset? Well, there are two ways I found, after searching, to figure it out.

• var topOffset = document.getElementById('container')[0].offsetY — meaning, we need to find the element in the DOM and by setting and index (best to go with 0) we could use Javascript’s offsetY and/or offsetX.
• var containerPosition = $('container').offset(); var containerTop = containerPosition.top; — meaning, using jQuery and it’s native offset() function, we grab the top and left offset of the element in the DOM.

That’s all she wrote

In the aftermath, I would say pageY and pageX were returning the proper coordinates based on the containers they were in. Unfortunately the coordinates weren’t taking the container offset into account. Whether this is a problem with how my Javascript was written I don’t know. At least I know how to solve it.

After days — and several attempts — of scratching my head and trying to figure out how to have sliding backgrounds, ala Dave Shea’s A List Apart article with CSS only, I think I’ve cracked it. Here’s a quick look at how you can set up sliding CSS backgrounds using -webkit CSS properties.

Quick caveat about compatibility

This CSS will only work in WebKit nightlies or, at the time of writing, Safari 4 Developer Preview.

Some of the current browsers may have some aspects of the CSS used in this example but not all. Hopefully we’ll see more and more browsers picking up some of these properties and behaviours.

On with the example

Probably the best way to present this example is by using a list — in our case a navigation list — but I’m sure a creative person could make it work in other situations. The jist of the process is to have 3 layers of elements and a creative use of positioning them.

Setting up the containers

The parent container (ul) should have the background state for the list (how about a nice blue background: -webkit-gradient(linear, left top, left bottom, from(rgba(137,174,195,1)), to(rgba(147,185,207,1)), color-stop(0.25,rgba(140,177,199,1)));). Using relative positioning and overflow: hidden; height: 1.5em; we can then position the list items (li) out of view (position: relative; top: 2em;). Unfortunately this also pushes the links inside the lis out of view so we need to position them back into view with position: relative; top: -2em;. So now we’ve got a navigation list with a blue background.

Now we need to add a background to the li that is currently out of view (let’s go with neutral grey gradient background: -webkit-gradient(linear, left top, left bottom, from(rgba(200,200,200,1)), to(rgba(50,50,50,1)), color-stop(0.95,rgba(100,100,100,1)));). This is what will slide into view as the visitor hovers over the link.

Get sliding already

Finally, we need to add the CSS that’s going to do the sliding. All of the example code I’ve given so far, with the exception of -webkit-gradient — which can be replaced with background colours or images — will work across all the browsers out today. The follow bits are where we dip into strictly WebKit territory.

First we’ll need to slide the li back into view with top: 0; -webkit-transition: top 0.3s ease-in-out;. It’s a little spotty though and I noticed some odd flickering when testing the code this far. So, I made sure the link stays where it is in the list by adding the same CSS from the li.

Bob’s your uncle

And that’s that. We’ve now got a navigation list, where when a link is hovered a new background slides in from the bottom. Obviously numerous parts of this example can be changed — sliding direction, colours, heights, container/elements, timing, etc.

Check out the working example (only works in WebKit nightlies and Safari 4 Developer Preview as of this writing) I threw together for you.

Here’s the complete HTML I used in my example:

<!DOCTYPE html>
<html lang="en-us">
<head>
	<meta charset="utf-8" />
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
	<title>CSS Sliding Background Images</title>
	<link rel="stylesheet" href="sliding-bg.css" type="text/css" media="screen" charset="utf-8" />
</head>
<body>
	<div id="container">
		<div id="main">
			<ul id="navigation" class="horizontal">
				<li id="home"><a href="#">Home</a></li>
				<li id="projects" class="active"><a href="#">Projects</a></li>
				<li id="blog"><a href="/mike/">Blog</a></li>
				<li id="twitter"><a href="http://twitter.com/mstickel">Twitter</a></li>
			</ul>
		</div> <!-- /main -->
	</div> <!-- /container -->
</body>
</html>

And the full CSS:

/* General page stuff */
html { background: #e5e5e5; min-height: 100%; }
body { background: #fff; font: 12px/18px "MyriadPro-Regular", "Lucida Grande", "Lucida Sans Unicode", Helvetica, sans-serif; margin: 20px auto; width: 900px; }

/* utility classes */
ul.horizontal			{ float: left; list-style: none inside; position: relative; width: 100%; *height: 1%; }
ul.horizontal li	{ float: left; margin: 0; }

/* Navigation specific */
ul#navigation			{
	background: -webkit-gradient(linear, left top, left bottom, from(rgba(137,174,195,1)), to(rgba(147,185,207,1)), color-stop(0.25,rgba(140,177,199,1)));
	border-left: 1px solid #fff;
	margin: 0;
	overflow: hidden;
	min-height: 1em;
	padding: 0;
	position: relative;
	width: 400px;
}
ul#navigation li	{
	background: -webkit-gradient(linear, left top, left bottom, from(rgba(200,200,200,1)), to(rgba(50,50,50,1)), color-stop(0.95,rgba(100,100,100,1)));
	border-right: 1px solid #fff; width: 24.75%;
	position: relative;
	top: 2em;
}
ul#navigation a		{
	border-right: 1px solid #fff; width: 24.75%;
	color: #000;
	display: block;
	height: 1em;
	padding: 0.4em 0 0.7em;
	text-align: center;
	text-decoration: none;
	width: 100%;
	position: relative;
	top: -2em;
}
ul#navigation li:hover {
	top: 0;
	-webkit-transition: top 0.3s ease-in-out;
}
ul#navigation a:hover {
	top: 0;
	-webkit-transition: top 0.3s ease-in-out;
	color: #fff;
}
ul#navigation li.active a { background: url(bg.png) no-repeat bottom left; }
ul#navigation li.active a:hover { color: #000; }

Today I was revisiting my last attempt at doing sliding backgrounds or transitions with WebKit specific CSS properties. For some reason I thought there was another way around it. So far, I haven’t found one to achieve the effect I’m going for but I did find something very interesting about -webkit-transitions.

The What

In order to use -webkit-transition on a -webkit-gradient in the background property, it seems you need to make sure there is some transparency in the -webkit-gradient. It doesn’t seem to matter which part of the gradient has transparency — the to(), from(), or color-stop() — just as long as one of them has it.

Let me explain

In my last example I discovered that it was not possible to transition from one background using -webkit-gradient to another. That still holds true.

However, what I didn’t realize at the time is that, for some reason, I couldn’t get transitions to work on background gradients that were defined with hexadecimal colours. I tried the following combinations:

• From: background: -webkit-gradient(linear, left top, left bottom, to(#f00), from(#00f), color-stop(0.5, #f00));
  To: background-color: #c80;
• From: background: -webkit-gradient(linear, left top, left bottom, to(rgba(0,0,255,1)), from(rgba(255,0,0,1)), color-stop(0.5,rgba(50,50,255,1)));
  To: background-color: #c80; and
• From: background: -webkit-gradient(linear, left top, left bottom, to(rgba(0,0,255,1)), from(rgba(255,0,0,1)), color-stop(0.5,rgba(50,50,255,.1)));
  To: background-color: #c80;

Guess which one worked?

The Finale

This has shown me two things.

1. In order to transition a background colour with -webkit-transition and -webkit-gradient you need at least one property of the -webkit-gradient to be somewhat transparent — though it does seem to work best when the transparency is on color-stop.
2. The -webkit-gradient sits on top of the background-color and background-image properties — meaning that it has a higher z-index.

Now go, my web minions, and play with whatever gradients you can come up with — it’s what makes websites part of Web 2.0 don’t you know. ;)

The talk around town is that a couple boys, in some podunk town, wrote some Javascript code that has given them more hits in the last couple days then they could have imagined. Not sure it’s all that fancy though, it still uses tables and that just won’t do.

Even with my busy schedule, I took it upon myself to help these fellows out. There’s no reason that we should be using tables for layout anymore. IE6 is a piece of crap. We all know this. Firefox 3 is getting better — or is the best in some regards, depending who you talk to — and Safari/Webkit is pretty kick ass. So why don’t we pander to the better browsers and give the rest whatever they can handle?

Enter FancyZoom, but edgier. Ok, so the tagline/name is pretty lame but whatever, I’m not a copywriter.

What’s the difference?

The biggest difference is that it uses -border-radius and box-shadow, in the browsers that support them. No more transparent PNGs and tables. The code’s slightly leaner with two divs instead of a whole table.

Don’t fret young padawans, the old way is still there for those that want to use it. In fact, the old way is the default until people start getting a little bolder in their effort to move forward. In order to see the new hotness, you’ll need to add edgy:true as an option to the first new FancyZoom call.

For example:
Prototype:
$$("div.photo a").each(function(el) { new FancyZoom(el, {edgy:true}); }) or new FancyZoom('medium_box_link', {width:300, height:200, edgy:true});.

jQuery:
$('div.photo a').fancyZoom({scaleImage:true, closeOnClick:true, edgy:true}); or $('#medium_box_link').fancyZoom({edgy:true});

Caveats

Keep in mind, when using prototype, the edgy option has to be set in the first FancyZoom call, otherwise you’ll get the old, transparent PNG version. Also remember that once edgy is set, it’s set for all FancyZoom calls on that page.

Why? Because the code for the zoomed box is only inserted once into the HTML document. It’s not inserted on the fly or for each instance of the class. This was probably done by design but adding this edgy option might change that. We’ll see.

When using the jQuery version, edgy has to be set in each call.

Check out the example I ripped made for you.