Re: Property list elements?

Jukka K. Korpela scribbled something along the lines of:

> On Tue, 13 Apr 2004, Edwin van Vliet wrote:
>>Might an extra type of list be useful? One that exists of properties and
>>values. It would have to be some kind of mix between a table and a
>>definition list.
> It looks like a table to me. It's really a table with two columns, isn't
> it?

It is derived from the definition list for sure.

>>   <pn>color</pn><pv>#000000</pv>
>>   <pn>background-color</pn><pv>#FFFFFF</pv>
>>   <pn>font-family</pn><pv>arial, helvetica, sans-serif</pv>
> That would be
> <table>
>   <tr><td scope="row">color</td><td>#000000</td></tr>
>   ...
> wouldn't it? And in a table, you could use various additional markup,
> like <thead> with column headers in it, or <caption>, or
> summary="...", etc.

In that case it also would be semantically the same as:

    <dt>font-family</dt><dd>arial, helvetica, sans-serif</dd>



(arial, helvetica and sans-serif are three properties in this case - 
this may not be wanted as this seems to be a marked up CSS style, but 
may very well be useful in some cases)

IIRC the contents of dl are defined as


The contents of this derived dl (your pl) would be defined as

(dt, dd)*

The semantic contents are the same as with a normal dl, it's just the 
order that is defined more strictly.
Also note that the freedom dl provides allows things like


(although this is not exactly the best example, but I wanted to stick to 
CSS properties here).
This allows having multiple properties share a value.

As for the other variant suggested:

   <prop><pn>font-family</pn><pv>arial, helvetica, sans-serif</pv></prop>

That's a normal two-column table indeed. Just again with a stricter order.

>>It is something else
>>than a definition list, in my opinion.
> Certainly. You would not define the term "color" but specify a value for
> "color", and the reader must be assumed to already know what the term
> "color" means. That is, you implicitly postulate the existence of a
> definition, instead of giving one. Beware that what HTML specifications
> say about <dl> is just great confusion - they first define it as a
> definition list, and this is what he can reasonably regard as the
> normative definition of the semantics, and then they go on and discuss and
> show all kinds of stuff where <dl> is only used to get a particular visual
> appearance (which browsers are expected to use, without really saying it,
> and which is very poorly implemented in browsers, really).

A definition list does not neccessarily define the meaning of the 
definition term(s) in the definition description(s). That is not a 
correct assumption.

The (X)HTML spec explicitly states that definition lists does not have 
to say anything about the exact relation between the term and 
description. It may be used to describe a property-value relation, just 
as well as it may be used to describe a navigational hierarchy or a 
character-speech relation in a dialog (where common sense suggests that 
it's usually only one dt (character) followed by one dd (dialog text) 
although it could be multiple dts if it is more than one character 
saying something -- like a chorus, for instance).
The term "definition list" may be misleading here.

>>I think such property
>>list elements may also be used in forms. Actually, this is the reason I
>>came to think about these new elements, since dl and table elements are
>>not really suitable elements, I think.
> <dl>, surely not. <table>, why not - this is an old debate, and there's
> really no reason not to use <table> for tabular data like
> (label, field) pairs. But you can also use just <div> and specify the

Wrong again. <dl>s could very well be used to order forms semantically, 
although <label>s (with the for-IDREF) are supposed to give enough of a 
relation in a form. The styling is of no concern - that is a CSS issue.

>>I think the list should be rendered like some sort of table by default.
>>The pn behaving much like a th and/or dt element, the pv behaving like a
>>td and/or dd element.
> So what would be the point of defining a special element to be used for
> two-column tables?

Nothing. At least not in HTML. Nobody stops you from writing your own 
XHTML family member by writing a DTD utilizing the Modularisation of 
XHTML / XHTML 1.1 [1] DTD modules.

Defining such a specialised table/dl is beyond the scope of the 
unspecialised hypertext markup language XHTML is. We don't need another 
case of featuritis.

Alan Plum, WAD/WD, Mushroom Cloud Productions

Received on Wednesday, 14 April 2004 07:51:53 UTC