As with all facets of web design, there are many ways to do a task and get the same (or similar) results. This chapter presents methods for making lists using XHTML and how the lists will look on a variety of devices, including handhelds. (From the book Web Standards Solutions: The Markup and Style Handbook, by Dan Cederholm, from Apress, 2004, ISBN: 1590593812.)
Most competent browsers will insert a bullet to the left of a list item when the <li> element is used. One might use Method B to achieve those results, adding the <li> by itself when a bullet is desired. However, some of those same competent browsers won’t display the bullet when an <li> element isn’t contained within one of its proper parent, the mighty <ul>. The <li> 's other parent is the <ol> element, for “ordered lists,” which I’ll discuss further on in the book.
The bullet does help the wrapping issue to a certain extent. A new grocery item would be signified by a bullet, to its left. If an item wraps to the next line, the absence of a bullet should be enough to distinguish itself from being a whole new item. But there is something else wrong with Method B, aside from its resulting display: It’s not valid.
According to the W3C’s XHTML 1.0 specification, all tags must eventually close—and if we were to go ahead and open an <li> for each grocery item, without closing it at the other end as in the example, shame on us!
We’ve mimicked the automatic line-breaking that occurs when a proper unordered list is used by adding the <br/> tag at the end. But there’s a better way.
It’s valuable to get used to the idea of writing valid markup, consistently. By ensuring our markup is valid, we’ll worry less about problems that may occur because of unclosed or improperly nested elements in the future. Not to mention that if anyone else is looking at our code, it’s easier for everyone involved to dive in and understand exactly what’s going on.
Be sure to use the W3C’s online validation tool (http://validator.w3.org/) to validate your files by URI or file upload. You’ll be happy you did in the long run.
Method C brings us closer to a preferable solution, but fails miserably in one potentially obvious way: It’s still not valid markup. We’ve closed each <li> tag properly, and since they are block-level elements, using them eliminates the need for a <br/> tag, putting each list item on its own line. But, we’re miss ing an outer layer of structure, lacking a containing element that denotes “This group of items is a list!”
It’s also important to view this from a semantic angle as well—that the list is a group of items that belong together, therefore they should be denoted as such. Furthermore, using proper list tags says very clearly to the browser, software, or device, “This group of items is a list!” A good example of how semantic markup is about structuring items for what they are.
Block level vs. Inline: HTML elements can inherently be either block level or inline. Block-level elements begin on their own line, followed by a line break, while inline elements are rendered on the same line as other inline elements. Block-level elements can contain other block-level or inline elements, while inline elements can’t contain block-level elements.
Some examples of block-level elements include <div>, <h1>-<h6>, <form>. Some examples of inline elements include <span>, <storing>, <em>, <q>.
If we were to look at our grocery list in purely an XML sort of way, we might choose to mark it up as shown in this example:
The entire list has a containing element,<grocerylist> , that all of the grocery items belong to. Grouping the items in this manner will make life easier for XML-based applications that may want to extract the items from the list.
For instance, a developer could author an XSLT style sheet that would transform this list of items into XHTML, plain text, or even a PDF document. Because of the predictable nature of a group of list items, software will have an easy time taking the information and doing something useful with it.
While I’m not dealing with XML in this book directly, the principles are carried over to the world of XHTML. Providing a meaningful structure to our markup gains flexibility later on. Whether it be the increased ease of adding CSS to properly structured documents or the improved manageability of making changes to markup that is easy to understand— providing that structure will make for less work later on down the road.
Let’s take a close look at Method D and see how this all fits together—providing a structure that the most browsers and devices can read, while also allowing us to style our list in several different ways.
So what makes Method D so special? First and foremost, it’s completely valid. A proper unordered list has a containing <ul> element, with each item within wrapped in opening and closing <li> elements. Now just when you think all we’re going for here is demonstrating how to be valid for valid’s sake, we’ll take a look at it in action.
Because we’ve properly marked up our grocery list, each item will be on a separate line (due to the block-level nature of the <li>) and most visual browsers will render a bullet next to each item, as well as indent any wrapping lines that may occur (see Figure 1-3).
Figure 1-3. Default rendering of an unordered list
Users of PDAs, phones, or other small-screened devices will also be able to view the list in a similar, clearly organized fashion. Because we’ve told the device what the data is (a list in this case), it can best decide how to display it according to its capabilities.
If a long line wraps due to increased text size or a narrow browsing window, the wrapped line will appear indented to line up with the text above it. It’ll be darn clear to distinguish between items no matter what the browsing circumstances.
Now that I’ve picked each possible method apart, let’s quickly review what I’ve covered about each:
Leaves out the possibility for styling the list uniquely
Could create confusion when longer lines wrap in a narrow column or small-screened device
Lacks semantic meaning
Adding a bullet helps for signifying a new item, but some browsers may choose not to show it, without its parent <ul> element.
No containing <ul> element or closing </li> elements means difficult to style.
Closing the </li> element eliminates the need for <br/> tags.
Omitting the <ul> element makes it difficult to style this particular list differently.
Provides semantic meaning and structure.
Bullets will render to the left of each item on most browsers.
Wrapping lines will indent on most browsers.
It can be easily styled uniquely with CSS.
As you can see, you can learn a lot from a seemingly innocent little question. Even if you’re already using Method D exclusively on all of your pages, it’s nice to know why you do things the way you do. We’ll continue to explore such “why” questions throughout the book, giving you more ammunition to make the best choice at the right time.
For extra credit, let’s look at a few different ways we can take advantage of our marked-up grocery list, using CSS to style it several different ways. We’ll throw away defaults, add custom bullets, and then turn it horizontal for a few navigation bar ideas.
This chapter is from Web Standards Solutions: The Markup and Style Handbook, by Dan Cederholm (Apress, 2004, ISBN: 1590593812). Check it out at your favorite bookstore today.