CSS Newbie

Button Height and a Broken Box Model

Rob Glazebrook — Tue, 02 Mar 2010 21:00:28 +0000

When I figured out the workaround for line-heights in form buttons last week, I also discovered an interesting discrepancy (feature?) across all major browsers in terms of buttons and the box model. Check out this article for a more in-depth refresher on the CSS Box Model, but here’s a brief summary:

Let’s say I have a div styled like so:

div {
	height: 30px;
	padding: 10px 0;
}

The box model states that the resulting box will take up 30px of vertical space for the div’s contents, plus an additional 10px on the top and bottom for the padding, for a total of 50px vertical space taken up by our div.

Back in the day, the problem was that while most browsers accepted this “standard” box model, Internet Explorer decided to be all rouge-ish and maverick-y and come up with a box model of their own. In their model, the entire div should take up 30px of vertical space, which would mean in our example above that 10px was subtracted from the top and bottom of the div’s interior to make room for padding… meaning there was only 10px left over for the div’s contents.

As you can imagine, this caused all sorts of problems for web designers trying to design for both box models. There were workarounds of course, but they bloated our code and made our lives just that much less glamorous. I mean, who has time for champagne pool parties when you’ve got to write browser-specific stylesheets?

To be fair, Internet Explorer has since begun to adhere to the standard box model. Old pages that used the old box model still work as such in “Quirks” mode, while new standards-compliant pages are rendered appropriately in “Standards” mode (there’s an article on Quirks vs. Standards modes here).

Back to the Future

So what the heck does this have to do with us? After all, we live in The Future. Well, as far as I can tell, buttons still use the non-standard box model. And the strangest thing to me is, this holds true in every single browser I tested: Chrome, Safari, Firefox, Opera, and Internet Explorer.
Let’s look at an example. Here’s the (essentially identical) CSS for a nice input-style submit button:

button {
	height: 30px;
	padding: 10px 0;
}

I’ve specified a height of 30px and top and bottom padding of 10px, which according to the box model should result in a total height of 50px overall, right? Except as you can see in the image up top, Firebug (running in the most recent edition of Firefox) reports a total height of just 30px: it’s subtracting the padding I’ve applied, in addition to the height of the default button borders.

Which means that, in addition to Firefox ignoring line-height on buttons, it also ignores the modern box model altogether!

So what gives? What makes a button any different than any other element on the page? I wish I knew. In fact, if you do happen to know the answer to this riddle, please share with the class in the comments below. Until then, I don’t have a solution to this particular peccadillo. But knowledge is half the battle!

The Firefox Input Button Line-Height Bug

Rob Glazebrook — Thu, 25 Feb 2010 22:21:00 +0000

I recently ran into a bug in Firefox and Opera when I tried to set the line height of text inside a button (which affects input “submit” buttons as well as the HTML button tag). The bug? The line height can’t be changed!

For example, take the following code:

input#button {
	border: 2px solid #06f;
	color: #06f;
	background-color: #6cf;
	font: bold 12px Arial, Helvetica, sans-serif;
	line-height: 50px;
}

In a perfect world, this code would be a quick and easy way to vertically center text inside a button and set the button’s height, since text is always centered inside of the space created by its line-height.

But the results are inconsistent. Chrome, Safari, and (I can’t believe this either) Internet Explorer 8 all center the text and resize the button just like I’d expect. But the results are less than perfect in Firefox and Opera (see the image above).

The Problem, Defined

A quick look at Firebug proves enlightening: even though I’ve specified a line-height of 50px, Firefox is using a line-height of 15px instead.

So what gives?

It seems our bug isn’t really a bug at all, but a “feature”: that is, it’s a deliberate decision by Firefox to limit line heights on buttons. This is evidenced by this line of CSS in Firefox’s default CSS:

button, input[type="reset"], input[type="button"], input[type="submit"] {
	line-height:normal !important;
}

Basically, Firefox is setting the line-height to “normal” on buttons and is enforcing this decision with an !important declaration. This is a frustrating decision on their part, particularly considering (as Eric Meyer has pointed out at great and detailed length), line-height: normal is anything but.

And while trying to work around this rule, I discovered something that makes the situation a little more dire: browser-defined !important rules cannot be over-ruled by author-defined !important rules. This rule cannot be overruled by a CSS file, an inline style — anything.

So what’s to be done?

After a couple of hours of teeth-gnashing, I’ve settled on the following as an acceptable workaround. Instead of using line-height, use padding.

So to take the example from earlier, we’d convert it to look like this instead:

input#button {
	border: 2px solid #06f;
	color: #06f;
	background-color: #6cf;
	font: bold 12px Arial, Helvetica, sans-serif;
	padding: 18px 6px;
}

This effectively centers the text inside our buttons, but it isn’t ideal. It means there’s no easy way to ensure our buttons are using the same line-height as the rest of our content, and it means the size of the button can’t be dependent upon the size of the button text. But I’ll take what I can get on this one.

New Example Page Formatting

Rob Glazebrook — Tue, 16 Feb 2010 21:21:05 +0000

I’ve always liked that most of my articles here at CSS Newbie have live demos — places where you can go and check out the code working in the real world. It’s a nice complement to the tutorials, I think.

But one think I’ve never liked about this setup is that my demos have no visual consistency. Some have background colors, some don’t. Some are centered while others are left-justified. Almost none of them show the source in the page itself. And not a single one of them is “branded” CSS Newbie.

This has always been a background annoyance, until a few weeks ago when I installed Google Analytics on my example pages and realized they were getting a lot more traffic than I expected. And further, many people visited the example pages without ever first seeing the corresponding CSS Newbie article. So people were getting examples with no context, and no way to respond.

I wasn’t cool with that.

So, I took some time and added a new wrapper to my CSS Newbie example pages. It solves the branding problem, makes tracking more consistent, and makes the example pages more useful to boot.

Now when you visit a CSS Newbie demo page, you’ll see the live demo on the left, and the code generating that demo on the right. It’s as easy as copy/paste to get the code for your own, without having to view the source. And to make things even simpler, there’s a link to download the source code to your computer.

Here’s a few example pages to try out:

So please, take a look at the new CSS Newbie example pages. Let me know what you think: what you like, what you don’t, or what you’d like to see added in the future.

The Simple Secret to Good Dropdown Navigation

Rob Glazebrook — Wed, 03 Feb 2010 21:26:23 +0000

Almost every example of good dropdown navigation on the web today relies on a single, simple HTML structure: the nested unordered list. Without this structure, dropdown menus would be much more complex to build than they already are.

Of course, that means that knowing how to build a good nested unordered list is critical to this entire process. I’ve seen many examples of people trying to build a dropdown menu on their own, running into problems they didn’t understand, and throwing their hands up in frustration… only to discover their problem wasn’t some obscure CSS problem, but an error in their list structure.

As such, I thought it would be a good idea to go over what a good nested unordered list structure looks like (and what a bad one often looks like too!).

The Good

Here’s a well-structured nested unordered list — a perfect foundation for a dropdown menu.


	Nav Item 1
	Nav with Subnav
		
			Subnav 1
			Subnav 2
		
	
	Nav Item 3

The critical detail in the example above is where the nested unordered list appears in relation to the list item it is “under”. The unordered list is inside the list item that will act as its parent in the navigation.

That’s a very critical bit. Without that little detail, it becomes much more difficult to determine which submenus “belong” to which main list items.

The Bad

By comparison, this is what I see 90% of the time when someone has a misbehaving menu:


	Nav Item 1
	Nav with Subnav
	
		Subnav 1
		Subnav 2
	
	Nav Item 3

It’s an extremely minor difference. The only change here is that the nested unordered list appears immediately after the list item they expect it to appear under, instead of directly inside like it should be.

And that makes a difference, obviously, in our CSS and JavaScript. Elements aren’t where the CSS is looking for them, relationships are harder to determine in JavaScript, and so forth.

List-Based Navigation Menus

And since we are talking about list-based navigation menus, here are a few that have been discussed on CSS Newbie. All rely on unordered lists as their structure:

And with that, I’ll be gone on vacation until next week. Take good care of the place, peeps!

How To Emulate a Foreach Loop in JavaScript

Rob Glazebrook — Thu, 21 Jan 2010 19:53:11 +0000

JavaScript does many things well, but one area I’ve always had trouble with is the array and array-manipulation department. For example, this weekend I was working on a project that required me to iterate through a JavaScript array and peform a set of functions on the values within. In PHP, that would have looked something like this:

$myArray = array("item 1", "item 2", item 3");
foreach($myArray as $item) {
	$item = "Do Something Here";
}

Nice and simple, right? All we’re doing is iterating through the array with the foreach() construct and replacing each item with the phrase “Do Something Here,” but you can see how this could/would expand. A similar construct exists in Perl, another language I grew up on.

But JavaScript lacks a specific “foreach” statement, which trips me up every time. So how do we fake it?

Plain-Jane JavaScript Foreach

In JavaScript, we make use of the for() loop construct to fake a foreach scenario. It looks something like this:

myArray = new Array("item 1", "item 2", "item 3");
for(i=0; iThis lets us loop over our array and do something with each item in turn. It’s not pretty, but it technically does the trick.
jQuery Foreach Loops
As with many things in the JavaScript world, jQuery makes the concept of a foreach loop simpler. To iterate over an array in jQuery, we’ll use the jQuery.each() (or in shorthand, $.each()) function.
Note: This is a different function than the more commonly known $(whatever_element).each(), and has slightly different usage!
The jQuery $.each() function works like this:
myArray = new Array("item 1", "item 2", "item 3");
$.each(myArray, function() {
	this = "Do Something Here";
});
In short, we pass the $.each() function two parameters: the first is the array we want to iterate over, and the second is the function we want to perform on that array. Within the function, we simply refer to the current item as “this,” which is pretty standard fare.
I prefer the jQuery functionality for two reasons:
It reads slightly more like a PHP foreach statement, and
I’m generally loading jQuery anyway, so there’s no harm in using it.
Your needs may vary – I’m not suggesting loading jQuery on an otherwise framework-free page just to make array loops easier. But if you’ve already got jQuery loaded, this might save you a bit of time (and in my case, frustration).
Related Reading:
Generating Automatic Website Footnotes with jQuery
The Simple Secret to Good Dropdown Navigation
Improve Usability and CTR: Make an Entire List Item Clickable
The EqualHeights jQuery Plugin
A Simple jQuery Stylesheet Switcher

Improve Usability and CTR: Make an Entire List Item Clickable

Rob Glazebrook — Tue, 12 Jan 2010 22:31:29 +0000

I was recently working on the navigation for a new Wordpress site (to be announced later) and I encountered a bit of a conundrum when it came to my category navigation.

I had developed some snazzy PHP/WordPress scripting to output my category information into a list containing both the category name as well as the category description. It was a nice way to show people what categories the site had, as well as offering some insight into what the category might contain. The code looked something like this:


	
		Category One
		This is a description of category 1.
	
	
		Category Two
		Category 2 description goes here.
	
	(...and so on...)

I styled it such that the style changed when the user hovered over the list item (as in the image above). But while the list item contained a lot of information, the link to the category (inside the heading) — and therefore the actual clickable area — was rather small. I wanted the entire list item to be clickable.

And this isn’t a purely aesthetic choice, either (although that had something to do with it). It’s a usability concern. If I wanted my entire list item changed on hover, people would expect that clicking the list item would elicit some sort of response – this is the way navigation works in most corners of the web. But in this case, only those fortunate enough to click the anchor inside the heading tag would get anywhere. Not good.

Further, it stands to reason that the larger your links are, the more likely someone will click on them. Fitts’ law suggests that the time it takes to successfully click on an object is a function of the distance the mouse is from the object and the size of the object. Thus, the larger the clickable area, the higher the click-through ratio (CTR).

This line of reasoning left me with three options:

Wrap the contents of the entire list item in an anchor tag. This isn’t ideal, because an anchor tag is an inline element, and inline elements technically shouldn’t contain block-level elements (like heading or paragraph tags).
Wrap the contents of each block-level element in an anchor tag. This also isn’t a great solution, because it grows my code and requires me to style several different links.
Use jQuery to do what I needed.

Can you guess which one I chose? If you selected option #3… well, you’ve visited this site before.

Our jQuery Script

This tiny snippet of code makes it all happen:

$(document).ready(function() {
	$("#categories li:has(a)").click(function() {
		window.location = $("a:first",this).attr("href");
	});
});

What this does is assigns a new click function to every list item in our categories list that contains (“has”) at least one anchor tag. When someone clicks on the list item, it redirects the browser using window.location to the location indicated in the first anchor’s href.

I’m using an neat jQuery trick here I haven’t talked about before:

$("a:first",this)

The “this” in the code above is a context selector, which is limiting the area in which we’re looking for the first anchor tag to the element that was just clicked. There is always a context applied to every jQuery expression you write: if you don’t specify a context, it uses the current HTML document. Here we’re limiting the context to the just-clicked list item, which reduces the complexity of our search (and presumably, calculation time) considerably.

That’s it? Yep! Five lines of code and you’re done! You can see a demo of this technique here.

A jQuery Plugin Alternative

Once I started working on this solution, I discovered that there’s already a jQuery plugin called BigTarget that does something rather similar to what I’m doing. If you’re in to jQuery plugins, definitely give it a look-see. If you’re planning to apply this in a lot of places, it’d probably speed up your development time. For my one-off use, however, I think five lines of code are preferable to a large plugin.

The Best CSS Newbie Articles of 2009

Rob Glazebrook — Tue, 05 Jan 2010 18:55:15 +0000

Happy 2010, readers of CSS Newbie! It’s a bitterly cold day here in Des Moines, Iowa — the sort that causes me to question the wisdom of throwing off the blankets in the morning. However, today I get to reflect on the last year of CSS Newbie, and that’s enough to warm my heart, if not my toes.

I’ve said it before and I’ll say it again: CSS Newbie is nothing without you awesome readers out there. This year, more than a quarter million people stopped by, visiting more than half a million pages. For that, I am very, very grateful. It also makes me excited to see what we can do for those numbers in 2010!

To celebrate the year gone by, I’d like to recap the Top 10 CSS Newbie Articles of 2009. The first five I’ve left up to you — they’re the five most visited articles in the last year. The second five were my choice. They include articles I enjoyed writing or include content that I thought particularly useful or interesting.

Readers’ Choice

Horizontal CSS Dropdown Menus. This was the clear winner of the popularity contest. Last year, more than 7% of the site’s pageviews went to this one article! Horizontal dropdowns must be a popular design tool these days.
Easy CSS Dropdown Menus. Another navigation article in the top five. These articles commanding the two top spots have inspired me to write more navigation-related articles recently and in the future.
The CSS-Only Accordion Effect. This article (and its successor, the Advanced CSS Accordion Effect) have received a lot of feedback, both positive and negative. The negative comments generally revolve around my ineptitude in the graphic design department. I’m comfortable with that, I think.
Show/Hide Content with CSS and JavaScript. This is one of those basic technique articles that people seem to have found really useful. Perhaps this indicates I should write more basics articles?
Equal Height Columns with jQuery. I’m happy to see this article make it into the top five — it’s a useful solution to a common problem!

Author’s Choice

15 Surefire Ways to Break Your CSS. This article was a ton of fun to write. Essentially, it’s a big list of what not to do — the opposite approach I normally take here.
Build Custom Frameworks Easily with CSS Classes. This article never got as popular as I expected — I blame an overly-verbose title. The article shows you how to build your own grid-based website without having to rely on the overly-complicated frameworks out there. Check it out!
How To Create Simple, Stylish and Swappable Image Captions. I had a lot of fun coming up with this technique and boiling it down to its bare essentials for the article. I received a lot of great feedback, and hope to release a new version this year.
A Super Simple Horizontal Navigation Bar. Navbars don’t get much simpler to build than this. This article is truly Navigation for Newbies, and is worth a look.
Advanced jQuery Tabbed Box Techniques. This article was more advanced and jQuery-heavy than my normal fare, but it contains tons of useful information and explains how to build a pretty useful product.

Have a Say

So that was 2009 in a nutshell. But now it’s time to look forward. What would you like to see from CSS Newbie in 2010? I’ve started a new poll in the site’s footer (also available below), and I’d love to get your feedback. What sort of articles would you most like to see appear here? You can select as many choices as you’d like. If you’d like to see something I haven’t thought of, leave me a comment below!

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Thanks again for a great year, folks. Let’s make this next one even better!

Build a Bare-Bones WordPress 2.8+ Widget

Rob Glazebrook — Mon, 21 Dec 2009 21:22:56 +0000

This tutorial is going to be a little more advanced than some of the fare around here, but in the end you’ll have all the information you need to know to create your very own WordPress widget! And that’s worth the effort, I think. However, you will need to understand a little bit of PHP for this to make much sense.

Widgets — essentially fancy drag-and-drop plugins, commonly used in sidebars — have existed in WordPress for quite some time, but with the release of WordPress 2.8, developers have a brand new widget API that makes creating widgets for WordPress a little bit easier. This tutorial will use the new system for developing our barebones “Hello World” widget.

Download the zipped source code here.

I should also note up front that this isn’t the only way to build a widget. This is simply the way I have learned, and a way that is compatible with the new WordPress 2.8+ widget API.

Make the Widget Appear

There are two things you need to do in ~any~ WordPress plugin, including widgets, to make it appear in your WordPress admin:

Give it a descriptive naming comment at the top, and
Drop it into the /wp-content/plugins/ directory.

Since we’re worried about the code here, let’s start with the naming comment.

Open any WordPress plugin, and you’ll see something very much like this at the top. The comment tells WordPress the name of the plugin, as well as who built it, where it can be downloaded, what version it is, and more. Note that all widgets are plugins, but not all plugins are widgets.

Many people also put copyright, GPL or MIT license information up here, but I’ve chosen to leave that out. Modify this to suit your specific needs.

Technically, this is all you need to make the plugin appear in your WordPress “Manage Plugins” list. But it won’t do anything until we give it some functionality!

Extending the WordPress Widget Class

WordPress 2.8 gives us a PHP class called WP_Widget that we can extend. This makes our development faster and keeps things somewhat consistent from place to place. The basic structure we’re going to use looks like this:

class WP_Widget_BareBones extends WP_Widget {
	function WP_Widget_BareBones() {
		// Construct goes here.
	}
	function widget($args, $instance) {
		// Our Widget Function
	}
	function update($new_instance, $old_instance) {
		// Our Update Function
	}
	function form($instance) {
		// Our Form Function
	}
}
add_action('widgets_init', create_function('', 'return register_widget("WP_Widget_BareBones");'));

We’re creating a PHP class for our widget that extends the base WP_Widget class. The class contains four functions:

WP_Widget_BareBones. You can call this whatever you want. It’s what tells WordPress what your widget is called in the program and loads all of our options when the time comes. It’s commonly referred to as the “construct” function.
widget. This, along with the next two functions, is a standard name that should not be changed. We’re overwriting a default class in WP_Widget with our own information. This one displays the widget on the screen when the widget is activated.
update. This saves our information when a change is made in the WordPress “Widgets” admin.
form. This generates the form we use to make changes in the “Widgets” admin.

The final line at the end, add_action, is loading our widget into the widgets_init list, which is called by WordPress when it’s ready to load all of the activated widgets. Without this, your widget will never show up on the page, so make sure it’s there!

Now let’s go through these functions one by one and fill them in.

The Construct

This is the function that pulls everything together and makes it work. Ours will look like this:

// The widget construct. Mumbo-jumbo that loads our code.
function WP_Widget_BareBones() {
	$widget_ops = array( 'classname' => 'widget_BareBones', 'description' => __( "A BareBones Widget" ) );
	$this->WP_Widget('bareBones', __('BareBones'), $widget_ops);
} // End function WP_Widget_BareBones

To be perfectly honest, this is the part that I understand least of all, but it works pretty much like this:

The $widget_ops variable gets loaded with an array that contains our widget classname (which has to be unique from all other widgets) and a brief description, which is used in the Widget display.
The second (and final!) line creates an instance of our widget, and loads it with the options array.

Clear as mud? No worries: this is all you need to do in this section. If you’re creating a widget of your own, just replace the “BareBones” stuff with whatever you want to call your widget, and then give it a description that makes sense for your application.

The Widget Function

The widget function is what creates our widget and outputs it to the screen. It pulls in two variables which are automatically provided by piggybacking onto the WP_Widgets class.

$args contains a list of standard widget variables — specifically, what should be displayed before and after your widget, and what to put before and after the widget title. These variables can be customized by individual WordPress themes, so it’s polite (and common practice) to include them.

$instance is a cool addition to widgets in WordPress 2.8+. Previously, you could only have a single copy of any widget running at any one time. But now we can have several instances (think: copies) of a widget running at once. And the $instance variable lets WordPress keep track of which copy we’re working with at any moment. It is an associative array that stores all of our widget-specific settings, which we set via the form function later.

Our code looks like this:

// This code displays the widget on the screen.
function widget($args, $instance) {
	extract($args);
	echo $before_widget;
	if(!empty($instance['title'])) {
		echo $before_title . $instance['title'] . $after_title;
	}
	echo "Hello world!";
	echo $after_widget;
} // End function widget.

First we’re using the extract() function to create the more recognized $args variables: $before_widget, $after_widget, $before_title, and $after_title. If you’ve ever done any WordPress template building, you’ve probably seen these before in the functions.php file.

Next, all we’re doing is echoing stuff to the screen. We echo $before_widget, then check to see if this instance of our widget has a title set. If so, we echo $before_title, our title, then $after_title. Then we echo a paragraph that says, “Hello world!” And we close by echoing $after_widget.

The Update Function

This function is used to save our widget information to the database. Every time someone goes into the Widget screen in WordPress and changes some options, this function will be called. Our is extremely simple:

// Updates the settings.
function update($new_instance, $old_instance) {
	return $new_instance;
} // End function update

As you can see, we get two variables to work with:

$new_instance, which contains all of our new information about this particular instance of the widget, and
$old_instance, which contains all of the previously saved widget information.

If we wanted to, we could write a bunch of code in here to make sure our variables are sanitary before writing them to the database, check them against the old variables, and whatever. All we’re doing here is returning the new information, which saves it to the database.

The Form Function

This form creates our widget administration panel on the Widget page in the WordPress control panel. We’re only going to have one editable option, the title, in this example. Complex widgets often have dozens of options, but once you see how to do one, the others should make sense.

// The admin form.
function form($instance) {
	echo '';
	echo 'BareBones Title:';
	echo '';
	echo 'This widget will display the title you choose above followed by a "Hello World!" statement.';
	echo '';
} // end function form

I’ve broken this code up over several “echo” lines just to make it easier to read and dissect; normally I would have done this all in one or two lines. But this makes it easier to see a few important variables to point out.

$this->get_field_id(“title”) calls a WordPress-generated ID for the title of our widget. I’m applying it to the label for usability purposes; if you include a for=”whatever” attribute in your labels, and then have an input with a matching ID, clicking the label selects the form.
$this->get_field_name(“title”) calls a WordPress-generated name field. This is important to have: WordPress uses it to assign and call database information.
We’re using $this->get_field_id(“title”) again within our input tag, as mentioned above.
We’re also putting $instance["title"] in our value attribute. This puts the current title in our text field. It’s an important usability consideration: without this line, people would type in a title, save, and the title would disappear! It’d be safe in the database, but the user wouldn’t know that.

It’s probably also worth noting that, although we’re including an input tag like you’d normally find in a form, we are not including a form tag.

Putting it All Together

And with that, we have a functioning widget! Our full code looks like this:

 'widget_BareBones', 'description' => __( "A BareBones Widget" ) );
		$this->WP_Widget('bareBones', __('BareBones'), $widget_ops);
	} // End function WP_Widget_BareBones

	// This code displays the widget on the screen.
	function widget($args, $instance) {
		extract($args);
		echo $before_widget;
		if(!empty($instance['title'])) {
			echo $before_title . $instance['title'] . $after_title;
		}
		echo "Hello world!";
		echo $after_widget;
	} // End function widget.

	// Updates the settings.
	function update($new_instance, $old_instance) {
		return $new_instance;
	} // End function update

	// The admin form.
	function form($instance) {
		echo '';
		echo 'BareBones Title:';
		echo '';
		echo 'This widget will display the title you choose above followed by a "Hello World!" statement.';
		echo '';
	} // end function form

} // end class WP_Widget_BareBones

// Register the widget.
add_action('widgets_init', create_function('', 'return register_widget("WP_Widget_BareBones");'));
?>

And when we upload it to our /wp-content/plugins/ directory and enable it on our Plugins screen, we’ll see the widget appear on our Widgets control panel.

And when we drag it into a sidebar, we’ll be able to edit the title to whatever we want.

And now, presuming you have a widget-enabled theme, your widget will show up automatically on your blog!

That’s all for today. In the future I hope to expand this tutorial into a second part, where we go through creating a more complex WordPress widget. Until then, if you’d like to download a copy of the BareBones WordPress widget for yourself, the source code (zipped) is available here.

A Full-Width Centered Navigation Bar

Rob Glazebrook — Thu, 17 Dec 2009 22:57:08 +0000

Right around the time I was developing the code for the Super Simple Navigation Bar I wrote about a while back, a friend came to me with an interesting problem. He needed a horizontal navigation bar like the one I was creating, with the following changes:

The navigation bar background should stretch the full width of the screen (not just the width of the centered content area), but
The navigation elements themselves should still be centered over the content area.

The sketch below outlines the basic design concept.

My friend had found some code elsewhere that did what he wanted, but it required two divs in addition to the navigation list to do its centering magic. He wanted to know if I could do it better.

This tutorial is the result of that challenge.

The HTML

I was able to reduce the number of extra divs required down to one. Sadly, I don’t think it’s possible to do this without at least one extra div — or turning to JavaScript instead of relying entirely on CSS.


	
		About Us
		Our Products
		FAQs
		Contact
		Login

If you’re familiar with the code for the Super Simple Navigation Bar, you’ll see it’s nearly identical, except that I’ve wrapped the ul tag in a div and moved the “nav” ID to that div.

This navigation code should be placed outside of your centered content container to allow us to stretch it the full width of the browser window in our CSS.

All in all, I think this is an acceptable amount of code for a navigation bar.

The CSS

Again, all I did here was take the previous navigation bar CSS and modify it a bit. The results are below:

#nav {
	width: 100%;
	float: left;
	margin: 0 0 1em 0;
	padding: 0;
	background-color: #f2f2f2;
	border-bottom: 1px solid #ccc;  }
#nav ul {
	list-style: none;
	width: 800px;
	margin: 0 auto;
	padding: 0; }
#nav li {
	float: left; }
#nav li a {
	display: block;
	padding: 8px 15px;
	text-decoration: none;
	font-weight: bold;
	color: #069;
	border-right: 1px solid #ccc; }
#nav li:first-child a {
	border-left: 1px solid #ccc; }
#nav li a:hover {
	color: #c00;
	background-color: #fff; }

Our #nav div is stretched to 100% of the browser window and floated left. The “float: left” rule might seem a little strange, because we don’t want anything to wrap around our navbar.

This is a little trick that takes advantage of how floats behave. If a container contains nothing but a floated element, that container will collapse down to a height of zero, because floating an element takes it out of the normal document flow. That is, unless the container is floated as well. Then, suddenly, our container only collapses down to the size of the contained float.

Why is this important? That’s what lets us set a background color and border on our #nav element and have it still appear. If the #nav weren’t floated, it would collapse to a height of zero, rendering our background and border invisible!

Next, we’ve given the “#nav ul” a fixed width and used the auto margin trick to center it. The width here is critical: you want it to be the same width as your centered content area. In this example, that’s 800 pixels.

I’m making use of one pseudo-class to interesting effect here. The “:first-child” pseudo-class applies to any element that is the first child in its parent. In our case, this rule is finding the first “li” in our parent “ul”. We’re then applying a border to the left side of the anchor tag inside. Without it, our first element wouldn’t have a border on the left like the others appear to have. While we could technically do that with a class or ID on the first element, I think this solution is a little more elegant.

The rest of the CSS is identical to that in our simple horizontal navigation bar and is mostly presentational. You can customize the colors, padding, hovers and everything else to make the navigation bar your own.

You can see this code in action here. Hopefully others will find this solution as useful as my friend did!

How To Create Simple, Stylish and Swappable Image Captions

Rob Glazebrook — Thu, 03 Dec 2009 23:46:41 +0000

While they say a picture is worth a thousand words, not every image is self-explanatory. Sometimes a few words of description or context can make the difference between a confusing image and a clarifying one. That’s why image captions are often a good idea.

I’ve always liked the idea of giving images captions, but I rarely do. And why not? It seems to me that most image caption solutions out there:

Require a lot of excess HTML,
Make it difficult to redesign (because of the rigidity, usually),
Don’t make the relationship between image and caption clear, or
All of the above.

Today, I propose a solution that addresses many — if not all — of these concerns.

You can view the demo here, or read on for the why- and how-to.

How Not To Do Captions

An example of an old-school way to deal with image captions might look like this:


	
		
	
	
		This is a caption for the image above.

One thing this solution does well is make the relationship between the image and the caption clear: items in the same column of a table are (or at least should be) related in some way.

However, it requires a ton of markup for something as simple as a line or two of related text. And let’s pretend you have a blog with 300 posts that contain images with this style of caption. What happens when, a year down the line, you decide the caption would look better above the image in the new design? There goes your weekend.

Here’s another example that’s much cleaner, but has problems of its own:

This image is swiped from Flickr.

This solution is nice and clean, but it makes a lot of assumptions. Your readers should assume, for example, that paragraphs following your images describe that image. Which may be true most of the time, but probably isn’t true all of the time.

And while you could give that paragraph a certain class or ID to style it more like a caption, code-wise they’re still semantically unrelated.

So what’s the solution?

The Goal

My goal was to create something that would:

Retain some resemblance to good, semantic code,
Keep my HTML as clean as possible, and
Be easy to style and restyle at will.

But in order to do any fancy CSS work, I’d need some hooks in my HTML. And adding more HTML makes it less clean, harder to revise in the future, and reduces my odds at keeping things semantically meaningful.

To solve this thorny catch-22, I turned (yet again) to our good friend jQuery.

The Solution

In order to keep my HTML clean, I decided to limit myself to a traditional image tag. Nothing simpler, right?

I also allowed myself the luxury of a special “hascaption’ class, but if all the images were going to have captions, this wouldn’t even be necessary. But then where does the caption come from? Well, why not the image tag itself?

Image tags have a “title” attribute which is supposed to contain extra information about the image. Extra, related information? That sounds like a caption to me! So let’s use it as such:

Now our caption is contained within our image tag, which is about as semantically meaningful as you can get. And we’re off to a good start: all modern browsers display image titles as a “tooltip,” which is sort of a poor man’s caption. But we want ours to be fancier, and styleable (you can’t style tooltips).

Here’s some jQuery that provides us a nice structure:

$(document).ready(function() {
	$("img.hascaption").each(function() {
		$(this).wrap('')
		.after(''+$(this).attr("title")+'')
		.removeAttr('title');
	});
	$(".figure").width($(this).find('img').width());
});

This code loops through our document and finds all the images with a class of “hascaption” and wraps them in a div called “figure”. Then it adds a paragraph after the image (inside the div) with a class of “caption”. It then fills the paragraph with the contents of the image’s title tag. Then it removes the title attribute to prevent the tooltip from competing with our caption (a bit extreme, but it works).

And the last line of code is a little trick that makes the “figure” div the exact same width as our image, so it only takes up as much room as necessary. If you chose to float your div or specify a predetermined width in your CSS, you wouldn’t need this line.

So now we have a rendered structure that looks more like this:


	
	This is going to be my caption!

This gives us plenty of hooks for some CSS/JS fun, but it didn’t require us to write any extra code by hand, and keeps our HTML looking clean. Anyone viewing the source will just see the original image tag, not the code above.

And best of all, if a year from now we want the caption to go above the image, it’ll only take changing one line of jQuery, versus changing hundreds of articles manually.

Adding Some Flair

I wanted these captions to have a bit of flair: the caption should appear directly on top of the image when the user mouses over (close visual proximity providing relevance), but disappear when the mouse goes away (so as not to clutter or obscure the image). For that, I needed a couple more lines of jQuery:

$(document).ready(function() {
	$("img.hascaption").each(function() {
		$(this).wrap('')
		.after(''+$(this).attr("title")+'')
		.removeAttr('title');
	});
	$(".figure").width($(this).find('img').width());

	$(".figure").mouseenter(function(){
		$(this).find('.caption').slideToggle();
	}).mouseleave(function(){
		$(this).find('.caption').slideToggle();
	});
});

And some quick CSS:

.figure {
	position: relative; }
.figure p.caption {
	display: none;
	position: absolute;
	bottom: 0px;
	left: 0px;
	margin: 0;
	width: 96%;
	padding: 5px 3%;
	background-color: #555;
	color: #fff;
	font-weight: bold; }

Note: The CSS above has been modified slightly from the original to account for an IE7 bug.

The jQuery is making use of the “mouseenter” and “mouseleave” functions built into jQuery. Whenever the mouse enters or leaves the space occupied by the “figure” div, the “slideToggle” function fires.

I think slideToggle is pretty cool: it “slides” the content in if it’s not currently there, and slides the content out if it is already present: it toggles between the two states.

The CSS is doing two primary things: setting a relative position on the figure div, and an absolute position on the caption paragraph. Then we just position the caption at the bottom-left of the figure using the power of absolute-inside-relative positioning (one of my favorite positioning tricks!). I gave the caption a nice dark background and made the text white and bold to provide plenty of contrast, but yours could be styled however you like. I’m also using a percentage width, plus a percentage padding on the left and right sides, to ensure the caption always stretches the entire width of the image.

View the whole thing in action.

Admittedly, this is really just a proof-of-concept and could probably stand to be cleaned up a bit. If there’s any interest, I might post a follow-up article that makes this a little prettier.