[uf-discuss] adr should be <address>

[Tantek Ç elik]

(below thread(s) kept only for context)

Two Q&A, and two suggested improved behaviors.


Suggested improvements:

1. Before asking a question on a microformats list, read the relevant
FAQs[1].

2. When answering a question on a microformats list:
  a) please check the relevant FAQs first, and if the answer is not there,
document the question and your answer there.
  b) please cite the FAQ answer rather than writing an answer in email.

I have added these to the mailing-lists page:

http://microformats.org/wiki/mailing-lists#General_guidelines

Following #2 gives the following:


Q&A:

1) James Craig: Isn't <address> the most appropriate element for addresses?

See: http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards

2) Thom Shannon: The documentation using only divs and spans, so people
don't get confused and think that the element types matter. Obviously people
should use the most suitable elements in the context they're using them. But
I think this should be made much clearer in the wiki.

See: http://microformats.org/wiki/faq#.3Cdiv.3E_and_.3Cspan.3E_semantics


Thanks,

Tantek


[1] Relevant FAQs
1. Start with the general microformats faq: http://microformats.org/wiki/faq
2. Then read specific microformats faqs, e.g. for adr, see hCard FAQ as the
spec points to: http://microformats.org/wiki/hcard-faq


On 2/25/07 3:19 PM, "Thom Shannon" <thom at ts0.com> wrote:

> Brian Suda made a point at barcamp about the documentation using only
> divs and spans, so people don't get confused and think that the element
> types matter. Obviously people should use the most suitable elements in
> the context they're using them. But I think this should be made much
> clearer in the wiki.
> 
> Christian Heilmann wrote:
>> James Craig wrote:
>>> My recent adr wiki change from <div class="adr"></div> to <address
>>> class="adr"></address> was reverted.
>>> 
>>> Why? <address> is the most appropriate element for addresses.
>> 
>> Only if the address is directly related the web page it is published
>> on. The address element is meant as a physical locator of the document
>> maintainer, not for any old address:
>> 
>> http://www.w3.org/TR/html4/struct/global.html#h-7.5.6
>> 
>> The ADDRESS element may be used by authors to supply contact
>> information for a document or a major part of a document such as a
>> form. This element often appears at the beginning or end of a
>> document.

On 2/25/07 5:10 PM, "Jason Karns" <karnsj at cse.ohio-state.edu> wrote:

> An additional reason, is that the <address> element cannot contain
> block-level children, so  to have block-level children, you would need a
> block-level parent.
> 
> Jason
> 
>> -----Original Message-----
>> From: microformats-discuss-bounces at microformats.org
>> [mailto:microformats-discuss-bounces at microformats.org] On
>> Behalf Of Thom Shannon
>> Sent: Sunday, February 25, 2007 7:18 PM
>> To: Microformats Discuss
>> Subject: Re: [uf-discuss] adr should be <address>
>> 
>> Sorry Ben! it was you. And you're right, the examples in the
>> docs are a bit misleading.
>> 
>> Ben Ward wrote:
>>> 
>>> On 25 Feb 2007, at 23:19, Thom Shannon wrote:
>>> 
>>>> Brian Suda made a point at barcamp about the documentation
>> using only 
>>>> divs and spans, so people don't get confused and think that the
>>>> element types matter. Obviously people should use the most
>> suitable 
>>>> elements in the context they're using them. But I think
>> this should 
>>>> be made much clearer in the wiki.
>>> 
>>> Actually it was me who made that point, unless Brian did as well,
>>> separately from the panel. Anyway.
>>> 
>>> Some time ago I suggested we put a disclaimer at the top of
>> each spec 
>>> making it clear that SPAN/DIV are used for example purposes
>> and then 
>>> have a new set of 'rich examples', complementing the existing ones,
>>> showing more diverse mark-up in use with microformats.
>>> 
>>> Unfortunately I suck and haven't had the organisation to do
>> anything 
>>> with it, Though it remains on my to-do list.
>>> 
>>> Ben