[whatwg] <CENTER>, <MENU>, <DIR>, <NL>

[Eugene T.S. Wong]

On Tue, 17 Jan 2006 00:28:05 -0800, Simon Pieters <zcorpan at hotmail.com>  
wrote:

> There is a <title> element type for this purpose. Use the following CSS:

Yes, I know of that. That's a very useful bit of CSS. In fact, it's 1 of  
my favourite tricks, next to "display:inline-block", and "display:table"  
and its variations.

> If you use <center> (or <h1>, or <div>) you are still duplicating the  
> <title>, no?

In this case, yes, because I would have a very simple title, and nobody  
else is using the electronic version of the document. However, in some  
cases, no, because I would need to put some ugly information in there.

<TITLE>Home -- www.MyServer.com</TITLE>
<TITLE>Foo Howto -- www.MyServer.com</TITLE>
<TITLE>Bar Howto -- documentation -> instructions -> Linux --  
www.MyServer.com</TITLE>
<TITLE>Contact Info -- www.MyServer.com</TITLE>

If I recall correctly, I read that many screen readers need to get past  
that redundant information in the title, which is the web site url [ie:  
"www.MyServer.com"]. It is important, though, because when all of us  
bookmark information, we need to know exactly which web site this "contact  
page" belongs to, and which site this home page belongs to. Ultimately,  
the information should be trimmed and modified by each user for the sake  
of customization, but we should code the information in an efficient and  
standard manner.

When those titles are rendered in the main document with CSS, as you  
suggested, it would begin to look very ugly, because you might get a title  
that looks like this.

<-- screen width with respect to the new font size --------->
     Bar Howto -- documentation -> instructions -> Linux --
                     www.MyServer.com

Another disadvantage is that there may be more information displayed than  
necessary, and may actually confuse the user. What if the user is familiar  
with bread crumbs, and tries to click on "instructions", or "Linux"? I  
suppose that the CSS solution is to replace the content, using "content:  
foo", but after a while, it begins to resemble CSS soup. But what if the  
user has CSS turned off? I suppose that in that situation, the user would  
never see <TITLE> in the page, and in the case of my flyer, I would have  
to turn it on to see <TITLE>. If I have to turn on the CSS to see any  
title, then I suspect that CSS is no longer being used to seperate content  
and presentation. Also, I admit that putting bread crumbs in <TITLE> is  
really stretching the intent of the element.

I think that 1 problem here is the definition of the word, "title". There  
is the bookmark concept, the element attribute, and what I will call the  
essay concept. The bookmark concept is more of a note or comment to give  
the user a clue when he selects that bookmark. This is similar to the  
element attribute. They may be like essay titles, but they tend to be  
short and to the point, with no real sentence grammar rules. At this point  
in time, element attribute titles actually have the freedom to be complete  
sentences and paragraphs that may explain how to use certain features of a  
page. The essay concept that I refer to is a proper title used in essays  
that should conform to college courses and maybe even book titles. Bear in  
mind that I went to college in 1991-1995. Some examples:

<CENTER>How I Got Rich By Coding HTML</CENTER>
<CENTER>How I Wasted Time Playing Cards</CENTER>
<CENTER>7 Habits Of Highly Successful People</CENTER>
<CENTER>How I Got My Freedom</CENTER>

The last 2 examples are probably the best examples, because although they  
are titles, they are more like conversational descriptions in note form,  
that are used to sell and summarize. They should contain more information  
about the subject, than <TITLE>. The reason that I use these examples, is  
because self-help books tend to be the worst offenders. In general, any  
book that helps a person is good, but no matter what, the book should be  
coded properly. In the last 2 examples, the <TITLE>s might be:

<TITLE>Good Daily Habits</TITLE>
<TITLE>Linux HowTo</TITLE>

In this situation, the content of <TITLE> would be very short, because we  
would want the user to have an easier time looking for it.

Documents which use these types of titles in the examples would most  
likely be very conversational, and less technical, and even discussing the  
philosophical aspects of following the book's instructions.

Imagine having to look through your bookmarks, where each 1 was labelled  
with an annoying sentence. In my bookmarks, I have a folder devoted  
entirely to all of Yahoo!'s services. The folder is called "-- Yahoo! --",  
without quotes. The folder's contents are each in simplest form. For  
example:

360
Alerts
Address Book
.
.
.
Yahooligans!
Yellow Pages

I wouldn't want it to look like this:

Yellow Pages By Yahoo!
Yahoo!'s 360
Address Book
Mail
Alerts -- Yahoo!

It makes it very difficult to speed read the information. Even if we  
sorted it out, certain items may still be found in an inconvenient order.  
Imagine if half of the items started with "Yahoo!'s ". Mentally, I only  
think of 360 as "360", and if I'm used to searching through the list  
according to how my operating system displays directories, then I'm going  
to look at the beginning of the list to find 360. If it's not there, then  
I can look under the first listing beginning with "Yahoo!'s ". If it's not  
there, then I can look for it using the search feature. It's good to have  
these options for finding the bookmark, but I believe that nothing beats  
good naming schemes.

The only solution is to rename the bookmarks and/or <TITLE>s. If we use  
good naming conventions for <TITLE>s, then we limit ourselves to what we  
can name our documents. The problem here is the same as any language.  
Words and concepts get associated with different contexts, and as a result  
meanings become diluted. We can counter the effects by allowing ourselves  
more HTML elements, and at the very least, the continued use of already  
created elements that don't create bad code.

-- 
Sincerely, and with thanks,
Eugene T.S. Wong