Archive for 2003

SimpleQuiz › Smart Linking › Conclusion

Certainly some great discussion on smart hyperlinking methods. Many like B over the other three examples. I think I like this one best as well. The link is surrounding the description of exactly what it’s pointing to. Using a title attribute can be helpful if for some reason the text you’re using isn’t descriptive enough, or to name the document you’re linking to.

Option C’s use of “Click here” text was a hot topic of discussion as well. I tend to think, in general, it’s not always a good idea for the following reasons that many of the readers shared:

  • Not everyone uses a mouse to navigate a web page, therefore the word “Click” doesn’t make sense for every situation.
  • If “Click here” text is used repeatedly on a page, a screenreader that reads off a list of links found on that page would basically be saying “Click here. Click here. Click here.” over and over again. Being more descriptive about what the link is will help.
  • Visually scanning the page for links would reveal little about what is being linked to.

Another thing to keep in mind, and this was brought a few times, is how being descriptive when building links can help search engine spidering.

SimpleQuiz › Part IX › Smart Linking

To mix it up a bit, I thought I’d offer this quiz question from Egor Kloos. It sort of borders on the topic of usability — finding the best way to hyperlink something in context.
What method will make the best impact? What we link, and where, is a simple way of improving a site’s readability. But what do you think?

Q: When linking to something that appears more than once within a sentence, where is the best place create that link?

  1. <a href="#">The W3C's section on HTML has been used by many designers as a reference to build better sites.</a>
  2. The <a href="#">W3C's section on HTML</a> has been used by many designers as a reference to build better sites.
  3. The W3C's section on HTML has been used by many designers as a reference to build better sites. <a href="#">Click here</a>.
  4. The W3C's section on HTML has been used by many designers as <a href="#">a reference to build better sites</a>.

See previous quiz questions and wrap-ups in the archive.

Styling Nested Lists

Recently, I was building a site map and realized that it is basically an outline of sorts. So how should I go about marking it up? I settled on a series of nested tables — ha! gotcha — nested unordered lists.

The Raw Markup

At their very basic — nested, unstyled lists deliver the exact hierarchy I was looking for. I could feel good about the structure that all browsers and devices would read, while easily styling it with CSS later on.

A simple version might look something like this:


<ul>
<li>Weblog</li>
<li>Articles
   <ul>
   <li>How to Beat the Red Sox</li>
   <li>Pitching Past the 7th Inning
      <ul>
      <li>Part I</li>
      <li>Part II</li>
      </ul>
   </li>
   <li>Eighty-Five Years Isn't All That Long, Really</li>
   </ul>
</li>
<li>About</li>
</ul>

Figure 1 below shows us how the markup above will render in most browsers. Woilla. A site map or outline. But let’s kick it up a notch (apologies to Emeril).

figure 1
Figure 1

Adding Style

Let’s say that we’d like some definition for certain levels of the site map. All we really need to add to the markup is an id so that we may style this particular list differently from any other lists that may be on the same page, without any additional markup:


<ul id="sitemap">
<li>Weblog</li>
<li>Articles
   <ul>
   <li>How to Beat the Red Sox</li>
   <li>Pitching Past the 7th Inning
      <ul>
      <li>Part I</li>
      <li>Part II</li>
      </ul>
   </li>
   <li>Eighty-Five Years Isn't All That Long, Really</li>
   </ul>
</li>
<li>About</li>
</ul>

Using descendant selectors, we can give a unique style to each separate level of the list. For instance, if we’d like the higher levels to be large and bold and the inner levels progressively smaller, we’d first set the size and weight for entire list:


#sitemap {
font-size: 140%;
font-weight: bold;
}

That will make the entire list big and bold. So next we’ll reduce the size and turn off bolding for li elements that are nested at any level below:


#sitemap {
font-size: 140%;
font-weight: bold;
}
#sitemap li ul {
font-size: 90%;
font-weight: normal;
}

figure 2
Figure 2

This means that all top level items will be big and bold, while all lists that are nested within will have a normal weight and font-size of 90% (which in this case is 140% of whatever the page default is). Figure 2 above shows the result.

We don’t even need to assign a smaller size for the third level, as it’ll automatically apply 90% of 90% (a little confusing, but it works!):

Now we have a descending font-size for each level of the list.

Custom Bullets

Let’s turn off default styling, and add a decorative bullet for only third level items by using the background property. We’ll first turn off list styling in general for all li elements, then we’ll specifically assign a background image for third level items:


#sitemap {
font-size: 140%;
}
#sitemap li {
list-style: none;
}
#sitemap li ul {
font-size: 90%;
}
#sitemap li ul li ul li {
padding-left: 16px;
background: url(bullet.gif) no-repeat 0 50%;
}

figure 3
Figure 3

Figure 3 shows the resulting list with a custom bullet applied only to third level li elements. We’ve added 16 pixels of padding on the left to account for the width of the decorative bullet image we’re using (plus a bit of whitespace). We’re also telling the browser to align the image 0 pixels from the left and 50% from the top, which essentially aligns the bullet to the left and center of the text. While we could’ve used a pixel value here, using a percentage allows for similar bullet placement if text is resized.

Conclusion

For building outline-like lists, nesting uls makes for a structurally sound — and easily styled solution. By assigning a single id to the top-level ul, we can let CSS do all the hard work of styling each level separately — without the need for extraneous presentational markup. And possibilities for creative styling go way beyond this simple example.

Designing in Public

Hats off to Dave Shea for his redesign of Mozilla.org (publicly released beta). Nice, clean design and structured markup. It’s a great contribution to the project.
Also of interest are Dave’s notes on the response of the beta, and what’s left to tackle.
In general (and as Dave mentioned), thick skin is needed when designing a popular site (like Mozilla.org). Validation, accessibility, design choices, browser quirks — just a few of the hurdles to leap over when redesigning any site — but are then magnified ten fold when dealing with something larger than your average personal site or weblog.
The reality? Getting everything 100% “correct” is hard stuff.
Feedback is important and necessary, and trying to break a design — turn it on its head and shake out the bugs — can be invaluable. But what’s important is this: when all is said and done, any attempt in making gains in validation, accessibility, markup structure, etc. make the web site better than it was. And if you fancy yourself a web designer, your first gesture should be a tip of the (Red Sox) cap to anyone who dares.

Mid Pass Filter: Toward a Hackless Future

Just recently, Tantek revealed his Mid Pass Filter — a handy way of sending IE5.x/Win external CSS styles that all other browsers will ignore. Pretty neat.
I’ve read a few comments regarding the method, which complain of its somewhat messy syntax. My first reply would be “isn’t any hack is somewhat messy?”, but more important is the concept — keeping all IE5.x hacks in one file makes for a nice tidy cleanup when these browsers reach the Netscape 4.x threshold.
This of course could be years down the road, but I like the idea of keeping standards-compliant CSS completely separate from the various hacks that are often necessary to render a design in 2003.
The more methods that use this separation, the better. Imagine a time when getting your CSS 100% hackless is only a matter of removing the import of a single file that’s merely filled with all those old hacks. It’s a nice idea, anyway.

Perhaps a Book

Rally Cap
Rally cap by web

Stemming from the SimpleQuiz, I’m looking rather seriously into putting the question and answer concept into a book. The scope would most likely be more of a “web standards FAQ” — with topics on structured markup as well as CSS tricks and tips and anything related.

What I’m looking for is a little help…

  • What topics would be important to you in this type of book?
  • What are common questions that one would come up against when diving into standards-compliant design/development?

The format is looking to be much the same as the Quiz: a series of topics each with a question posed, followed by exploration of available options, summary and extra tips based on the topic.

I’m open to hearing any and all suggestions. Feel free to email me directly as well. Thanks, fine people.

Accessible Image-Tab Rollovers

I recently implemented a new navigation system for Fast Company and thought it’d be useful to document the process.

The Problem

We needed to fit more items into FC’s top navigation. We ran out of room. Previously, this was handled by a simple, styled unordered list. But at a window resolution of 800×600 there wasn’t enough additional horizontal space to add even one more item using the current design.

The Solution

I choose to combine and modify Pixy’s brilliant Fast Rollovers and Stuart Langridge’s accessible image replacement technique to create accessible, Javascript free, image-tab rollovers.

How does it work?

The XHTML: One List to Rule Them All

I wanted to continue to use a simple unordered list for the navigation in the markup. Much has already been said about using lists for navigation, here and elsewhere. They’re compact, lightweight and accessible to text browsers, screenreaders, PDAs, phones, etc.

Here’s what the list looked like originally (I’ve deleted some of the actual items to make it more convenient to demonstrate):


<ul id="nav">
<li><a href="/" class="selected">Home</a>&lt/li>
<li><a href="/guides/">Guides</a>&lt/li>
<li><a href="/magazine/">Magazine</a>&lt/li>
<li><a href="/articles/">Archives</a>&lt/li>
</ul>

Nice and simple. Now let’s add a unique id to each li so that we can do some fancy stuff with it (namely, replace the boring text with stylized tabs):


<ul id="nav">
<li id="thome"><a href="/" class="selected">Home</a>&lt/li>
<li id="tguides"><a href="/guides/">Guides</a>&lt/li>
<li id="tmag"><a href="/magazine/">Magazine</a>&lt/li>
<li id="tarchives"><a href="/articles/">Archives</a>&lt/li>
</ul>

Now we’re ready to create some tab images.

One Image, 3 States

The essence of Pixy’s Fast Rollovers involves creating one image for each navigation item that includes normal, hover and active states stacked on top of each other. Later, we’ll use CSS to change the background-position to reveal each state at the appropriate time.

fig. 1
Figure 1.1

Figure 1.1 on the right shows an example image that I’ve created and used for Fast Company’s new navigation. Each state is 20px tall with a total image height of 60px. The top 20px is the normal state, the next 20px shows the hover state and final 20px shows the active state (which is also used for the “you are here” effect). There are similar images for each tab we’d like to use.

Using one image for each state allows us to toss out ugly Javascript and instead make use of simple CSS rules for hover effects. This is good. It also eliminates the “flicker” effect that other CSS methods suffer from, where separate on/off images are used. This is good. We also don’t have to pre-load any additional images. Again… this is good.

The CSS: This is Where the Magic Happens

First we’ll set up the rules that all navigation items will need. This will save us from writing duplicate rules for each tab. Then we’ll add a separate rule for each list item id, giving the li it’s own background-image and width — the only two variables that will be different for each tab.

The CSS goes something like this:

#nav {
margin: 0;
padding: 0;
height: 20px;
list-style: none;
display: inline;
overflow: hidden;
}
#nav li {
margin: 0;
padding: 0;
list-style: none;
display: inline;
}
#nav a {
float: left;
padding: 20px 0 0 0;
overflow: hidden;
height: 0px !important;
height /**/:20px; /* for IE5/Win only */
}
#nav a:hover {
background-position: 0 -20px;
}
#nav a:active, #nav a.selected {
background-position: 0 -40px;
}

This essentially turns off padding and list styles, makes the list horizontal and hides the text that’s between each hyperlink in the list. Notice the :hover and :active rules. These are generic for every a element within #nav so that we don’t have to repeat those particular rules for each item.

I’ve also assigned a “selected” class to a tab that I wish to highlight permanently, signifying which section of the site you are currently on. This is shared with the :active state.

You may also notice that list-style: none; and display: inline; are repeated in both the #nav and #nav li selectors. This was to keep IE5/Win happy. In a perfect world, declaring this once for #nav would be perfectly sufficient. That’s not the case, of course.

Next, we’ll add the rule for each id and assign it’s background-image and width. Here’s an example:

#thome a  {
width: 40px;
background: url(home.gif) top left no-repeat;
}

There’s a similar declaration for each tab needed.

The Results

fig. 2
Figure 1.2

Figure 1.2 shows the resulting tabs in normal, hover and selected state. To see it all working in action, check out the working example with sourcecode, or better yet, the real-world implementation at fastcompany.com.

Why use it?

  • It’s lightweight: Just an unordered list in the markup.
  • It’s accessible: Using Stuart’s method, we can insure screenreaders will read the text links.
  • No Javascript: We don’t need to pre-load or create multiple images for each state. We also don’t need extra Javascript to control hover effects. Thanks, Pixy.
  • It’s stylized: Fitting hypertext into defined areas can be tricky, this allows for using stylized images.

But Wait, the Text Doesn’t Scale!

Following a great suggestion from Doug Bowman, and in response to legibility issues and the inability to resize image text, I went a step further and created second set of tab images with larger text labels. I could then override rules on the exisiting “medium” and “large” alternate stylesheets. The alternate styles are activated using Paul Sowden’s Stylesheet switcher.

An example of the overriden rule looks almost identical to the original, with a new width and image path:

#thome a  {
width: 46px;
background: url(guides_lg.gif) top left no-repeat;
}

fig. 3
Figure 1.3

Figure 1.3 shows the larger tabs as they appear on Fast Company, where you’ll notice that the horizontal spacing is tighter while the vertical size remains the same as the original. But, by adding the ability to increase the size of hypertext as well as the tab images we’ve helped out low vision users, while still working with our certain design constraints. Thanks to Doug for this solution.

Compatibility

Tested and working in Windows: Mozilla, Netscape7, IE5.0+; Mac: Mozilla, Camino, IE5, Safari.

Specifically for Fast Company, I choose to position: absolute the #nav in order to make things line up perfectly, letting the background color of the header area show through underneath. This works fine and dandy — except in Opera7/Win where specifying a width is necessary for absolutely positioned elements (ugh). That’s OK though, we’ll just add the total width of the images (added up) to the #nav:

#nav {
margin: 0;
padding: 0;
height: 20px;
list-style: none;
display: inline;
overflow: hidden;
width: 201px;
}

Now we can sleep at night, and Opera fans rejoice.

Special thanks to Paul Maiorana for letting me bounce ideas off of him (repeatedly) at the office.

About the Talking About Semantics

I feel the need to take a time-out and regroup in regards to the SimpleQuiz.

What’s the point in arguing about semantics? XHTML is not a semantic language.

I agree — it may never be a purely semantic language. I sort of wished I had never used the word “semantic” in the questioning of the quizzes. What we’re trying to get at here is whether one method of markup has any benefits over another. That’s it. Call it semantics, call it preferred methods, call it advantages and disadvantages, etc. The bottom line is that talking about this stuff (as mundane and ridiculous as it can get) can be beneficial.
Sure, at times we’re all splitting hairs and to some it may seem like an absolute waste. But, call me crazy, it’s fun talking about the million different ways to markup a list or a form or a heading — and hearing how others may do it differently. I also hope to broaden the questions to handle CSS methods and tricks.
So, the intention is to question the whole idea of semantics, when they’re helpful or when they ain’t — not to preach some “golden way” of writing web pages. I’ll be the last to want to adhere to a single way of marking up XHTML. Sometimes, a tag is a tag is a tag, and instead of worrying about what’s right we should go outside and toss the football around (or kick the football around for all you non-Americans).
Allright. Had to get that off my chest. Now back to work. The next quiz will be on how XHTML files with odd numbered byte sizes are more semantically correct. (Just kidding).

SimpleQuiz › Titles › Conclusion (sort of)

Where do I begin? This one has no obvious answer, and didn’t really intend to. In fact, very few of these questions really intend to have a definitive answer. And the following is my attempt to absorb the illuminating comments (and they are always illuminating) and make some sense of them.

Let’s get right to it. Book titles. Right. The title of a book. Think about seeing a book title in print — in a magazine or another book. A book title is normally set in italics. It’s a visual clue. It’s strictly presentational. Now think about a book title on a web page. We still want that visual clue — italics, but we also want all browsers and devices to know that this is a book title as well.

Moby Dick. I just used i. Is that any good? Well, using i is strictly presentational, it’ll give us the italics we want, which is good. But:

The only real difference is that i‘s nomenclature disregards all but visual browsers. (full comment)

When using i, visual browsers will render the book title in italics, but others may not.

Looks like B is out.

But non-visual browsers will recognize em you say? Great! But, do you really want the the title of a book to be emphasized (read faster and/or louder)? Probably not, so A is out — although I’m plenty guilty of using it.

So what about cite? Many dispute the relationship of cite in regards to a book title — if you’re simply stating the title of a book, are you really citing it? I suppose I could go either way on that one. One could argue that you are, in fact, citing the book title even when stating it without following quotations. cite also has the benefit of being rendered in italics in most (?) browsers — by default and without additional CSS rules. How many I could not tell you definitively, and that would be an interesting tidbit of information.

A fourth option would be to create a custom class and attach it to the span tag such as <span class="title">This is a Book Title</span>. But this to me is the same as using i — strictly presentational and if you wanted to be hilariously ridiculous you might point out that it would cost you a few more bytes for the span tag and associated CSS rule. Silly, but…

So the moral of this quiz question is: use one of the four methods and move on. Each of them has their respective advantages and drawbacks. Take those into account in the real world, make a choice and feel good in knowing that you may have some extra information on why you made it.