Are Lists Becoming the New Tables?

Posted February 15th, 2008 by Mike Cherim

Misusing specific elements in a way not intended, especially for presentational purposes, while creative and admirable on many levels, simply isn’t right.

A number of years ago some members of the scientific community and the United States government were involved in a new way to share text and data documents over phone lines. This became the Internet. It didn’t take long for people, call them web designers, to adopt and subsequently exploit this technology by using and even misusing the use-specific elements interpreted and rendered by “web browsers.”

Good Tables Gone Bad

One such element was quickly identified as being extra exploitable. That, of course, was the data table element and all of its descendants. Web designers figured out that they could manipulate the size and proportion of table rows and cells, fill them with colors and pictures, and basically construct what we still see a lot of on the web today: nice looking but fairly inaccessible web pages completely laid out and styled with data tables. In a big way this was a huge step forward for the industry because the creative potential of this new medium was realized and more widely embraced. Web pages started popping up all over the place. But like many rapid advancements in technology, there was a bit of a downside:

First of all it was like the Wild West what with everyone doing their own thing, busting the envelope and convention at every turn.
Second, a basic tenet of the web, access by everyone regardless of disability, was being shattered by this rampant creativity.

As I mentioned in the first paragraph, web designers were misusing “use-specific elements interpreted and rendered by ‘web browsers.’” The key phrase in that is use-specific. By misusing these elements, their value — and thus their inherent meaning — was (is) being obscured. This resulted in the web becoming more and more inaccessible. Things were spiraling out of control. Thankfully, some of the more visionary members of the web design community, folks like Jeffrey Zeldman, recognized this and decided it was necessary to have and use web standards. To keep web designers on the same page, and to keep those who make web browsers and other user agents talking. Both parties communicating their needs bidirectionally.

The result was the more wide-spread (and still spreading) adoption of web standards. This, to its own credit, helps to ensure the accessibility of the web. Web designers are getting back on track, and together, are making the web a better place — for everyone. But it may be happening again…

History Repeating Itself

The adoption is not so wide-spread this time (yet), but there’s a movement afoot. This time it’s not the table element that’s being misused, instead it’s list elements. I see it more and more each week: extremely creative ideas coming from some of the masters of the craft resulting in the abuse and misuse of lists.

At this point I’m torn. Do I show you examples? Some of the people at the front of this movement are people I respect and admire. They’re even friends in some cases. If I mention names and link to them it might not be appreciated. I don’t want to embarrass anyone, I just want to nip this trend in the bud before it becomes more widely adopted by those who will believe the practices are a step forward. I have decided to let them come forward on their own if they wish to defend their point of view. They can comment here or write their own post supporting their stand. I will mention a few quasi-generic examples, though:

Lists for Forms

First on the chopping block is the use of lists (and other non-form elements) to layout web forms. The arguments are almost convincing. Such as, a web form is a list of inputs. But not convincing enough; I don’t buy it. Forms are forms and lists are lists. Forms have their own elements, and lists have theirs. Granted, anything can be stuffed into a list item, but that’s not an invitation to go nuts. Rather it is an accommodation to meet needs, not wants. Forms have their own organization, and their ordering is already dictated by their natural source order. Nothing needs to be added to this, not even the tabindex attribute in most cases. It is true that forms can be difficult to style. Cross-browser consistency has been one of the arguments for using lists to lay out forms. And that does have appeal. But put another way, such as, it’s okay to misuse elements for presentational purposes, and you should see the practice is treading on very shaky ground.

Lists for Addresses

A street or mailing address is a single body of information. While it’s true that it is made up of different bits of information, street, city, country, postal code, etc., (just like a sentence is made up of words), these are not list items and as such they shouldn’t be organized in a list. If anything is used, assuming the instance doesn’t justify the use of the address element, the paragraph element, p, would be the best choice. I mention this one because it was brought up in my article about using breaks and I felt maybe this probable usage should be smacked around more.

List for Web Pages

This one pains me. I know a brilliant developer whom I consider a friend. He has devised a way of using ordered lists (ol) to layout an entire web page. A basic example: List item one is the header; list item two is the content, list item three is the sidebar, and list item four is the footer. Despite the fact the order of the web page is already dictated by the natural source order, he felt this was beneficial… hey, no div elements is good, right? I disagree with the alleged benefits and argue that this is complete element abuse. So strongly do I feel about this, that it is highly unlikely I could be convinced otherwise. Anything can be listed if one uses enough imagination, but this is what happened to data tables. In the case of a web page made from an ordered list, what if someone jumps to a particular location on said page? So much for order.

A List Calendar

This one is really dumb. And I can link to it because it was my own brainchild: using a list to create a calendar. I will freely admit, I was so wrong about this experiment that it’s almost embarrassing, but if I can’t include my own fallibility, then I shouldn’t be talking about that of others, even if I’m not mentioning names. A calendar should not be organized in a list. A data table should actually be used as it is the best fit. Thinking of weeks as list items was way off the mark. I’m not ashamed. Please note that the site on which this is featured is for experiments. Not all are worthwhile (though some are good). Originally the domain was just my own playground, but I have about a zillion subscribers to my feed over there. Thus, I have updated the page to explain it shouldn’t be used. Others really need to follow through to this end by disclaiming their own wild and crazy experiments.

The Fat Lady Sings

Ah, lists. So what are they really for and how should they be used? Well, here’s an article I wrote about using lists properly that may help you understand their proper purpose. Is the information I wrote debatable? Sure it is, always. But is it wrong? I really don’t think so. It all comes down to web standards and the proper use of elements. Thus, there’s not much to argue about. If doing it the right way proves too challenging, the only choice is to rise to said challenge. Misusing specific elements in a way not intended, especially for presentational purposes, while creative and admirable on many levels, simply isn’t right. The fat lady has sung.

Filed under Wicked Wild Web, Access Counts, Coding & Markup —

33 Responses to: “Are Lists Becoming the New Tables?”

Rich Pedley responds:
Posted: February 15th, 2008 at 3:37 pm →

Hi Mike,

Interesting write, and no I won’t comment about the using a list for a web page!

But I disagree in 2 places. Firstly using lists for forms. For overall layout of a form I do agree, but I have used a list quite a few times to list a series of checkboxes. This is surely semantically correct usage?

Secondly, a calender. So far as I am concerned a Calender is one of those things that can either be a table, or a list. What is a calender? is it not a list of dates.
Mike Cherim responds:
Posted: February 15th, 2008 at 5:18 pm →

Hi Rich. If the checkboxes represented, say, a “List of your favorite things - check all that apply” then I’d have to say maybe (but at a stretch in my opinion as I feel there would be a better way). I think I’d rather see a fieldset for the grouping, a legend for the “List of your favorite things - check all that apply” changed to “Check your favorites” so it didn’t sound too verbose with a screen reader, then label/input combos for each checkbox input. To display them in a linear fashion I’d use breaks.

As far as a calendar being a list of dates. That would only be true if the dates were in a list if what I’m saying makes sense. Otherwise it would be a calendar and I feel that should be in a table due to the way a traditional calendar is structured via associated rows and columns. Just take one look at my horrible experiment sample with styles off and its flaws seem terribly obvious. It looks organized with styles on, but with styles off it’s really quite a mess I think.
John Faulds responds:
Posted: February 15th, 2008 at 7:12 pm →

Interesting that you’ve written this now Mike because I was thinking more about lists this week after a discussion on WSG on whether you should use paragraphs inside lists. I was surprised that people thought that once a list item contained more than one paragraph that the usage of a list in the first place should be reconsidered. I mean there must be thousands of blogs whose comments are marked up as lists!
Mike Cherim responds:
Posted: February 15th, 2008 at 7:32 pm →

The comments on this blog are in an ordered list, which I think is somewhat okay, the ordering is natural to the source so the ordered part isn’t really needed. They are also listed by date so that helps reinforce the source ordering. Being listed does serve one purpose, though, by organizing all the comments into a single collective structure that effectively separates them (otherwise everyone’s name would have be a sub-heading). That’s why I haven’t bothered to address this on my theme. It’s iffy both ways.

As far as entering multiple items in a list, I don’t really have an issue with that. I did see that discussion, more than once I think. Many, moderately large blocks can be served well if organized in a list (unnecessarily so at times I’d say). All of this is strongly dependent on the content and its relationship to the content it’s sharing the list with, as well as the importance of needing all list items in a collective structure more dominant than what one would get from paragraphs under headings. One way to look at it, I suppose, during that critical time when deciding what mark-up to use to best serve the content, is to perhaps imagine the content in a book or a magazine. I can’t recall a time that I’ve ever seen really large blocks of content organized in list style. It’s typically smaller chunks. Following that style might be best on the web, too.
Dan Schulz responds:
Posted: February 16th, 2008 at 12:41 am →

Hi Mike,

Thank you for posting this. I’ve been railing against the use of lists to mark up forms since I first saw them in action (I won’t say where for obvious reasons), especially since form controls are not list items to begin with. I’m glad to see that someone who’s as widely recognized and respected as yourself feels the same way as I do on this.
Joe Dolson responds:
Posted: February 16th, 2008 at 12:43 pm →

Actually, I think that the definition of a calendar is a bit more flexible than what you’re describing. Now, I agree that your experimental calendar-in-a-list layout is a bad idea — but just because I see no benefit to taking a list and displaying it as a table. If something is going to be displayed as a table, then it should be marked up as a table.

However, the definition of “calendar” encompasses more than just “A table showing the months, weeks, and days in at least one specific year.” (American Heritage Dictionary, 4th edition). Other definitions include “An ordered list of matters to be considered,” (same source) “a list or register of events” (WordNet).

The physical object of a calendar is traditionally laid out as a table, and if you are attempting to replicate that display model, then you should use a table. However, if you are attempting to render a list of events, this should absolutely be in a list — but it’s still a calendar.

In fact, a calendar could easily have multiple calendar layers: a global table structure which models the days within a month, and a list structure which models the calendar of a single day’s tasks.
Mike Cherim responds:
Posted: February 16th, 2008 at 1:01 pm →

The physical object of a calendar is traditionally laid out as a table, and if you are attempting to replicate that display model, then you should use a table. However, if you are attempting to render a list of events, this should absolutely be in a list — but it’s still a calendar.

I agree, Joe. That’s what I meant when I wrote…

As far as a calendar being a list of dates. That would only be true if the dates were in a list if what I’m saying makes sense. Otherwise it would be a calendar and I feel that should be in a table due to the way a traditional calendar is structured via associated rows and columns.

…in response to Rich. But I stand corrected on the hard and fast definition in the quote above so I concede that if appearing as a list it may still be called a calendar. I just meant if the calendar is to be display in the more traditional format, then a table should be used, but if a person wants to display it as a list then a list element would be perfect — a cleverly used ol might be just the trick.
John Faulds responds:
Posted: February 16th, 2008 at 10:14 pm →

One way to look at it, I suppose, during that critical time when deciding what mark-up to use to best serve the content, is to perhaps imagine the content in a book or a magazine. I can’t recall a time that I’ve ever seen really large blocks of content organized in list style. It’s typically smaller chunks.

Magazines and newspapers probably not but it’s definitely something that is done in academic texts.
Jermayn Parker responds:
Posted: February 17th, 2008 at 10:42 pm →

I have been saying this for the last few months now and so yes I agree with you!
Erik van Beek responds:
Posted: February 18th, 2008 at 6:37 am →

At this point I’m torn. Do I show you examples?

For one moment I thought you weren’t showing examples for fear people might actually copy them if they look good
Georg responds:
Posted: February 18th, 2008 at 7:59 am →

As long as elements can be used for presentational purposes, they will also be misused for presentational purposes. Disconnecting actual and contextual value from presentational value, is some times impossible, and most web designers tend to weigh presentational value way above any other value since that’s the only value they - and their clients - can actually see in the finished product.

That we can modify the visual appearance of any element and its content with CSS, means all elements can be used badly. Consequently: they are.
Most examples, demos and “real world designs” are built on a markup chosen for its stylability - not semantics. If a semantically valid section isn’t stylable enough for comfort, markup will be thrown at or around it almost regardless of the effects this has on semantics. So, the simple fact that we need elements as “style-hooks” or for their “default visual appearance”, is enough to make “good markup go bad”.

Pro-arguments are often easier to find and defend than con-arguments, since con-arguments usually have to cover the whole base while pro-arguments can often be limited to the case at hand and the mindset/preferences of the author.

The often repeated argument that “this sequence can be seen as a list, so we can safely use a list” is anything but an argument for using lists. It is an argument for oversimplification.
Some sequences are perfect for lists, but most sequences are “accidental” - content just happens to be sequenced and grouped in a certain way, but doesn’t necessarily have to be sequenced and grouped that way, or at all, in order to make sense.

“Accidentally sequenced and grouped content” should be contained in markup-elements that makes most sense on all levels for the case at hand, not “shoehorned” into the author’s “preferred markup”. Pity it’s sometimes so hard to figure out what makes most sense.
Stevie D responds:
Posted: February 18th, 2008 at 8:19 am →

Georg:

The often repeated argument that “this sequence can be seen as a list, so we can safely use a list” is anything but an argument for using lists. It is an argument for oversimplification.
Some sequences are perfect for lists, but most sequences are “accidental” - content just happens to be sequenced and grouped in a certain way, but doesn’t necessarily have to be sequenced and grouped that way, or at all, in order to make sense

A list doesn’t have to be a sequence to be a list.

My shopping list is
* 1lb mince
* 1 tin tomatoes
* 2 onions
* 1 packet fresh pasta

There is no sequence there - when I’m going round the supermarket whether I pick up the mince or the pasta first. I could re-write the list in any order without affecting the success of the purchase. [ul] lists generally don’t have a sequence.

My recipe is:
1. Fry the mince and onions
2. Add the tomatoes
3. Put the pasta on to boil

There is a sequence this time - if I boil the pasta before I start cooking the mince, it will have gone cold before the rest of the meal is ready. And even I’m not that bad a cook.
Karl responds:
Posted: February 18th, 2008 at 10:12 am →

Thoughtful article with equally good comments. I think that some people really stretch the idea of “if it’s repeating content then I can use list markup” - like marking up content blocks in a sidebar as an unordered list. The litmus test may be “what does it look like without CSS?” I’ve seen content that has over-used lists to such a degree that the site had about 20 bullet points with no apparent hierarchy - no headings - and just didn’t make sense as a result.

Can I sit on the fence and say “it depends”? I’d like to think responsible developers would have mulled over the pros and cons of what they’re about to do (or copy) before going list-tastic on a website.
rob responds:
Posted: February 18th, 2008 at 11:40 am →

I did the “list for a layout” thing as an object lesson for one of my reports a little while ago and I ended up writing it up for the web.

One of the things I was wondering while writing it up, was if anyone out there was using the technique out in the wild. Reading this, I guess they are? For my money I’m happy to have it remain “in theory” only.

A Three Column CSS Layout Using Just an Unordered List
Georg responds:
Posted: February 18th, 2008 at 1:26 pm →

Steve D

You’re presenting examples that are perfect for unordered/ordered lists, and I’m not arguing against the use of lists for those examples.

My use of the word “sequence” as meaning “arranged order”, may not have come through as I intended. Almost everything we put in a document comes in an “arranged order”, or can be seen that way if one wants to, without necessarily making it suitable for lists.

Sentences expressing lines of thoughts usually must be grouped and read in sequence to make sense, but clearly paragraphs are usually more suitable for marking them up even if they are sequenced as “a list of thoughts”. OTOH: sentences and whole paragraphs may be placed in lists for grouping or to strengthen the order they must be read in.

I may also argue that a sequence of links does not necessarily belong in a list even if it feels natural to group them together and call them “navigation” or “external resources” or whatever. That a list looks like the best option in most cases, doesn’t defend its use in all cases.

I usually choose elements without paying attention to visual presentation, and try to get it right at what one may call a “technical level” where not even “without CSS” is enough of a guidance. Needless to say that the need for stylability and lack of options do lead to less than optimal choices all the time, since one can hardly get away with a wish for “technical perfection” if the resulting design doesn’t look right.
Megan McDermott responds:
Posted: February 19th, 2008 at 11:20 am →

I’ve been through that forms as lists arument in my head a million times. You have to put in something to make them clear properly in all browsers. If a form has to be something (with structural markup), then what is it? I tend to avoid using <br />’s as much as possible, which led me to choosing lists. Lately I’ve been starting to think that really, the is exactly what you need to do in this case - just force the line break. Anything else would be superfluous.
Mike Cherim responds:
Posted: February 19th, 2008 at 1:34 pm →

I’m surprised actual form elements weren’t added to that poll, Megan, though I have to wonder if it would have gotten any votes since 100% chose lists and nobody chose “something else.”
David McFarland responds:
Posted: February 22nd, 2008 at 12:20 pm →

Mike,

Thanks for posting this. I’ve been thinking about this lately as well. The concept of lists being the “semantic” response to most markup challenges is so often taken to an extreme. If you think about your markup too much everything starts looking like a collection of list items–”look three paragraphs, must be a list!” You can see this as well with definition lists which have been twisted in all sorts of bizarre ways, such as for displaying dialogue.

The real problem, of course, is that HTML is just too anemic to adequately identify all of the different types of content we add to our Web pages. Unfortunately, we don’t have the freedom to really markup our content the way it should be — for example by using XML and our own DTDs or XML schemas.
Dave responds:
Posted: February 22nd, 2008 at 1:23 pm →

I think it’s acceptable to use lists for forms when appropriate, but not required or appropriate in all cases. The trouble seems to come from the fact that all future uses of the HTML code can’t be anticipated.

I have an unexplainable innate drive to make my code 100% perfectly semantically correct. My problem with simple usage of form & input tags is that I feel like all the bits of the form are an unorganized jumble within the form tag. I envision a rogue browser scheming to take any forms like that and display the input fields in a random splattering throughout the height and width of the parent block, and that browser is laughing at me.

Then, I see lists. Using a list for a form lets me say, “Listen, rogue browser. I am clearly stating my intent: You will display these form elements one after another. They will look sort of similar — there will be some repetitive styles for each of these elements, even if one is a textarea and one is a collection of radio buttons. I’m telling you it’s a list, dangit, and now you have to do it.”

It’s completely ridiculous, and I’m normally much more logical, but basically I have to use lists for forms because I don’t trust the user’s browser to do what I want without me being so explicitly clear about my intent.
Mike Cherim responds:
Posted: February 22nd, 2008 at 2:07 pm →

You can see this as well with definition lists which have been twisted in all sorts of bizarre ways, such as for displaying dialogue. — David McFarland

For natural dialog I like using paragraphs. In fact I have a special “dialog” class with my blog here that I can apply to a div (for lots of dialog) and to the p for limited or spread out instances. This class removes the top and bottom margin and indents the first line. The result is dialog that looks like that written in a book.

I did once promote, or suggest the allowance of using dl for a more formal dialog like an interview (Q&A-like) in my article about using lists. I still think that’s probably a good way to go, but it’s right on the edge.

I envision a rogue browser scheming to take any forms like that and display the input fields in a random splattering throughout the height and width of the parent block, and that browser is laughing at me. — Dave

Hehe, you got it bad, huh? You know what, though, it’s far better to have your affliction than to not care one way or the other!
Robert Wellock responds:
Posted: February 25th, 2008 at 10:50 am →

Definition lists for generic navigation hyperlinks are one of the worst scenarios I usually see floating around.
michelangelo responds:
Posted: February 28th, 2008 at 6:09 pm →

Mike, on taste and instinct I agree completely but could you please show the negative consequences of, for example, using a list for layout? What’s a scenario where users would suffer from it?
Mike Cherim responds:
Posted: February 28th, 2008 at 10:18 pm →

Hi michelangelo. I can’t point to an example or reference, but I think I may be able to explain the importance. The elements all have a purpose, and as assistive technologies continue to improve, they may better convey the meaning of the these elements. Right now, laying out a page with a list might be passable to a screen reader user for example. In the future, though, because a list has a particular meaning, it may really screw someone up. Another example is the use of elements like strong. As of today, this element doesn’t give a clue to the screen reader user — no pitch change, no tag announcement, nothing, but I fully expect this is a temporary situation just as I expect aural style sheets will be better supported in the future. In my eyes, that a good reason to use the elements they way they are meant to be and not getting so creative that it may very well have a negative future impact.

One of the important requirements of creating accessible sites if to use the proper elements for the job and to do so in such a way that ensures they’re forward compatible.
Dennis responds:
Posted: March 12th, 2008 at 7:37 pm →

Unfortunately, I have to agree that lists are the new layout table. Developers overuse them for their benefit, not for correct semantic markup or for making a web page more accessible. I agree that forms and calendars are not lists; a calendar is a data table–days of the week in columns, and weeks in rows.
Andy responds:
Posted: March 26th, 2008 at 9:11 am →

Just curious: What makes a site navigation a list?
Mike Cherim responds:
Posted: March 26th, 2008 at 9:16 am →

What makes a site navigation a list?

Fair question. It is a list of the main navigable pages on the site. I wrote main navigable pages because the list might not contain all of the navigable pages.
Jared Stein responds:
Posted: June 20th, 2008 at 1:59 pm →

This article excited me as I love thinking about semantics. I’d agree that at least half of your suspects are blatantly guilty of list abuse (though I’ve not personally seen some of them in action), but I do disagree with your indictment of lists for forms. My disagreement comes first from the fact that you haven’t articulated a strong argument to prove that forms do not contain a list of items. You merely say:

“Forms are forms and lists are lists”
“Forms have their own elements, and lists have theirs”
“Forms have their own organization…dictated by their natural source order. Nothing needs to be added to this…”
This is simply repeating the same idea: that forms are different from lists; yet you haven’t articulated why or how they are different.

From an instructional design point of view listing the input points for the user makes sense, as you do want the user to work through and complete the form in sequence, and users tend to think of the fields/fieldlists as one-at-a-time “items” with clear relationships to the whole. I think that while using UL/OL and FIELDSET would seem a bit redundant for the parent grouping, but as has also been mentioned, there’s not many alternative elements that are any more semantic. Usually with FORMs, we’re looking at LABEL/INPUT pairs that could/should be demarcated. Another reader suggested using BRs at the end of each “line”, but I think a parent element is needed to nest these pairs. TABLE’s TR+TD markup does not seem semantically correct, because we are not presenting a “row” of “data”–we are presenting one or more form items. My second choice to encapsulate LABEL/INPUT pairs, the DIV, is completely neutral–giving no semantic information at all.

Anyway, thanks for an interesting article. It’s good to keep one’s guard up in defense of semantics!
Mike Cherim responds:
Posted: June 20th, 2008 at 3:20 pm →

I don’t know how to explain it better I guess, other than a form is a form and a list is a list. Form elements, in my mind, are not list items. Adding a list to the mix seems unnecessary is all. I don’t think it adds anything positive.

From an instructional design point of view listing the input points for the user makes sense, as you do want the user to work through and complete the form in sequence […]

That argument would dictate the use of an ordered list specifically, if there is a important sequence that is. Typically I view a form as a complete unit. One fills out the inputs then submits it. If someone fills out half the form then goes away, I can’t possibly fathom that that would happen because the user got confused by the unlisted form.

[…] the DIV, is completely neutral–giving no semantic information at all.

Not trying to be disagreeable, but I will on this one. I feel a div (unlike the span element), does have semantic value, as a divider. This was discussed quite a bit on the WSG list and that’s the conclusion the majority came up with. The only valueless element that I am aware of is a span. And a span can be given value by the developer through the use of attributes. By default the same should hold true of div elements, meaning that they can be used in such a way as to have no value at all (when nested, using them for forms, etc.). But if used properly I do feel they have semantic value or meaning.
Dawid Krysiak responds:
Posted: June 24th, 2008 at 8:53 am →

Tables are in fact a little more complicated lists. They are the 2D variant of lists - like vectors and matrices. So they belong to the same domain - their purpose is to structure, organize, order the data. So the use cases are very similar and of course both shouldn’t be overused - ie. shouldn’t be used just because it will look fine.
Jared Stein responds:
Posted: June 24th, 2008 at 10:29 am →

Mike, you are right; I overstated the meaningless-ness of DIV; DIV does have some semantic information (though I think the better description is as a “division” rather than a “divider”–HR is a divider, right?), and with the use of CLASS or ID we can use DIVs appropriately to encapsulate things like I’m pointing out, e.g. LABEL/INPUT pairs in a form. I also agree that OL would be preferable to UL for the form usage I mentioned above, though in radio/checkboxes UL is just fine. I personally wouldn’t ever argue the use of UL/OL in a FORM because it makes CSS easier.

As we can clearly see on your blog, that use of OL/UL in forms is debatable, but I still think it’s not only acceptable, it’s semantically useful markup. Thanks for the thought-provoking discussion.
Mike Cherim responds:
Posted: June 24th, 2008 at 10:42 am →

D’oh, “divider” was a poor choice. A division, or “section” as in HTML 5 is much better. Thanks.
Chris Heald responds:
Posted: July 6th, 2008 at 6:56 am →

The crux of the problem, I think, is that web developers are caught between a desire for semantic and presentational perfection, and are not given the tools necessary to accomplish it perfectly, in the case of HTML. The calendar is a perfect illustration of this - it is displayed as two dimensional matrix (which is, after all, what a data table is), as any other display format would be unwieldy and difficult to place on your kitchen wall, but when was the last time you told someone that you’d be over for dinner on “Thursday, Week Three”? How do you semantically represent a calendar to a screen reader without making the text-to-voice take approximately three years to iterate over it? I’d argue that HTML makes no good provision for things like calendars - instead, we are forced to make do with kludges and hacks, and hope that those who are accessing our sites under less than ideal circumstances will forgive us.

Despite the railings against lists for forms, I’m actually somewhat a fan of definition lists for forms. My reasoning is that a definition list consists of a series of terms and their definitions. The label for a field, therefore, is the term, and the input is the definition of the term to be filled in by the user. I’m sure there are a whole host of people that will disagree with that assessment, but it’s quite readable, renders very nicely in most every modern browser (including Links) without CSS, styles very easily, and just works well.
Chris responds:
Posted: July 6th, 2008 at 7:59 am →

Interesting problem but you might be calling fowl a little early — I work designing and implementing websites, and I have friends at other companies doing the same thing, and I’ve never heard of this practice. I think the general trend of using elements in proper ways is still considered most professional and thus most often done so by those “in the know”.

Sorry. Comments are closed.

Beast-Blog.com Are Lists Becoming the New Tables?