Archive for ‘markup’ category

Microformats for Designers

In a little less than two months, I’ll be heading to Vancouver to speak about “microformats for designers” at Web Directions North. It’ll be a fun topic, and I’m starting to put together the material. I’m looking forward to talking about microformats from a designer’s perspective, including a little bit about the logo development, the implementations over at Cork’d (and the unexpected cool things that came out of that), as well as applying CSS to microformats.

But I’m also looking for help. What are some interesting things happening with microformats and design? Know of any great examples, visual experiments, etc.? Here are a few to get started:

I know there’s a lot happening out there, so let’s hear about it. And thanks!

Pairing Wine and Microformats

While working on Cork’d, I realized this was a perfectly fine excuse to implement some microformats. What goes great with a nice 2003 Pinot Noir? Meaningful markup, naturally.

We’re currently using three microformats on Cork’d:

  • hCard (for member profiles)
  • hReview (for wine reviews or “tasting notes”)
  • rel-tag (for indicating tag links)

Our implementations aren’t perfect, but it’s a start. The rest of this article will talk about how we implemented hReview for member-entered tasting notes (example) and specifically how I used CSS to style the markup.


(more…)

Bulletproof Logos

There are a few browsers (Firefox, Opera) that treat image alt text as if it were normal text on the page, when the image isn’t present. If the reader turns images off to save bandwidth, we can still visually treat the images by styling the alt text, and this could be especially handy in regards to site logos.

(more…)

When Floated Figures Attack!

I recently began publishing full entries in the RSS feed for SimpleBits, figuring that if people would rather read the entire Notebook post in the comfort of their aggregator, they could go ahead and do so. Personally, I enjoy reading content in its intended environment, with all the site design around it, and find myself skimming NetNewsWire for interesting articles to pull up in a browser later on.

(more…)

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.

SimpleQuiz › A List › Conclusion

This was another easy one — but as expected the discussion got more interesting as additional related questions were asked. The question itself is becoming secondary to the conversation happening alongside.

Notable Comments

Overwhelmingly, it was D all the way. I guess I sort of gave it away, orginally titling it “Part II: Unordered Lists”. We’ve learned some good stuff here though.

web:

Yeah, I’d go with D as well, but to be noted is the lack of KitKats in your list.

Dully noted.

Michael Z.:

There are a few situations where code like A could be used, though. Marking up a poem, for example.

Which prompted others to ask about using pre or br / to markup a poem. Tough to call,
and even the W3C uses a poem as an example of both methods.

Folkert:

Did anyone ever fall into the trap of identifying every bit of content on a page as a list, ordered and unordered? I was that close to declaring the bodytext on a page as an inline ordered list.

In fact, Doug Bowman pointed me to Tantek Çelik’s move to using a series of lists
to handle most of his weblog’s structure.

Also certainly worth a look again, is Doug’s Overused Lists? article — where he explores the differences between using pipe-delimited vs. an unordered list for navigation. The pipe-delimited method could’ve easily been option E in this quiz question, and may have divided the results a bit.

Michael Z.

I think even one item can constitute a list.

And according to the W3C, this is true.

Paul G.:

You’d have to change the stylesheet and the markup if you wanted to do something as simple as add a border around your list.

Exactly. Using a ul makes it easier to change styles with CSS.

Matt Haughey poses some questions that are far more intriguing than the quiz itself:

When should someone put something in a list instead of using line breaks? How to do screenreaders interpret lists?

To which Patrick H. Lauke responds with perhaps the most insightful information of the discussion:

… yes, they do treat lists differently from normal text broken up by line breaks. JAWS, for instance, announces that it’s an “unordered list with 5 items”. I imagine other screenreaders will provide similar information.

That to me, is a huge reason for using lists when in doubt. And after being asked whether the declaration of how many list items there are would be a hinderance to blind users, Patrick went on to offer this:

… they will know how many links there are (i.e. whether it’s only 5 items or 50), which will influence how they will choose to navigate the site.

I realize I could go on quoting everything else — because there are other great points raised as a result of another seemingly ELEMENTary (sorry) question.

Summary

A simple list of items should most likely be structured with a ul element. Why is the better way?

  • D is more easily styled with CSS without having to modify the markup.
  • Using a ul to markup lists makes it easier for screenreader users to hear how many items are contained.
  • An unordered list may be better represented in a small screen such as a phone or PDA — where unintentional line-wrapping may occurr.

SimpleQuiz › Part I: Headings

In response to Jason Kottke’s post on semantics and markup, I thought I’d try out a new series here called SimpleQuiz (I know… but it’s better than “Markup Quiz” or “Web Standards Quiz”). The objective is to ask some questions about markup and generate some discussion about preferred methods.

I may very well become either too busy or bored to continue these on a regular basis, but we won’t know until we begin. The hope is that these questions and answers would become useful little bits of information. I also won’t pretend to be the authority on any of these subjects. I may very well be asking the question because I’d like to hear how others would handle it as well.
So here goes… the first one is a doozy. Sure it’s incredibly obvious — but we have to start somewhere, and should probably make no assumptions.

Q: Which of the following is more semantically correct? (For the title of a document)

  1. <span class="title">This is a Title</span>
  2. <h1>This is a Title</h1>
  3. <p><b>This is a Title</b></p>