How should I format an address?

[Jukka K. Korpela]

I think one could also argue for the use of a definition list, for
about the same reasons:

You could, but you would be wrong.

<dl class="address">
<dt>Addressee</dt>

You are not defining the meaning of the term "addressee". If you were,
you would have something like
<dd>the person to whom a letter or other message is addressed</dd>

 

[Jukka K. Korpela]

Advice is often seen on this group to
not choose an element because of it's default style.

Right. You should not choose an element just because it "looks right"
on a particular browser, or on several browsers, even if the default
presentation is specifically recommended in specifications.

Isn't the reverse true as well?

It depends on what you mean by reversing.

Don't choose ul because of the default
style? Don't choose address because of it's defaut style?

It's a reasonable practical principle to consider the default
presentational effects of using a particular element _when you have a
choice_ that makes sense semantically.

For example, any list can trivially be described as a table, either as
a one-row table or as a one-column table. In fact, something that
logically consists of a sequence of lines could be marked up in several
ways, and there is in general no particular reason to favor one over
another _semantically_:
- <ul>
- <ol>
- <table> with one row
- <table> with one column
- a sequence of <div> elements, perhaps enclosed inside an outer <div>
though the last option should be taken as the last resort, since it has
least structure. We could also consider <pre> or using just <br>
between lines, but these are less satisfactory since they do not even
make the lines _elements_.

(Note, by the way, that using <address> as the container, the _only_
way to indicate the line structure is to use <br>. This is one of the
symptoms of the poor design of the <address> element in HTML.)

Given these options, it seems reasonable to make a choice at least
partly according to the default rendering of elements.

 

[Toby Inkster]

Don't choose ul because of the default style?

Don't choose UL for an address because the order of items in an address is
semantically important. Default style doesn't come into it.

 

[Marcus Stollsteimer]

Although I agree with your general point about W3Schools not being
authoritative...

HTML 2.0 Spec:
| The ADDRESS element contains such information as address,
| signature and authorship, often at the beginning or end of the
| body of a document.

but consider the slight differences in the formulation.

Regards,
Marcus

 

[Stan McCann]

To stay on the safe side, we should expect them to be the same,
since the summary at
http://www.w3.org/TR/REC-html40/index/elements.html says that
<address> is "information on author", and the DTD comment says the
same.

I do not see "information on author" anywhere in that specification.
What it says is "may be used by authors to supply contact information
for a document or a major part of a document." Not the same at all. I
am the author of a number of pages that I am not the correct contact
person for. As I said, author and contact are not always the same.

With the usual CSS caveats. Did you forget them? My point is that by
using <address> you take the unnecessary risk of having the content
displayed in italics in some browsing situations. When you would use

No, I didn't forget about not having control at the viewer's end, I
said it was irrelevant to consider the default display. You addressed
this in another post and to a point, I must agree.

With a list (<ul> or <ol>), you would have the problem of _default_
rendering, with bullets or numbers. An attempt to remove the bullets
or numbers with CSS might or might not be successful.

How does an audio reader render lists? Does it say "bullett" for each
list item? Most modern browsers will display CSS mostly correct. So,
if a ul is semantically correct, the fact that bulletts are the default
display is irrelavent, a very very small number of people might see the
address list presented with bulletts. I'll have to ask someone about
the presentation of it in audio as that would be a concern.

Hey, I teach this stuff too, so I want to *know* before I go telling my
classes one way or another.

 

[Stan McCann]

Don't choose UL for an address because the order of items in an
address is semantically important. Default style doesn't come into
it.

Oops, you're right. Whether the numbers are displayed or not, to be
semantically correct, it would be ol. I agree that the default syling
should not be a consideration any more than it should be a
consideration marking something up as h1 because you want it big and
bold or blockquote for indenting.

I'm beginning to believe that there may not be a semantically correct
element which would bring us back to Jukka's
<div class="address">
<div class="addressee">Somebody</div>
<div class="streetaddress">xxx some street</div>
<div class="location">city, state/province, zip and/or country</div>
</div>

or some such semantic structure.

 

[Jukka K. Korpela]

I do not see "information on author" anywhere in that
specification.

You don't? I mentioned _two_ locations, in the text you quoted.
(Actually, the DTD comment appears both in the description of the
element and in the DTD itself, which is part of the spec, too.)

How does an audio reader render lists?

It depends. Some early speech-based user agents read the items of a
<ul> list in succession as if they were all one paragraph (and for this

Does it say "bullett" for each list item?

Probably not. But it may pause between the items.

Most modern browsers will display CSS mostly
correct.

Well, that's quite an exaggeration. After all, IE is by far the most
common browser, and it has a poor CSS implementation. If you mean just
list bullet suppression, then you're right - up to a point.

So, if a ul is semantically correct, the fact that
bulletts are the default display is irrelavent, a very very small
number of people might see the address list presented with
bulletts.

Drop at least one of the "very" words. Think about text-based browsers
like Lynx and Links, which ignore style sheets. Think about the
possibility of switching off style sheets or using user style sheets to
override author style sheets.

 

[Jukka K. Korpela]

Oops, you're right.

I don't think so. The difference between <ol> and <ul> is basically the
styling of list markers. The idea that <ol> is ordered and <ul> is
unordered does not hold water. It would be just as incorrect for a
browser to reorder the items of a <ul> as it would be incorrect to
reorder the paragraphs in a sequence of paragraphs or the rows of
table. There is nothing in HTML specifications that says that elements
_must_ be rendered in succession or that the order of table rows is
significant; it is more or less just common sense, and so is the
significance of the order of items in a <ul> list.

The difference between <ol> and <ul> has some semantic flavor, though.
We normally use <ol> to _emphasize_ the order and to make it explicit,
perhaps for the purpose of referring to items by their numbers (or
letters).

I'm beginning to believe that there may not be a semantically
correct element

There are _several_ semantically correct elements, or let us say
elements that are not semantically incorrect. There is no element
_dedicated_ for address markup (in general), though.

 

[Stan McCann]

You don't? I mentioned _two_ locations, in the text you quoted.
(Actually, the DTD comment appears both in the description of the
element and in the DTD itself, which is part of the spec, too.)

OK, I found where it does say "information on author" but in the
expanded text that clarifies usage, it says "used by authors to supply
contact information for a document or a major part of a document" which
you snipped. So, the W3C provides two statements that contradict each
other. "information on author" != "used by authors." Which are we to
go by? The short notation/comment or the explanation of usage
provided?

It depends. Some early speech-based user agents read the items of a
<ul> list in succession as if they were all one paragraph (and for
this reason, some people recommended using <ol> instead), but modern
software works better and reads it in some "itemized" way.

I use the two semantically, I think. For lists where order does not
matter, I use <ul>. Where the order of the items does matter, I use

Probably not. But it may pause between the items.

I just talked to a blind student that uses Window Eyes. He doesn't
know HTML so I'm not sure how valuable his input is as he said anything
is ok as long as each is on a different line. I'm not sure he really
knew what I was refering to without setting up some demonstrations for
him.

Well, that's quite an exaggeration. After all, IE is by far the most
common browser, and it has a poor CSS implementation. If you mean
just list bullet suppression, then you're right - up to a point.

No, I didn't mean just bullet suppression. IE does have a poor
implementation of the box model, positioning and other fancy stuff.
The basics (CSS 1 and some of the simpler things in 2.1) work fairly
well IMO. Maybe I think that way because the only time I use IE is to
check to see how pages are displayed in it. I use FF as my regular
browser.

Drop at least one of the "very" words. Think about text-based

Yeah, I get carried away sometimes. Reading that over again, I'll drop
both verys.

browsers like Lynx and Links, which ignore style sheets. Think about
the possibility of switching off style sheets or using user style
sheets to override author style sheets.

I also like to check pages I do without style sheets. I do so mostly
to see that presentational sequence is in tact *knowing* that things
won't be the same. I see no harm in an address being in italics or
having bullets before each line if that is the default presentation.

Of the options in the page on your site, I'm leaning more and more to
using <div>. I'm undecided about the inner markup. On one hand, I see
nothing wrong with using <br> for a line break (not for spacing). On
the other hand, using <div> for the inner markup as shown on your web
page makes sense to me.

 

[Toby Inkster]

There is nothing in HTML specifications that says that elements
_must_ be rendered in succession

Indeed they don't have to:

<ul style="line-height:1em">
<li style="position:relative; top: 1em">One
<li style="position:relative; top:-1em">Two
</ul>

 

[Jukka K. Korpela]

OK, I found where it does say "information on author" but in the
expanded text that clarifies usage, it says "used by authors to
supply contact information for a document or a major part of a
document" which you snipped. So, the W3C provides two statements
that contradict each other. "information on author" != "used by
authors."

That's no contradiction. You can take the longer descriptive phrase as
what it is, a note on usage rather than a definition. Even if you
treated both as normative, there is no contradiction: they would be two
requirements, and then correct usage would satisfy both requirements.

I use the two semantically, I think. For lists where order does
not matter, I use <ul>. Where the order of the items does matter,
I use <ol>.

The only semantics assigned to those elements, apart from their being
lists of course, is in the phrases "unordered list" and "ordered list".
I wonder how much meaning we can read into these phrases (or expansions
of the names of the elements). After all, nobody has ever suggested
that a browser would be allowed to reorder a <ul> as it likes when
rendering it or that the order in it could be taken as insignificant.

These elements reflect the word processor software practice of offering
"bulleted lists" and "numbered lists". I would say that the difference
is basically stylistic, with a potential semantic flavor.

 

[chromatic_aberration]

You could, but you would be wrong.

When it comes to "definition lists", I would take that chance!

You are not defining the meaning of the term "addressee". If you were,
you would have something like
<dd>the person to whom a letter or other message is addressed</dd>

That's not really the point either. You're being a bit too literal in
your understanding of the DL element...
When you look at the W3C spec, it states a.o.:

"Another application of DL, for example, is for marking up dialogues,
with each DT naming a speaker, and each DD containing his or her words."

(BTW, notice "for example"...)

Now, consider the following code:

<dl>
<dt>Polonius</dt>
<dd>This above all: to thine own self be true...</dd>
</dl>

According to your understanding, the sentence "This above all: to thine
own self be true" should define the term "Polonius"... which obviously
is not the case!
Still, the code is perfectly valid according to W3C's own recommendation.

Besides, DL is only required to contain at least *one* DT _or_ *one* DD,
which (in the case of a single DT or DD) would be hardly sufficient to
qualify the markup as defining anything...

Obviously, DL is mostly a way to provide a plain list, with 2 levels of
indentation and possibly a certain degree of relationship/hierarchy
between items. Despite the name...

Some have gone so far as to use DLs to build most of a whole site:
http://www.jasoncartwright.com/blog/entry/2005/10/why_a_divless_page

I've been using them mostly to make navigation lists (menus), as they
make nice containers which are easier to style than ULs. And I can use
DLs as titles for groups of links, without having to wrap Hns and ULs in
a DIV...
The introduction of the NL element in XHTML 2, which can be regarded as
a further development of the DL, indicates that I haven't been
completely wrong in that matter... either!

 

[Stan McCann]

That's no contradiction. You can take the longer descriptive phrase
as what it is, a note on usage rather than a definition. Even if you
treated both as normative, there is no contradiction: they would be
two requirements, and then correct usage would satisfy both
requirements.

I hate to send you to a page from the old table layout tag soup pages
on a server I manage, but would you say <address> would be appropriate
for the contact information in the top part of this page:
http://alamo.nmsu.edu/programs/ ? Specifically, this portion:
Counseling Office
Student Services Building
439-3720
Advisor on Line at:
(e-mail address removed)

Actually, that's one of the pages I've fixed up as I've improved my
HTML/CSS skills, not that it's perfect, but better.

These elements reflect the word processor software practice of
offering "bulleted lists" and "numbered lists". I would say that the
difference is basically stylistic, with a potential semantic flavor.

I think you're right about the reasoning for inclusion, but with the
names, I think they have taken on a semantic flavor. But even with
<ul>, there are sometimes reasons for the order listed, just not as
strong a reason to go with <ol>. Not changing the order in the browser
is a good thing, although with most of my usage of <ul>, it wouldn't
bother me much if the order were changed in the browser.

 

[Toby Inkster]

After all, nobody has ever suggested that a browser would be allowed to
reorder a <ul> as it likes when rendering it or that the order in it
could be taken as insignificant.

Not quite the same, but I've been suggesting for years on opera.wishlist
that it add a feature to sort unordered lists alphabetically (not by
default, but on demand in a right-click context menu). Likewise with
tables on a column-by-column basis.

 

[Jukka K. Korpela]

would you say <address> would be appropriate
for the contact information in the top part of this page:
http://alamo.nmsu.edu/programs/ ?

Hardly. It's not the page author's contact information. In fact, at the
bottom of the page, there's contact information that is apparently
meant to be used for communication about the page...

 

[Jukka K. Korpela]

You're being a bit too literal in
your understanding of the DL element...

I'm referring to its definition, which is pretty definite.

When you look at the W3C spec, it states a.o.:

"Another application of DL, for example, is for marking up
dialogues, with each DT naming a speaker, and each DD containing
his or her words."

So what? They give a definition and then start to babble nonsense that
is quite comparable to saying, after a definition of what BLOCKQUOTE
_means_, that another application of BLOCKQUOTE is for indenting text.

When a specification is self-contradictory, you have to make a choice.
The sensible approach is that the normative definition trumps any
examples.

This has actually been discussed quite a many times. Nobody can prevent
you from using DL (or BLOCKQUOTE) to achieve a particular visual
layout, and there are probably no serious consequences, since such
abuse is so common that DL (and BLOCKQUOTE too, in fact) is almost
useless as semantic markup. Yet, it's still much better to use logical
and clean markup and use CSS for styling.

 

[Stan McCann]

Hardly. It's not the page author's contact information. In fact, at
the bottom of the page, there's contact information that is
apparently meant to be used for communication about the page...

I think you are wrong on this. Your insistance that <address> is only
for information on the author is wrong. I've already shown that the
W3C itself says <address> is for use *by* authors for contact
information about the document or part of the document.

And just how is author defined when it comes to web pages? In many
instances, one or more people may write the content for a page while
someone else marks up that content. Which is the author? In the link
I gave for instance, I may or may not be considered the author. There
are two sets of contact information on that page for a very definite
reason. One set of contact information, at the top of the page
concerning the content that appears on the page (much of that content
authored by others and only marked up by me) and another contact
concerning design and markup of the page.

This question I pose about who is the author of a page also begs the
question of meta information. Am I incorrect in specifying
name="Author" as myself when I have only marked up a document? Maybe
we need some new words for author? Words that make distinctions as to
content (and amounts of?) or markup?

 

[chromatic_aberration]

When a specification is self-contradictory, (snip)

Maybe a bit fuzzy, but not self-contradictory...
Define "definition"

In my example, "name" might not be a definition of *what* an "addressee"
is, but it sure is a definition of *who* this particular addressee is...

(snip) Nobody can prevent
you from using DL (or BLOCKQUOTE) to achieve a particular visual
layout,

Sure not. But that's not what I would do, either!
I believe one should use CSS for visuals... The point of using a list
here (be it UL or DL) is to provide code with a clean logical structure
and as much semantic as HTML (as we know it today) allows.
In this case, lacking a specific element to meet our needs, we have to
use fallbacks, which your TABLE suggestion, indeed, is just another
example of.

 

[Jukka K. Korpela]

Your insistance that <address> is
only for information on the author is wrong. I've already shown
that the W3C itself says <address> is for use *by* authors for
contact information about the document or part of the document.

I have shown that the HTML specification says "information on author"
_three times_ when describing the <address> elements. There's little
point in any discussion if you keep misrepresenting the facts.

Use <address> for whatever you like, and <blockquote> for indentation
and <h6> for small text if you like, but if you claim in public that
such usage is semantically correct, stay tuned to getting responses
that indicate that you are wrong.

 

[Stan McCann]

I have shown that the HTML specification says "information on
author" _three times_ when describing the <address> elements.
There's little point in any discussion if you keep misrepresenting
the facts.

You are correct that this discussion is at an end, but not due to my
misrepresenting the facts as I have not. The specification also says
what I have quoted. You insist on going by a short definition rather
than the expanded information also provided by the same body.

Use <address> for whatever you like, and <blockquote> for
indentation and <h6> for small text if you like, but if you claim in
public that such usage is semantically correct, stay tuned to
getting responses that indicate that you are wrong.

Your responses. I've seen nobody else obsessing over such detail
ignoring all other as you have. If I am wrong, and I see other
responses showing that, I am certainly man enough to admit my
failings. Fact is, I am not wrong. You just fail to read the entire
specification. Apparantly, to you, the entire writings of the W3C are
the first few lines of each element, ignoring the rest. Some of us
read a bit beyond the first few lines in order to learn what the
authors meant by those first few lines.

I'll continue to learn (sometimes, even from you), and you can
continue to hide your head in the sand learning nothing new.