Build Custom Frameworks Easily with CSS Classes

Published March 10, 2009 by saurav.roy.

Woodsmith Shop columns

Generally speaking, I consider full-fledged CSS frameworks to be overkill on all but the most absolutely complex projects or, on the other end of the spectrum, rapid proof-of-concept prototyping. Most people only use a few of the classes that any one CSS framework provides, but then still require their users to download the entire, and largely unused, stylesheet.

However, I still think that the foundation on which CSS frameworks are built — the concept of using classes to simplify layout and standardize design across similar elements — is very much worth investigation. But instead of relying on a one-size-fits-all (snuggie-esque?) solution, I’d encourage you to take a few minutes and build a custom, simplified framework that does exactly what you need it to do. Read On…

Share and Enjoy !

0Shares
0 0

Build a Tabbed Box with CSS and jQuery

Published January 18, 2009 by saurav.roy.

tabbed box

The longer a site has been around, the more content it tends to accumulate. As website operators, we walk a fine line: too much content on every page and your site will look cluttered. Too little, and users won’t be able to find all your website has to offer. A tabbed box like the one pictured above is a nice bridge between the two extremes. It allows you to show off a large amount of content without cluttering up a lot of space. And this tabbed box has extra niceties that are sure to help your content get noticed.

What it Does

At the end of this two-article series, you’ll be able to build a tabbed content box of your own that:

  • Is easily customized to fit the size and color scheme of your website.
  • Is either fixed or variable height.
  • Can automatically rotate through the tabs to draw interest.
  • Pauses its rotation when the user interacts with it.

This article will show you how to take the tabbed box from Photoshop to XHTML and CSS, and how to apply the basic jQuery functionality to make the tabs operate. The next article will show you some advanced jQuery techniques to make your tabbed box even more dynamic and eye-catching. Read On…

Share and Enjoy !

0Shares
0 0

Understanding XHTML Semantics

Published October 15, 2008 by saurav.roy.

\"Semantopoly\" photo by dharmasphere. Used under a Creative Commons license.

Even those of you in the audience who are new to web development (or perhaps just new to the site) have still probably heard the word “semantics” or the phrase “semantic development” thrown about in various web-related conversations (and if not, I certainly hope you will soon!). But what does that phrase really mean? Today, I want to take a brief step back from our normal how-to fare to talk about why we do things the way we do them: the semantics that guide our development.

A Definition of Semantic Development

So what does this whole “semantics” thing mean? In web development, we use the term to refer to using tags that describe what something is instead of what it looks like. Or to put it another way, as Dan Cederholm states in his fantastic book Web Standards Solutions:

[W]e’re striving to use tags that imply meaning, rather than a presentational instruction. Are you dealing with a list of items? Then mark it up as such. Is this a table of data? Then structure it that way.

So in short, when we’re talking about semantic development we’re looking for a way of separating our structural information from our presentational information. And luckily, we have all the tools we need right in front of us. CSS is a presentational language; stylesheets affect the appearance of objects, not their underlying structure. This means we can use XHTML to create our structure (and only our structure), and move all of our presentational stuff into our CSS.

Understanding Unsemantic Markup

Now that we have a definition in mind, let’s look over a few examples of what semantic markup is not. Once you get comfortable playing “spot the not,” the definition will start to make a lot more sense.

Here’s an example of how not to create a large heading for your blog posts:

<p><b>Semantics, Schemantics</b></p>

And here’s another:

<div class="headingBig">Why Konqueror Rocks</div>

Now admittedly, with the right CSS to back up your mad XHTML hackery, either one of these could end up looking like a perfectly legitimate heading on the screen. So what’s all the fuss about?

These examples are unsemantic for two reasons. Both of our examples are using tags (or classes) that don’t have anything to do with headings to create a heading-like effect. This is a faux pas because we have a tags at our disposal for the express purpose of creating headings: namely, the <h1> through <h6> tags. A good portion of writing semantic code is simply knowing the tools (tags) at your disposal and when to use them.

Of course, there isn’t a single tag for every use case, so sometimes we just have to do the best we can. And sometimes that causes debates within the community, because oftentimes complex problems can be solved with several different, arguably semantic, solutions — like when I argued that a calendar could be represented using an unordered list instead of a table (you can also see my follow-up article here).

Second, our first unsemantic heading example is using a presentational tag. In XHTML, at least, the <b> (bold) tag is generally frowned upon, precisely for the reason of semantics. The difference between a boldfaced word and a roman word is a presentational one — the bold tag doesn’t offer any semantic information about the text it wraps. That’s why XHTML offers the options of using the <strong> tag instead. The strong tag simply suggests that the word/phrase/whatever that it wraps is text that is somehow stronger than its surrounding text. The tag doesn’t dictate how that text should be strengthened… only that, semantically speaking, the text contained within is comparatively stronger. We can then turn to CSS to determine how our strong tag should be treated in our document.

Tips for Semantic Markup

So how can you help ensure that, moving forward, you’re generating logical, semantic markup instead of sloppy, structural-presentational code soup? Here are a few suggestions to help you along the way:

  • Know your options. Unless you’re the guy (or gal (okay, probably guy)) that wrote the XHTML specifications, there are probably more XHTML tags out there than you know. This XHTML Cheat Sheet might be a nice place to start learning more.
  • Think structurally. When you’re writing XHTML, try to boil things down to what they truly are, instead of worrying about what they’re going to look like when your site is done. Theoretically, a well-designed structure should be able to accommodate all sorts of different designs without having to change. That’s the idea behind the CSS Zen Garden, though admittedly their XHTML is pretty darn verbose to give the designers plenty of “hooks.”
  • Code inside the box. XHTML is an amazingly flexible language, but sometimes its easier for me to code semantically if I treat my XHTML like I would a language that was going to be interpreted by machines instead of humans. Your computer doesn’t care what a heading looks like — it cares that it can classify certain data as headings. This has the added benefit of resulting in pages that machines (like Google’s bots) do understand… resulting in a nice SEO boost in the end.

If you have any more tips, things that you do to help yourself code more semantically, I’d love to hear about them in the comments. Drop me a line!

Share and Enjoy !

0Shares
0 0

Horizontal CSS Dropdown Menus

Published May 20, 2008 by saurav.roy.

Last week, CSS Newbie reader Andrea Pluhar wrote in with an interesting problem: she wanted to use CSS dropdown menus like the ones we featured last week on a website that she was building, but the design called for the submenu to be arranged horizontally, not vertically. She sent me a mockup of what she was after (excerpted above) and wondered if there was a way to accomplish this effect using CSS. It turns out that there is a CSS-riffic way to do this, and in the spirit of maximizing benefit, I thought a tutorial would be in order.

The XHTML involved is identical to that used in our regular dropdown menus: a nested unordered list, where the nested lists become the submenus. It looks something like this:

<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>

Next we’ll move to the CSS. I started out by moving the navigation bar to the top-right corner, like the design called for, removing the list styling, and floating the items left to make them line up in a row:

#navbar {
	position: absolute;
	top: 0;
	right: 0;
	margin: 0;
	padding: 0;}
#navbar li {
	list-style: none;
	float: left; }

Next, I styled the primary anchor tags to make them look more like the navigation Andrea was looking for. The code looks like this:

#navbar li a {
	display: block;
	padding: 3px 8px;
	text-transform: uppercase;
	text-decoration: none; 
	color: #999;
	font-weight: bold; }
#navbar li a:hover {
	color: #000; }

I’ve added a bit of padding to the link, and used the text-transform property to make everything uppercase like the mockup called for. That way, the original XHTML can be lowercase or camel-case (capitalized first letters)… which would be a little easier to read in an unstyled document.

Next up, we hide the nested lists by default, and then style them when the containing list item is hovered over:

#navbar li ul {
	display: none;  }
#navbar li:hover ul, #navbar li.hover ul {
	position: absolute;
	display: inline;
	left: 0;
	width: 100%;
	margin: 0;
	padding: 0; }

The code above is the bit that really makes most of this magic work, so I’ll explain the important parts in some detail. First, because IE6 doesn’t support hover states on anything other than anchor tags, we’re writing our rules to account for the hover state and a hover class. This class is applied to elements when they’re being hovered over, using an ingenious little bit of JavaScript (which is explained in this previous dropdown menu tutorial).

Next up, we’re absolutely positioning our nested lists and using the “left” property to move the list to the left-most side. This isn’t moving the list to the left-most side of the screen, but instead the left-most side of its parent positioned element, which in this case happens to be the main unordered list that we positioned right at the start. As such, this trick relies of the whole list being positioned in some manner, even if it’s just relatively positioned and left in place.

The display: inline rule is a little more complicated. So much so, I don’t even completely understand what it’s doing. What I do know is, without that rule, the list items in the submenus simply don’t show up whatsoever in any major browser. I think it has something to do with the fact that the containing elements are floated (which we’ll get to in a bit), but I can’t prove that. If anyone has any better insight into the technical aspect, please let me know in the comments.

Lastly, the width: 100% rule is somewhat important. It’s preventing the unordered list from collapsing down to a smaller size in certain browsers. Specifically, without setting this width specified, the nested list sometimes collapses to the size of its “containing” list item (even though it’s absolutely positioned and therefore technically no longer contained). Note that older versions of Opera don’t deal well with the 100% width… if you want it to work on older versions, you’ll need to specify a width according to a definite size (such as pixels). However, the most recent version of Opera (9.27) handles it fine, and I get the impression that Opera users tend to upgrade more frequently than, say, IE users.

Finally, we just float the elements left (to put them in a nice horizontal row), and give them some colors:

#navbar li:hover li, #navbar li.hover li {
	float: left; }
#navbar li:hover li a, #navbar li.hover li a {
	color: #000; }
#navbar li li a:hover {
	color: #357; }

And that’s it! You can see a working example here. This has been tested and works fine in IE 6+, Firefox 2, Safari (Mac and PC), and Opera 9.27.

The only portion of the mockup I wasn’t quite able to duplicate was a way to keep the primary menu item highlighted when the submenu was in use: because the nested list is absolutely positioned, the browser doesn’t seem to consider them a matched set any longer (except, it seems, in terms of default width). If anyone has a solution to this bit, I would love to hear about it!

Thanks to Andrea for inspiring a hopefully useful tutorial! And if you ever have a CSS-related question that you think might make a good article here, don’t hesitate to send me a message, either via my contact page or on Twitter. I can’t guarantee I’ll use every question posed, but I’ll do what I can as time and situation allow.

Share and Enjoy !

0Shares
0 0