The Simple Secret to Good Dropdown Navigation

Published February 3, 2010 by saurav.roy.

Centered Navigation Bar - Click to see it in action!

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!). Read On…

Share and Enjoy !

0Shares
0 0

Improve Usability and CTR: Make an Entire List Item Clickable

Published January 12, 2010 by saurav.roy.

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: Read On…

Share and Enjoy !

0Shares
0 0

A Full-Width Centered Navigation Bar

Published December 17, 2009 by saurav.roy.

Centered Navigation Bar - Click to see it in action!

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:

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

The sketch below outlines the basic design concept. Read On…

Share and Enjoy !

0Shares
0 0

On Calendars, Lists, Tables and Semantics

Published July 2, 2008 by saurav.roy.

A couple of weeks ago, I wrote an article on creating a calendar using lists instead of tables. I was expecting a few people to find the concept interesting, and I was hoping for a little feedback from the web community. What I wasn’t expecting was the outpouring of comments and a very serious, fascinating debate on the semantic nature of calendars, the place of lists in web design, and more. And because I don’t think it’d be productive to just go through the list and respond to each comment individually, I thought I’d take some time and respond in a follow-up article. If you haven’t read the comments yet, I’d encourage you to do so first.

The first thing that I realized as the comments started to roll in was that my tutorial was fundamentally incomplete in a couple of vital ways. While I feel I did a decent job describing how to implement the technique, I fell short when it came to explaining how I envisioned the technique being used, or my reasoning behind what made using a list in lieu of a table such a useful idea. In other words, I’d covered the “how,” but not the “what” or the “why.” So I’ll cover more of that here.

I first came up with the idea for a list-based calendar at my 8-5 job as I was leafing through my appointments in Outlook. I thought about how useful it was to be able to switch between the month view, to the 7-day, to the 5-day, and so on as necessity dictated. I wasn’t restricted to just one view of my time: I had flexibility. And then I realized that even my day planner, an old fashioned, low tech paper product broke my time into months at the top of the page, but showed the days of my week in a more linear fashion.

And that got me thinking: was there any way to support that sort of flexibility in web-based calendars? I’d dealt with web calendars before: they were exclusively table-based and, as a result, fundamentally rigid. But what if, instead of turning to a table, I used a list? Then the data could be displayed linearly, like the 7-day calendar view of my planner, or in a grid like a traditional month-based calendar, as need dictated.

I was also thinking of my multiple-calendar setup in Outlook. I have two calendars: one for my meetings and appointments, which is generally useful in a month or week view, and one for my bills (I’m bad about remembering them!), which was really more useful as a list of dates. That convinced me even further that maybe a calendar didn’t need to be based on a grid.

I created my first test calendar with that flexibility in mind. I envisioned it being used in a scenario where it was sometimes useful to see things in relation to their days of the week or place in the month, and other scenarios where it was simply more useful to have things broken down by date. I figured it’d be an easy thing to set up bit of PHP or JavaScript to swap between two CSS files, changing the view on the fly. Of course, when it came to the tutorial, I focused exclusively on how to implement the idea, and neglected to mention why such an idea might be useful.

And that explains my thinking on the “what” and “why” portions of the tutorial. I was looking for a flexible calendar solution, one that wasn’t locked to the month-based grid.

Because — to get more into the semantics side of things — I would disagree with those that commented that a calendar was, fundamentally and semantically, a grid-based (and therefore table-based) entity. If calendars are married to the grid, why does my Outlook calendar have so many alternative views? Why does my day planner make so much sense to me at a glance, even though the days are arranged in a single column? Thinking of a calendar as exclusively month-based and grid-based is a narrow way at looking at the concept, considering all the alternative options we as a culture use on a daily basis.

And all that plays into the semantics of the calendar. Is a calendar, semantically, a grid? Sure, if you’re talking specifically of a month-based calendar. But I’d argue that my day planner is much more closely semantically related to an ordered list, and my Outlook calendar is like both, depending on what view I’m using at any given moment.

I can understand now why my calendar tutorial stirred up such a big semantics debate: my tutorial showed a calendar locked in a month-based, grid-like format. I didn’t mention any of my ideas on flexibility, multiple views, or the rest. And that resulted in well-reasoned retorts in the comments and even elsewhere: for example, Unintentionally Blank argued that I had presented a grid, but used a linear tool to do so, and thus wasn’t using the right tool for the job. Similarly, commenter Mark Aplet directed me to a recent post on his blog visual28, where he argued that designers were using lists for everything; that, essentially, lists were becoming what tables had once been in the web design world.

And the ironic part of it all is, I agree with both of those stances. Yes, I worry that designers overuse lists: I am opposed to the idea, for example, of using an unordered list as a basic structure for an entire website. And I would also agree that, if you’re presenting tabular data, there’s no better tool than a table to accomplish that aim. Which meant that my earlier attempts to respond to the debate raging in the comments all started with, “Yes, but…” Which is how this, longer and hopefully more clearly argued article came about.

So, what say you, semantically impassioned readers? If the goal is to create multiple calendar views with a single XHTML file, is a list an acceptable tool or am I still trying too hard to live off the grid? Does a calendar by any other orientation smell just as sweet? Let’s keep the debate alive: we’ll all end up coming away a little bit wiser.

Share and Enjoy !

0Shares
0 0

Easy CSS Dropdown Menus

Published May 12, 2008 by saurav.roy.

Attractive dropdown menus have long been the realm of Flash developers and advanced JavaScript gurus. But that needn’t be the case. This tutorial will walk you through developing a clean, semantic dropdown menu using XHTML and CSS that works in all modern browsers!

Let’s start with the XHTML first and foremost. It’s surprisingly simple:

<ul id="navbar">
	<li><a href="#">Item One</a><ul>
		<li><a href="#">Subitem One</a></li>
		<li><a href="#">Second Subitem</a></li>
		<li><a href="#">Numero Tres</a></li></ul>
	</li>
	<!-- ... and so on ... -->
</ul>

As you can see, our navigation bar consists of nested unordered lists and anchor tags. The key to this working correctly is to properly nest your unordered lists, wrapping the list item around the unordered list that is nested under it (for more on that topic, see this article on styling nested lists). The main list items will be our main navigation bar, while the nested unordered lists will become our subnavigation elements. The navigation bar also works without submenus, so you can mix and match as needs be. Also note that, other than an ID on our primary containing unordered list, there are no additional classes or IDs required!

Next, we’ll start adding a few styles to our navigation bar:

#navbar {
	margin: 0;
	padding: 0;
	height: 1em; }
#navbar li {
	list-style: none;
	float: left; }
#navbar li a {
	display: block;
	padding: 3px 8px;
	background-color: #5e8ce9;
	color: #fff;
	text-decoration: none; }

Here, I’ve removed the margin and padding from the main list, removed all list styling from all the list items, and floated the individual items left. I’ve also added a bit of styling to the anchors, just to make it look a little more like a navigation bar. As you can see, this really isn’t any different than making any other sort of navigation bar to start out with.

The only real oddity here is the “height: 1em;” rule on the navbar ID: this forces the navbar to have a specific height (1em) and width (100% by default), meaning I don’t have to do anything special to “clear” the navigation afterwards. Without that rule, I’d generally need to apply a “clear: left;” to whatever came immediately after the navigation to prevent it from trying to fill the space voided by those left-floated list items. The actual height is arbitrary: as long as a height is specified, the list will retain its block-level status.

Next, we can apply some styles to the subnavigation section:

#navbar li ul {
	display: none; 
	width: 10em; /* Width to help Opera out */
	background-color: #69f;}

This is pretty straightforward: we’re applying a display: none to prevent the submenu from displaying by default, and giving it a background color to make it stand out against the background. The only odd bit is the width property, which is mostly there to prevent Opera from doing some weird things with the width of the submenus (Opera makes them strangely small without a width specified). However, it also ads a nice bit of consistency to the submenus, so I don’t really mind the “fix.” I chose 10em because that allowed all of my submenu items to exist on one line, but you could choose whatever size works for you.

Now all we need to do is style the list for its “hover” state:

#navbar li:hover ul {
	display: block;
	position: absolute;
	margin: 0;
	padding: 0; }
#navbar li:hover li {
	float: none; }
#navbar li:hover li a {
	background-color: #69f;
	border-bottom: 1px solid #fff;
	color: #000; }
#navbar li li a:hover {
	background-color: #8db3ff; }

Let’s go through this bit by bit. The first rule causes the submenu to reappear when the user hovers over the containing list item (this is where the properly nested lists come in handy). We’re using position: absolute on the menus to ensure they don’t push any content below the navigation out of the way. The margin and padding are simply getting rid of the default spacing on the lists so we can style them ourselves.

Next up comes the “float: none” rule on the list items. This is just preventing the items in the submenu from floating left: it’s counteracting our previous “float: left” rule so that our submenu doesn’t mimic our main navigation elements.

The rules we’re applying to “#navbar li:hover li a” are purely stylistic: I’m applying a background color, bottom border, and changing the color of the anchor. You could set these to be anything you wanted whatsoever.

And finally, I’m applying a different background color to the anchor when it’s being hovered over, just to help set it apart from the other items in the list. This is to improve usability: the user can easily see which item their cursor is over.

That’s all it takes! You can see a working example here. I’ve tested this and found it working in Firefox 2, IE7, Opera 8.5+, and Safari for Windows. Of course, you’ll note that I’m leaving out the usual party pooper: Internet Explorer 6. Because of IE6’s limitations on :hover states (you can only hover over anchors in IE6, instead of any element like in all the other browsers), this fantastic little technique doesn’t work. Unless, of course, you’re willing to add in a couple of lines of JavaScript.

The brilliant hive mind that is Patrick Griffiths and Dan Webb have come up with a fantastic JavaScript solution for Internet Explorer that solves the :hover problem in just 12 lines of code. The version I’m using looks like this:

sfHover = function() {
	var sfEls = document.getElementById("navbar").getElementsByTagName("li");
	for (var i=0; i<sfEls.length; i++) {
		sfEls[i].onmouseover=function() {
			this.className+=" hover";
		}
		sfEls[i].onmouseout=function() {
			this.className=this.className.replace(new RegExp(" hover\\b"), "");
		}
	}
}
if (window.attachEvent) window.attachEvent("onload", sfHover);

The concept is pretty brilliantly simple (even if the code looks complex). The function goes through your document and finds every list item contained within the “navbar” id (you could change this to be whatever you wanted). It then applies a “mouseover” and “mouseout” state on every item: it adds a class of “hover” to the list item whenever it’s being moused over, and removes it when the cursor wanders off. The result is you can then apply your CSS to the .hover class as well as the :hover pseudo-class and create identical results across the board. So all you need to do is modify your CSS like so:

#navbar li:hover ul, #navbar li.hover ul {
	display: block;
	position: absolute;
	margin: 0;
	padding: 0; }
#navbar li:hover li, #navbar li.hover li {
	float: none; }
#navbar li:hover li a, #navbar li.hover li a {
	background-color: #69f;
	border-bottom: 1px solid #fff;
	color: #000; }

And that’s it! With just three tiny changes to your CSS and a dozen lines of JavaScript, you have a CSS dropdown solution that works on every single modern browser – even the ones that aren’t exactly standards-compliant.

Share and Enjoy !

0Shares
0 0

Writing CSS Shorthand

Published April 7, 2008 by saurav.roy.

"Jeri Rowe" by spcoon.

Writing Cascading Style Sheets saves you time and bandwidth in the long run by removing all of the presentational elements and attributes from your web pages and moving them into a separate document. But sometimes that CSS document itself can get pretty long as well. So what do you do then?

There are lots of things you can do to help – embracing the cascading nature of CSS helps a great deal, as does combining CSS declarations using sequential selectors. But another trick that can really help cut down on the size of your CSS is to use CSS shorthand properties whenever possible. There are six shorthand properties for various areas of your CSS: margins, padding, borders, backgrounds, list-styles, and fonts. I’ll go through each of them below.

The margin shorthand property combines the margin-top, margin-right, margin-bottom, and margin-left properties into one single property. So instead of writing this:

div {
	margin-top: 5px;
	margin-right: 8px;
	margin-bottom: 3px;
	margin-left: 4px; }

You could shorten it all down to this:

div { margin: 5px 8px 3px 4px; }

It’s important to remember to always put your margins in the shorthand property in the following order: top, right, bottom, and left. Basically, just start at the top and work your way around the element clockwise. And if your top/bottom and left/right margins match, you can boil your shorthand down even further:

div { margin: 5px 8px; }

The rule above applies a 5 pixel margin to the top and bottom of your div, and an 8 pixel margin to the left and right sides. If all four of your margins match, you could even just write this:

div { margin: 5px; }

The padding shorthand property works exactly the same way as the margin shorthand. The biggest thing to remember about both of these properties is to start at the top and work your way around clockwise. And if you’re shortening it to two values, the top/bottom value always goes first, followed by the left/right value. Further, if you don’t need to specify a value on any one of the sides, you can just specify a zero (0) size with no unit of measurement.

div { padding: 30px 0; }

The border property allows you to combine the border-width, border-style, and border-color properties into one. The width comes first, followed by the style, and then the color. So instead of writing out all this:

div {
	border-width: 3px;
	border-style: solid;
	border-color: #c00; }

You could boil it down to a single rule, like so:

div { border: 3px solid #c00; }

The background property is fairly powerful, in that it combines five rules into one: background-color, background-image, background-repeat, background-attachment, and background-position (in that order). So instead of writing this verbose mess of code:

div {
	background-color: #fff;
	background-image: url(../images/bg.gif);
	background-repeat: repeat-y;
	background-attachment: fixed;
	background-position: top center; }

We could boil all of that down to this little snippet:

div { background: #fff url(../img/bg.gif) repeat-y fixed top; }

Also note that I skipped the “center” portion of my background-position property: if you specify one background position (i.e. “top”) but neglect to specify a second position value, “center” is the assumed value.

The list-style shorthand property isn’t used all that often, but it can save you a couple of lines of code. It combines the list-style-position property with either of the list-style-type or list-style-image properties – you could probably specify both, but list-style-image would overwrite the list-style-type property with whatever image you selected. So instead of writing this:

ul {
	list-style-type: square;
	list-style-position: inside; }

You could write this:

ul { list-style: square inside; }

Generally speaking, however, I tend to only use this shorthand when I’m looking to remove styling from the list (as when building a navigation bar):

ul { list-style: none; }

The font shorthand property is probably the most powerful of all the shorthand properties. It combines a grand total of six properties into one: font-style, font-variant, font-weight, font-size, line-height (even though it’s not technically a font property), and font-family. So instead of writing out all six of these rules:

p {
	font-style: italic;
	font-variant: small-caps;
	font-weight: bold;
	font-size: small;
	line-height: 1.2em;
	font-family: Helvetica, Arial, sans-serif; }

I can get by with a single declaration:

p { font: italic small-caps bold small/1.2em Helvetica, Arial, sans-serif; }

Of course, most of the time you won’t be specifying all six of those properties at once – I can’t even imagine how difficult it would be to read italicized, bold-faced small caps! But it is very useful for specifying your font-size, line-height, and font-family all in one place. That way, all of your typeface information sits one convenient location.

Share and Enjoy !

0Shares
0 0