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

How To Emulate a Foreach Loop in JavaScript

Published January 21, 2010 by saurav.roy.

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

Share and Enjoy !

0Shares
0 0

Combating Classitis with Cascades and Sequential Selectors

Published March 10, 2008 by saurav.roy.

stethoscope

There is a disease out there in the CSS world. It can afflict anything from the meanest weblog (or the nicest ones too, I suppose) to the greatest of corporate websites. It’s called Classitis, and I’ve encountered it far too often in my professional work. Perhaps you’ve seen it too. It looks a little something like this:

body {
	font-family: Arial; }
h1 {
	font-family: "Times New Roman"; }
h2 {
	font-family: "Times New Roman"; }
p {
	font-family: Arial; }
p.ArialRed {
	font-family: Arial;
	color: red; }
p.ArialRedBig {
	font-family: Arial;
	color: red;
	font-size: 150%; }
ul {
	font-family: Arial; }
ul.ArialRed {
	font-family: Arial;
	color: red; }
strong.redArial {
	font-family: Arial;
	color: red; }

This particular snippet of (completely fictional) horribly afflicted CSS suffers from multiple problems which could all probably be considered symptomatic of Classitis, even when they don’t directly involve classes. I’ll go through the five of the most glaring problems and how to remedy them below.

The Cascading ability of CSS is ignored. Notice how many times the “font-family: Arial;” rule is applied? This is a waste of space, and ignores the fantastic cascading ability of CSS (which I’ve covered elsewhere). Once the appropriate font family had been applied to the body tag (the first rule in our example), all of the additional “Arial” family declarations, because they were identical and were inherited from this first declaration, became redundant.

Simple and identical rules are repeated.
Take a look at the rules for the <h1> and <h2> tags in the example above. They use a different font-family than the body tag, so it’s appropriate that they have a rule making that change. But why repeat the rule twice? With CSS, you’re allowed to list sequential selectors, separated by a comma. Instead of the rule above, we could’ve written this:

h1, h2 {
	font-family: "Times New Roman"; }

Different classes have an identical effect. Consider the rules “ArialRed” and “RedArial” above. They do exactly the same thing, but the designer was in such a hurry, they accidentally created two rules that mirror one another. Always stop and consider when you’re writing your CSS if there’s any way to consolidate your rules. If you have to write the same rules multiple times, the answer is probably “yes.”

Classes are applied to multiple elements. There are two instances of the “ArialRed” class in the example above. One is being applied to a paragraph tag, while the other is being applied to an unordered list. There’s no need for this redundancy. By eliminating the “p” and “ul” portions of the two selectors, those classes can be consolidated into a single instance.

Class names are super long. This is the classic symptom of Classitis from whence the name derives, much like how chicken pox is named after the chicken-shaped virus that causes it (no? Well, you figure it out then). Designers sometimes get in a hurry and start building classes for every possible design difference they encounter. This can most easily be combated by remembering two things:

First, as I’ve mentioned before, elements can have multiple classes. Instead of having a class of “RedBig,” why not break it into two classes? Then you can style elements that need both classes like this:

<p class="red big">
  This text is now red and big.
</p>

Second, classes should describe what an element does, not what it looks like. A class of “red” is great when you’re first building a site, but what happens three months down the road when you decide that you want your emphasized text to be blue? A class of “.highlight” or something similar to indicate the text should stand out in some way would have been more appropriate. Of course, even seasoned developers tend to break this rule every once in a while.

So, after we apply all of the advice offered above, what are we left with? Something that looks a little like this:

body {
	font-family: Arial; }
h1, h2 {
	font-family: "Times New Roman"; }
.highlight {
	color: red; }
.shout {
	font-size: 150%; }

Ahh… nice, healthy CSS, without all of the bloating Classitis inevitably causes.

Of course, these are just a few of the pitfalls of redundancy and excess that designers can fall into when developing their CSS. If you can think of others, share them in the comments.

Share and Enjoy !

0Shares
0 0