Indenting with XHTML

[John]

Hi,

I need to produce XHTML (transitional or strict) documents, that display
invoices. A typical invoice might be:

1 x Assembled Part
consisting of ...
5 x Large Bolt
10 x Small Bolt
3 x Assembly 452
consisting of ...
1 x Mending Plate
3 x Self-Tapping Screw
3 x Bottle of Oil
5 x Toolkit A
consisting of ...
1 x Spanner
1 x Hammer
1 x Stapler

What is the best (most standards-compliant and clean coded) way to
format this list in XHTML? I am open to all suggestions (not just those
that look like the above). The indentation works well at displaying the
nesting, but there could well be other better ways. This document will
be non-geek viewable though, so nested brackets and such like are out of
the question.

Cheers,

John

 

[rf]

John

Hi,

Er, G'day. Care for some chardonnay?

I need to produce XHTML

Why the emphasis on XHTML. HTML will do nicely until the majority of
browsers in use support XHTML (hint IE does not, really).

(transitional or strict)

I would hope that new documents would validate to strict.

documents, that display
invoices. A typical invoice might be:

1 x Assembled Part
consisting of ...
5 x Large Bolt
10 x Small Bolt
3 x Assembly 452
consisting of ...
1 x Mending Plate
3 x Self-Tapping Screw
3 x Bottle of Oil
5 x Toolkit A
consisting of ...
1 x Spanner
1 x Hammer
1 x Stapler

What is the best (most standards-compliant and clean coded) way to
format this list in XHTML? I am open to all suggestions (not just those
that look like the above). The indentation works well at displaying the
nesting, but there could well be other better ways.

This is unordered lists within unordered lists. You may have to adjust the
decoration and the margins to suit.

This document will
be non-geek viewable though, so nested brackets and such like are out of
the question.

Er, what does this actually mean? What brackets and what geeks?

 

[John]

John



Er, G'day. Care for some chardonnay?

I'll give it a miss, thanks anyway.

Why the emphasis on XHTML. HTML will do nicely until the majority of
browsers in use support XHTML (hint IE does not, really).

To allow other systems to read the documents (specified feature I can't
control).

I would hope that new documents would validate to strict.
Good.



This is unordered lists within unordered lists. You may have to adjust the
decoration and the margins to suit.

Right, I'll have a go at those. I'm not sure about adjusting the margins
though, how would that work?

Er, what does this actually mean? What brackets and what geeks?

If I was writing it for myself I might just use brackets.

Order_4673{
5 x ToolKit_A{
1 x Spanner
1 x Hammer
1 x Stapler
}
}

Cheers for the response rf.

John

 

[Toby Inkster]

1 x Assembled Part
consisting of ...
5 x Large Bolt
10 x Small Bolt
3 x Assembly 452
consisting of ...
1 x Mending Plate
3 x Self-Tapping Screw
3 x Bottle of Oil
5 x Toolkit A
consisting of ...
1 x Spanner
1 x Hammer
1 x Stapler

<style type="text/css">
.partslist li {
list-style: none;
}
</style>
<ul class="partslist">
<li>
1 x Assembled Part<br />
consisiting of...
<ul>
<li>5 x Large Bolt</li>
<li>10 x Small Bolt</li>
<li>
3 x Assembly 452<br />
consisting of...
<ul>
<li>1 x Mending Plate</li>
<li>3 x Self-Tapping Screw</li>
</ul>
</li>
</ul>
</li>
<li>3 x Bottle of Oil</li>
<li>
5 x Toolkit A<br />
consisting of...
<ul>
<li>1 x Spanner</li>
<li>1 x Hammer</li>
<li>1 x Stapler</li>
</ul>
</li>
</ul>

 

[Frogleg]

<style type="text/css">
.partslist li {
list-style: none;
}
</style>
<ul class="partslist">
<li>
1 x Assembled Part<br />
consisiting of...
<ul>
<li>5 x Large Bolt</li>
<li>10 x Small Bolt</li>
<li>

<snip>

What about <dl> and <dd>/<dt>? I remember being entranced with dl's
when I first began to learn HTML, but I rarely see them/anything about
them now.

 

[Karl Groves]

What about <dl> and <dd>/<dt>? I remember being entranced with dl's
when I first began to learn HTML, but I rarely see them/anything about
them now.

Is the OP's list a list of terms and their definitions? No. So, it wouldn't
be appropriate here.

-Karl

 

[Ken]

Hi Karl -

Is the OP's list a list of terms and their definitions? No. So, it wouldn't
be appropriate here.

Actually the OP's list *IS* a list of terms (parts) and their
definitions (components).

I'm not saying that's the best way to do it or the way that I would
recommend (I'm not making any particular recommendation), but it is
one valid possibility.

 

[Karl Groves]

Hi Karl -



Actually the OP's list *IS* a list of terms (parts) and their
definitions (components).

I don't view that as a definition at all.
A definition list is a list of terms and what those terms mean.
A part, listed with its components seems more appropriately handled with a
table or an unordered list.

-Karl

 

[Jukka K. Korpela]

1 x Assembled Part

I would suggest using the multiplication sign "×" instead of the letter
"x" in such expressions. Looks more professional. If you don't know how
to type the multiplication sign on your keyboard (Alt-0215 works in most
Windows programs), use the entity reference &times;, e.g.
1 &times; Assembed Part

 

[Sam Hughes]

Right, I'll have a go at those. I'm not sure about adjusting the
margins though, how would that work?

If you wanted to adjust the margins, you could use a little CSS.
However, since most browsers (read: all) progressively indent nested
lists in that manner by default, you wouldn't need to do so. I would
mark up the information like this:

<ul>
<li>1 x Assembled Part<br>
consisting of ...
<ul>
<li>5 x Large Bolt</li>
<li>10 x Small Bolt</li>
<li>3 x Assembly 452<br>
consisting of ...
<ul>
<li>1 x Mending Plate</li>
<li>3 x Self-Tapping Screw</li>
</ul>
</li>
</ul>
</li>
<li>3 x Bottle of Oil</li>
<li>5 x Toolkit A<br>
consisting of ...
<ul>
<li>1 x Spanner</li>
<li>1 x Hammer</li>
<li>1 x Stapler</li>
</ul>
</li>
</ul>

 

[Sam Hughes]

<br>

Erm, using <br /> instead of <br> because it is XHTML.

 

[Sam Hughes]

Is the OP's list a list of terms and their definitions? No. So, it
wouldn't be appropriate here.

The use of a definition is is not for terms and definitions; it is for
terms and their _descriptions_. In a sense, that is what the op wants.

Overall, a definition list is just the vertical linearization of a two-
column table into a more comfortable and familiar format for reading.

 

[Jukka K. Korpela]

The use of a definition is is not for terms and definitions; it is for
terms and their _descriptions_.

By definition, that's not true.

Overall, a definition list is just the vertical linearization of a two-
column table into a more comfortable and familiar format for reading.

That is, you are actually using <dl> to achieve a particular layout, just
as so many people use <blockquote> for indentation (who could say that a
block quotation is not for blocks of quoted text but for indented text).

The tragicomic part is that <dl> is a horrendously poor and primitive
tool for formatting text, just as <blockquote> is (it may indent - some
unknown amount, on one side or on both sides). Well, actually more, since
<dl> is an odd bird - it often resists attempts to style it.

But we've discussed this a few times, haven't we? See e.g.
http://www.cs.tut.fi/~jkorpela/def.html#impl

 

[Sam Hughes]

By definition, that's not true.

By which definition? Reading one spec or reading another? And of course,
which spec is the better one?

(Un?)fortunately, through utter (mis?)use, the definition list has lost all
meaning, as shown in the 4.01 spec. Or, removing exaggeration on my part,
it has lost much of its meaning.

The imprecise meaning of "description" as adopted by later specifications
is much more useful through its genericness -- the actual need for
definition lists for definitions themselves are extremely rare. Of course,
the 4.01 spec's example of dialogue is profusely stupid.

That is, you are actually using <dl> to achieve a particular layout,

No, I am saying that a definition list contains tabular data (except in the
super-rare case of a many-to-many combinations of terms and definitions).

 

[Jukka K. Korpela]

By which definition?

By the definition of "definition" in English dictionaries, for example.
Or consult a dictionary of philosophy if you prefer; they have nice
classifications of definitions as well.

(Un?)fortunately, through utter (mis?)use, the definition list has
lost all meaning, as shown in the 4.01 spec.

It hasn't. It still has a defined meaning, despite the fact that the
specification gives absurd examples. Examples are not normative.

Of course, the 4.01 spec's example of dialogue is
profusely stupid.

It just makes it explicit where you end up with if you start distorting
the concept of definition list into description list or whatever you wish
to have formatted in a specific way (without actually realizing how the
specific way you have in your mind is just your browser's odd way of

No, I am saying that a definition list contains tabular data (except
in the super-rare case of a many-to-many combinations of terms and
definitions).

But thinking that way, we find that <table> elements offer _more_
flexibility for formatting than <dl> elements, on the practical side.
On the theoretical side, if you use <table> and not <dl> when you
actually have a genuine definition list, you lose some semantic
information (since a definition list _more_ than just a two-column table:
it expresses a specific relationship, definiendum - definiens relation,
between the elements). I think that's tolerable, but I am willing to
accept the use of <dl> in the case where you really have a list of terms
and their definitions.

 

[Mark Parnell]

It hasn't. It still has a defined meaning, despite the fact that the
specification gives absurd examples. Examples are not normative.

But it's not just the examples.

"Definition lists vary only slightly from other types of lists in that
list items consist of two parts: a term and a description."
http://www.w3.org/TR/html401/struct/lists.html#h-10.3

 

[Sam Hughes]

By the definition of "definition" in English dictionaries, for
example. Or consult a dictionary of philosophy if you prefer; they
have nice classifications of definitions as well.

Hmm? I'm not asking for the definition of "definition;" I'm asking which
definition of a definition list you are typing about.

It hasn't. It still has a defined meaning, despite the fact that the
specification gives absurd examples. Examples are not normative.

But the normative parts are normative, and they refer to terms and
"descriptions," which is the change in meaning to which I am referring.

But thinking that way, we find that <table> elements offer _more_
flexibility for formatting than <dl> elements, on the practical side.

But DL elements are the more practical, for linear reading and sanity.
Also, they offer more flexibility by allowing many-to-many match-ups of
definitions and terms. Tables can do one-to-many or many-to-one match-
ups with rowspan, but not many-to-many match-ups.

Plus, definition lists are easier and more simplistic to mark up
(upmark? =-).

 

[Jukka K. Korpela]

But it's not just the examples.

"Definition lists vary only slightly from other types of lists in that
list items consist of two parts: a term and a description."

That's unnecessarily poor formulation, but it's still about lists of
definitions, with terms (not just any strings you like); and a
description is a way of giving a definition. And a preceding DTD comment
says that DD element is for "definition description".

 

[Jukka K. Korpela]

Hmm? I'm not asking for the definition of "definition;" I'm asking
which definition of a definition list you are typing about.

So you need a definition for "list" too? A definition list is a list of
definitions, apparently.

But the normative parts are normative, and they refer to terms and
"descriptions," which is the change in meaning to which I am
referring.

As I comment in an another message in this thread, it makes things more
obscure, but it does not change the meaning.

But DL elements are the more practical, for linear reading and
sanity.

Hardly. There are several accessibility-oriented markup features that you
can use for tables, and there is support to tables in many different
"different" browsers. Moreover, a simple two-column table (the

Also, they offer more flexibility by allowing many-to-many
match-ups of definitions and terms.

Many-to-many definition lists are extremely rare, basically a contrived
idea. But you have my permission to <dl> for them if you ever actually
need to write a list of genuine definitions where several terms share a
set of definitions.

Plus, definition lists are easier and more simplistic to mark up
(upmark? =-).

They are more simplistic indeed. Whether they easier really depends.
How many authoring tools have functions for entering data into a
definition list, as opposite to functions for entering data into a table?

 

[Andy Dingley]

<li>
3 x Assembly 452<br />
consisting of...
<ul>

I'd avoid using <br /> in XHTML

If, as I strongly suspect, the OP is using XHTML because some
XML-reading 'bot process is going to be processing these same
documents. In that case, a mixed content model like <br /> (both
elements and text as siblings) is a pain to work with, using typical
XML tools.

I'd use this instead:

<li>
<span class="sub-assembly-count" >3</span> x <span
class="sub-assembly-name" >Assembly 452</span>
consisting of...
<ul>


It's verbose, but it's much easier to process downstream.