Re: XHTML 2.0: Suggestion for <addr/> and <blockaddr/> to replace <address/>

Jukka K. Korpela wrote:

>On Mon, 1 Dec 2003, Christian Wolfgang Hujer wrote:
>
>>ince <quote/> and <blockquote/> as well as <code/> and <blockcode/> are
>>counterpart for quotes or listings, I suggest to replace <address/> with
>><addr/> and <blockaddr/>.
>>    
>>
>That would be logical in a sense, though one might question the very idea
>of having inline and block versions of elements. Isn't the distinction
>basically presentational?
>
  No, it's not presentational, its the result of not being able to 
specify content models that change depending on the parent element.  If 
there were no distinction between inline an block, then you could have 
things like paragraphs inside span elements (<span><p>...</p></span>), 
so the distinction is necessary.
  We also need sepearte address elements for block and inline, even 
though both elements would represent addresses (or code and quotes in 
the case of <blockcode>/<code> and <blockquote>/<quote> elements), 
because it is impossible to specify that an <addr> element can contain 
block elements when it's parent is block, and inline when it's parent is 
inline.

>Besides, what's the point in <address> in the first place? It's an old
>element, which has been widely used against its definition: it has been
>used in general for addresses, not for contact address of the _document's
>author_. And we really cannot blame authors for this confusion, since the
>name is particularly poorly chosen.
>
  I agree.  I thought the address element was for marking up any 
address, whether it was for the author or not.  I too made that same 
mistake recently when I wanted to write a postal address (not for the 
author) in a document, but discovered that it wasn't meant for that 
general use.  However, I think it, or some new element should be for 
that purpose.  I really don't think it's necessary to have it purely for 
the authors contact details, since meta tags, or RDF could handle that.  
Also, it would be much more useful if it were more general.

>...However it might be better to define some internal structure for it,
>instead of mere line structure. Or it might be named just <postal>,
>for specifying a physical address, whereas various Internet address
>are, in a natural way, covered by the elements for linking.
>
  I think that's too specific since it might not be just used for postal 
addresses.  it could be used for email addresses, URIs or any other form 
of address you can think of.  But then, what about phone numbers?  
That's still contact information, yet there is not <phone> element.  How 
about some new <blockcontact>/<contact> elements be introducted.

  <contact> is more generic than address so it could hold emails, URIs, 
street addresses, or phone numbers, etc...  If  we continued using 
<address>, then it would conflict with it's current definition as being 
for the author only, whereas <contact> won't.

CYA
...Lachy!

Received on Tuesday, 2 December 2003 08:12:12 UTC