Contact information

[Nik Coughin]

Contact information is a list of name=value pairs.

Name=John Smith
Street Address=1234 Some St
Phone=+649 555 1234

etc.

However, it is standard practise to omit the name from the name=value pair
for some of the contact info, for example a business card might read:

John Smith
1234 Whatchamacallit St
Auckland, New Zealand
Email: dksjafkh@fjkahgjmns
Phone: +649 555 1234

Semantically, how is this marked up?

"It is a list of contact details therefore it should be a ul":
<ul>
<li>John Smith</li>
<li>Email blahblah@blahblah</li>
<li>Ph +649 555 1234</li>
<li>Fax +649 555 5678</li>
<li>Mobile +649 555 3456</li>
</ul>

In this case the phone numbers/email address do not line up. They are much
easier to read if they line up. Don't like this.

"A definition list, as it is a list of items following the form of
something=something":
<dl>
<dt></dt><dd>John Smith</dd>
<dt>Email</dt><dd>blahblah@blahblah</dd>
<dt>Ph</dt><dd>+649 555 1234</dd>
<dt>Fax</dt><dd>+649 555 5678</dd>
<dt>Mobile</dt><dd>+629 555 3456</dd>
</dl>

Easier to read. If float: left is applied to dt then it becomes very
readable indeed. Would you say it is wrong to leave the dt blank? There is
an implied dt of "name" in this instance. Problem is that if the text in dt
is longer than the margin on the dd the data no longer lines up.

"A table; it is tabular data":
<table>
<tr>
<td>John Smith</td>
</tr>
<tr>
<th>Email</th><td>blahblah@blahblah</td>
</tr>
<tr>
<th>Ph</th><td>+649 555 1234</td>
</tr>
<tr>
<th>Fax</th><td>+649 555 1234</td>
</tr>
<tr>
<th>Mobile</th><td>+649 555 1234</td>
</tr>
</table>
Markup is unweildy but provides the most flexible solution
presentation-wise. The value components always line up with each other.
Problem is similar to that of using a dl, we may end up with a tr containing
a single td. However, like in the dl example above, tabular data is
implied; name=value with name omitted. Therefore, semantically sound?

So, ul, dl, or table? Don't like ul much, because of the readability issue.
Am I justified in saying that in the cases of dl and table, the name part of
a name=value pair can be implied? In that case is dl better suited, or
table? Table seems the more fluid of the two when it comes to presenting
the data in a form that would be the most familiar to most people.

Comments?

--
"Come to think of it, there are already a million monkeys on a million
typewriters, and the Usenet is NOTHING like Shakespeare!" - Blair Houghton
-=-=-=-=-=-=-=-=-=-=-=-
http://www.nrkn.com/
-=-=-=-=-=-=-=-=-=-=-=-

 

[Neal]

Contact information is a list of name=value pairs.

Name=John Smith
Street Address=1234 Some St
Phone=+649 555 1234

etc.

However, it is standard practise to omit the name from the name=value
pair
for some of the contact info, for example a business card might read:

John Smith
1234 Whatchamacallit St
Auckland, New Zealand
Email: dksjafkh@fjkahgjmns
Phone: +649 555 1234

Semantically, how is this marked up?

It could be a list of contact details about the main item.

<address>John Smith
<ul>
<li>1234 Whatchamacallit St</li>
<li>Auckland, New Zealand</li>
<li>Email: dksjafkh@fjkahgjmns</li>
<li>Phone: +649 555 1234</li>
</ul>
</address>

Or, it could be a one-column table, where the missing "first" column" is
implied and not specifically stated.

<table>
<tr>
<td>John Smith</td>
</tr>
<tr>
<td>1234 Whatchamacallit St</td>
</tr>
<tr>
<li>Auckland, New Zealand</li>
</tr>
<tr>
<td>Email: dksjafkh@fjkahgjmns</td>
</tr>
<tr>
<td>Phone: +649 555 1234</td>
</tr>
</table>

I don't exactly know which is best. Or some other option.

 

[Jukka K. Korpela]

Contact information is a list of name=value pairs.

Maybe, in a logical sense.

However, it is standard practise to omit the name from the name=value
pair for some of the contact info,

Which means that it is just a list of text lines, isn't it? However it's
about "logical lines", so that a "line" might get split to two (or more)
lines if they are wider than the available width.

This is a bit problematic, since the order of the lines varies by
national practice. Sometimes the reader does not know which part is
street address, etc., especially if the address is written in a writing
system unknown to him (such as Latin letters for many, or Chinese
characters for some). But usually this does not matter since the cryptic
part is the lines of the postal address, and you normally use it just to
_copy_ it (into an envelope for example).

Semantically, how is this marked up?

Since there is no element for address information in general in HTML, the
best approach is usually to use a semantically empty element, namely
<div>. That way, you will not give _incorrect_ semantic information, and
you don't invoke processing or display features that are related to
semantically wrong elements.

If you use <div> for each line, you will get the desired appearance
except for the "continuation lines". You can wrap it inside an outer
<div>, class it, and use CSS to handle that too:

<style type="text/css">
..address { margin: 0.5em 0 1em 2em; }
..address div { margin-left: 1em; text-indent: -1em; }
</style>
- -
<div class="address">
<div>John Smith</div>
<div>1234 Whatchamacallit St</div>
<div>Auckland, New Zealand</div>
<div>Email: <a href="mailto:dksjafkh@fjkahgjmns">
dksjafkh@fjkahgjmns</a></div>
<div>Phone: <a href="tel:+6495551234">+649 555 1234</a></div>
</div>

Why not <address>? Because it specifically means contact information for
the current page (author's address), and this is about the general case
of an address. And because <address> has some presentational
idiosyncracies in common browsers, features that are really _unsuitable_
for addresses. If it's really the author's address, you _might_ define it

"It is a list of contact details therefore it should be a ul":

That would not be completely incorrect, but rather unnatural. The
meanings of <ul> and <ol> are rather vague, but they are meant to
correspond to an everyday notation of "list" in documents, not any
sequence. We are not supposed to put paragraphs inside <ul> markup, even
though paragraphs constitute a list in a very abstract sense (a
sequence). Moreover you would have to do your best to prevent browsers

"A definition list, as it is a list of items following the form of
something=something":

A definition list is a list of _terms_ and definition data for them. You
are not defining the terms "Email", "Ph", etc. You are not saying "The
meaning of the word 'Email' is 'blahblah@blahblah'".

Would you say it is wrong to leave the dt blank?

Is it wrong to define a term without saying what the term is?

"A table; it is tabular data":

It can be regarded as tabular data, yes. A table can be used here. The
<table> markup is semantically empty except for the pure structure in the
sense that a table is a sequence of mutually isomorphic sequences - and
here you have something that can be regarded as a special case of that, a
sequence of pairs.

<tr>
<td>John Smith</td>
</tr>

Since other rows have two cells, this should too - most logically, with

Markup is unweildy

Not really.

Problem is similar to that of using a dl, we may end up with a
tr containing a single td.

That's formally accepted but structurally unsound. An empty cell can be
used to handle this. It puts the data into the correct column.

 

[Toby Inkster]

Semantically, how is this marked up?

HTML doesn't really have much in the way of contact-info markup.

There is <address>...</address>, but according to the spec, this is used
to include contact information about the author of the page (not just
general contact info).

If you're including information for a lot of people, then a table with
columns "Name", "Address", "Postcode", "Country", "E-mail", "Phone",
"Fax", etc might be appropriate.

Alternatively:

<dl class="contact">
<dt class="no">Name</dt>
<dd>Joe Bloggs<br></dd>
<dt class="no">Address</dt>
<dd>Omnibus Depot,<br>Clapham,<br>London<br></dd>
<dt>Phone:</dt>
<dd>020 8123 4567<br></dd>
<dt>Fax:</dt>
<dd>020 8123 4568</dd>
</dl>

..contact {
border: 1px solid black;
}
..contact dt, .contact dd {
display: inline;
}
..contact dt.no {
display: none;
}
..contact dt {
font-weight: bold;
}

If semantics are of the utmost, it might be best to use whichever form you
like best on the page, but link to the same data in a format more suited
to address data, such as LDIF or FOAF.

 

[Adrienne]

Contact information is a list of name=value pairs.

Semantically, how is this marked up?


Comments?

How about the label and span elements? The label element holds the names
and the spans hold the values, eg:
<p>
<label for="name"><span id="name">John Doe</span></label><br>
<label for="address"><span id="address">123 Any Street</span></label><br>
<label for="city"><span id="city">Any Town</span></label>
<label for="state"><span id="state">Any State</span></label> <label
for="zip"><span id="zip">99999</span></label><br>
<label for="phone">Phone: <span id="phone">(800)555-1212</span>
</p>

 

[Neal]

How about the label and span elements? The label element holds the names
and the spans hold the values, eg:
<p>
<label for="name"><span id="name">John Doe</span></label><br>
...

However, label "explicitly associates the label being defined with another
control", and as such is defined as a form element. This would be improper
use of label.

See [http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL] for more.

 

[Adrienne]

How about the label and span elements? The label element holds the
names and the spans hold the values, eg: <p>
<label for="name"><span id="name">John Doe</span></label><br> ...

However, label "explicitly associates the label being defined with
another control", and as such is defined as a form element. This would
be improper use of label.

See [http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL] for
more.

I thought about that, so I sent it through the validator. It didn't
complain at all. The only thing it didn't like was a lack of <p>
element, so I put those in, and voila!

Of course, one could always wrap this in a form element, with the action
set to itself and no submit button.

 

[Neal]

Neal wrote
I thought about that, so I sent it through the validator. It didn't
complain at all. The only thing it didn't like was a lack of <p>
element, so I put those in, and voila!

Well, there's what's valid and what makes sense. Just because it validates
doesn't mean it makes sense.

Of course, one could always wrap this in a form element, with the action
set to itself and no submit button.

But does that make sense?

Why do you need a label element?

 

[Adrienne]

Well, there's what's valid and what makes sense. Just because it
validates doesn't mean it makes sense.


But does that make sense?

Why do you need a label element?

I'm probably coming from this from a different angle. I do a lot of forms,
mostly for admin purposes, so I sort of think in name value pairs.

I really like that label element. With CSS and server side scripting, I
can make it do all sorts of things. I style it as a block container, of a
certain width, aligned a certain way, and simulate tables for forms. I can
also make it a different color/background color if the user has made an
error.

Even in this instance, for an address, that label could be styled in a
certain way.

 

[Neal]

I really like that label element. With CSS and server side scripting, I
can make it do all sorts of things. I style it as a block container, of
a
certain width, aligned a certain way, and simulate tables for forms. I
can
also make it a different color/background color if the user has made an
error.

But it's a form control. It makes no sense to use it in this context. You
may as well use a null element like <div>.

 

[Neal]

But it's a form control. It makes no sense to use it in this context.
You may as well use a null element like <div>.

Correction - <span>. label is %formctrl which is %inline.
[http://www.w3.org/TR/html401/sgml/dtd.html]