Re: Semantics - Mystery of the Menu tag

On Fri, 4 May 2007, David Woolley wrote:

> I think the problem with the menu *element* was that no browsers
> rendered it differently from UL, even though the original
> specification hinted that it should be rendered compatibly with the
> user of very short items (as such it is semi-presentational.

I wouldn't say it was semi-presentational. The difference between UL and 
OL might be called semi-presentational (and even that is questionable - do 
bullets vs. numbers or letters change the _meaning_ of a list?), but the 
difference between UL, MENU, and DIR was _defined_ as presentational. No 
wonder MENU and DIR never became popular, because there was in practice no 
presentational difference either.

For example, HTML 2.0 defined MENU as follows:

"The MENU element is a list of items with typically one line per item. The 
menu list style is typically more compact than the style of an unordered 
list.

The content of a MENU element is a sequence of LI elements. Nested block 
elements are not allowed in the content of MENU elements."

So it's a list of items, not specifically a menu, despite the name. The 
presentational suggestion is odd, since the rendering would not be 
particularly compact, but presumably the idea was that a MENU element 
might lack bullets, left margin, and any vertical spacing.

The restriction on item contents does not change the presentational 
nature, and it was probably imposed because allowing blocks would conflict 
with the presentational ideas. Anyway, it clearly forbids nested MENU 
elements.

The DIR element, on the other hand, was supposed to be rendered 
compactly. Quoting HTML 2.0 again:
"The DIR element is similar to the UL element. It represents a list of 
short items, typically up to 20 characters each. Items in a directory list 
may be arranged in columns, typically 24 characters wide."

This was odd. In the old times when style sheets for HTML were just an 
idea, it would have been understandable if a single element for list had 
been defined so that various types can be specified using an _attribute_, 
like <list type="bulleted">, <list type="menu">, etc., but inventing a 
total of four obscurely named _elements_ was not consistent with the 
general idea of generalized markup.

A list of links is a common construct, but it is debatable whether a 
particular _element_ is needed for it. It might be seen as unnecessary 
complication and diversity. If a link list element does not _mean_ 
anything but a list where the items are links, why would a separate 
element be needed? It might allow simplistic browsers to do something 
special (in a useful way) with such lists, but wouldn't this mean that a 
link list element and a list of links might be processed differently, for 
no good reason?

A link list (or "navigation list") might be useful to authors, if authors 
could use some special simplified markup for it, like
<linklist>text1 = url1, text2 = url2, ..., textN = urlN</linklist>
but any possibilities for such readable markup were abandoned when 
oversimplification was declared progress, i.e. SGML was abandoned in favor 
of XML. But maybe the wheel could be reinvented for HTML 5 purposes? :-)

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Saturday, 5 May 2007 08:34:23 UTC