Re: several messages about <address> and related subjects

Executive summary: I made it that if <address> applies to the body element 
it really applies to the whole document. I did not make <address> suitable 
for all contact information; it continues to be limited to contact 
information for the current section/article/page. I couldn't see a 
convincing use case for the element either as contact information for the 
page nor for any arbitrary contact information, and would probably not 
introduce the element at all if it wasn't for the relatively big existing 
use base, which, as far as I can tell, is mostly using the element 
correctly (at least relative to how HTML is generally misused).


On Thu, 12 Oct 2006, Simon Pieters wrote:
> 
> <address> is currently defined to apply to its nearest ancestor 
> sectioning elements. If you wanted to give contact information for a 
> page you could use an <address> that applies to <body>, but that doesn't 
> cover the entire document (e.g., it doesn't apply to the <title>).
> 
> Perhaps it could be defined so that when <address> applies to the <body> 
> element also applies to the entire document?

Done.


On Thu, 30 Nov 2006, Simon Pieters wrote:
> 
> Shouldn't The address element and The figure element sections be moved 
> to the Paragraphs section?

Arguably. However, <address> is related to sections, so seems to belong 
well there, and <figure> (for now at least) applies to embedded content, 
so seems to belong there too.


On Mon, 26 Feb 2007, Simon Pieters wrote:
> 
> From http://forums.whatwg.org/viewtopic.php?t=5
> 
> | In HTML4, the <address> element was defined as this:
> |
> | | 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.
> |  -- http://www.w3.org/TR/html4/struct/global.html#edef-ADDRESS
> |
> | In WHATWG's HTML5, it's defined as this:
> |
> | | The address element represents a paragraph of contact information for
> | | the section it applies to.
> | |
> | | ...
> | |
> | | The address element must not be used to represent arbitrary addresses
> | | (e.g. postal addresses), unless those addresses are contact information
> | | for the section.
> |  -- http://www.whatwg.org/specs/web-apps/current-work/#the-address
> |
> | This seems to be quite a rare scenario to have an element dedicated to.
> | If it were more general, surely the element would become more useful?
> | Somewhat like <dl> being used for more than just dictionary-like
> | definitions.
> |
> | As examples (numbered for convenience):
> |
> |  * A general point of contact where messages would ultimately get passed
> |    on to the person responsible for the section where the <address> was
> |    found.
> |  * People or departments responsible for more than that section.
> |  * People or departments of the organisation the website is for, even if
> |    they are not directly responsible for the section in which the
> |    <address> occurs. (Example: Calthorpe Park School's contact page. [1])
> |  * Member's profiles in forum and other social network systems, who have
> |    limited control over that section. (They can edit their own contact
> |    details and perhaps other personal information in that section, but
> |    don't work for the website.)
> |  * Providing contact details of any type for any person or organisation.
> |
> | It may also be more intuitive that an element with a fairly generic name
> | like "address" have fairly generic semantics.
> |
> | Are there any implementations which rely on the current semantics?
> | (AFAIK, there aren't.)
> |
> | So then, should <address> be more general-purpose? (I think it should,
> | if you hadn't guessed!)
> |
> | [1] http://calthorpepark.hants.sch.uk/contact.htm

(Ironically, the example given uses it correctly now. :-) )

Making it general purpose means we lose the contact-information angle, 
which could be an issue...


On Tue, 27 Feb 2007, Benjamin Hawkes-Lewis wrote:
> 
> Would generalizing address to that extent prevent automated agents being 
> able to distinguish an <address> for a <article> (e.g. a blog comment) 
> from an <address> mentioned in a <article>? This would make it more 
> difficult to construct functionality for citing by or replying to 
> author. Creating an <author> element might help resolve that problem for 
> new content, but then agents would have to sniff content to work out 
> what sort of content was under investigation. A better alternative might 
> be a new element <contactinfo>, which is a more general name than 
> <address> and doesn't make old content more ambiguous.

I don't think we want to introduce a new element for this. That's 
expensive and confusing, and the element isn't that well used as it is.


On Tue, 27 Feb 2007, Simon Pieters wrote:
> 
> Yes. Do UAs need to know the scope of the <address>? What could they do 
> with this information? (If it is important, then we could use a class 
> name or a new attribute for this IMHO.)
> 
> <address> has been around forever. Yet no UA has done anything useful 
> with its semantics as far as I know. That suggests to me that the 
> use-case is not a real-world one. Isn't it better to make <address> more 
> general so that its semantics is more like how most authors use it so 
> that it becomes a convenient styling hook for authors?

It's not clear to me that <address> really is mis-used that much.

I agree that its current semantic isn't used much; but then, neither would 
the more general semantic, and in the meantime we're making a bunch of 
existing pages wrong (unless we make the new semantic "any contact 
information for anything", which seems more vague than ideal).


> I don't think it's a good idea to invent a new element when the use-case 
> is so weak that most authors don't bother using it and no UA have 
> implemented anything useful with it. I'd rather drop <address> 
> altogether.

I don't think we can realistically do that. It's used quite a bit.


On Tue, 27 Feb 2007, Benjamin Hawkes-Lewis wrote:
> 
> That there should be a way of expressing the scope of contact 
> information is more important than the more technical question of 
> whether it's in an attribute or element or registered class name. 
> Obviously specifying an element or attribute is preferable, as then UAs 
> would be substantially more likely to do something with it.

Not much more likely, it seems.


> An <author> element might kill several of these birds with one stone.

Could you elaborate on what such an element would mean?


On Tue, 27 Feb 2007, Simon Pieters wrote:
> 
> I do think authors have use for an element for "any contact info", but I 
> think using <address> for this and dropping the "page (or section) 
> author contact info" semantics is better than using two elements. If UAs 
> or tools get around to implement anything useful with the current 
> semantics of <address> then I'll reconsider.

Is there any great advantage to having an element for all kinds of contact 
information? I'd rather not loosen the semantics without a gain of some 
kind.


On Tue, 27 Feb 2007, Andy Mabbett wrote:
> 
>         <http://microformats.org/wiki/adr>
> 
> The latter has better granularity, allowing for street-address, 
> locality, region, country and postcode, for example, to be marked up 
> separately.

This seems like a fine solution to me.


On Tue, 27 Feb 2007, Colin Lieberman wrote:
> 
> Andy - one of my first thoughts when reading through the HTML5 spec was 
> that one of the benefits of dramatically improving available markup 
> would be getting rid of the need for microformats-type approaches.

Microformat-like formats provide a way to extend HTML in a way that 
augments the existing semantics of a document, so that you have good 
backwards compatibility to user agents that don't support the classes in 
question, with additional semantics available to those users who are aware 
of the format. I don't think HTML5 will ever be able to completely replace 
all the needs of everyone, nor do I think we should try. Thus there will 
always be a need to extend HTML, e.g. with Microformats.


> Perhaps what's needed is a type attribute ("postal", "email", etc) as well as
> a rel attribute ("author", "contact", "example", etc.). Maybe it would be
> useful to have a "for" attribute:
> <address type="postal" rel="contact" for="cal_08_07">...</address> would
> signify a postal contact address for the content of the element with id
> cal_08_07.

It's not clear to me that authors actually want or need this.


> I think it's useful to look at microformats as examples of very real 
> needs that HTML doesn't meet, and work to incorporate those solutions in 
> HTML.

For the commonly used ones I agree... is "adr" seeing much use in the 
wild?


On Tue, 27 Feb 2007, Simon Pieters wrote:
> 
> Ease of use, mostly. It's simpler to say:
> 
>    <address>665 3rd St.<br>
>    Suite 207<br>
>    San Francisco, CA 94107<br>
>    U.S.A.</address>
> 
> ...than:
> 
>    <div class="adr">
>     <div class="street-address">665 3rd St.</div>
>     <div class="extended-address">Suite 207</div>
>     <span class="locality">San Francisco</span>,
>     <span class="region">CA</span>
>     <span class="postal-code">94107</span>
>     <div class="country-name">U.S.A.</div>
>    </div>

...but what's wrong with?:

    <p>665 3rd St.<br>
    Suite 207<br>
    San Francisco, CA 94107<br>
    U.S.A.</p>


On Tue, 27 Feb 2007, Keryx Web wrote:
> 
> In all fairness, that's not equivalent information. The first is no way 
> near able to be parsed by a machine, converted to vCard, imported into 
> an address book, etc.

Google seems to manage it fine...


On Wed, 10 Oct 2007, Henri Sivonen wrote:
> On Oct 9, 2007, at 13:42, Henri Sivonen wrote:
> > I have taken "inline-level content" to mean "structured inline-level 
> > content" when it appears as a content model, but I think it would be 
> > better for the spec to explicitly say "structured inline-level 
> > content" in content models.
> 
> Except in the case of the content model of <address>, it seems.
> 
> <address> should take strictly inline-level content only for backwards 
> compat reasons, right?

<address> is now allowed to take any prose content.


On Tue, 11 Dec 2007, Anne van Kesteren wrote:
> On Tue, 11 Dec 2007 11:03:17 +0100, Ian Hickson <ian@hixie.ch> wrote:
> > On Tue, 13 Feb 2007, Matthew Raymond wrote:
> > > A <name> element may have some uses, such as providing a hook for adding
> > > people to your contact list:
> > > 
> > > | <address>
> > > |   <name>John Hopkins</name><br>
> > > |   Phone: (359) 555-1701
> > > | </address>
> > 
> > Notwithstanding what I consider misuse of <br> in that example, I 
> > would encourage people to use hCard to mark up a name instead of us 
> > introducing an element for the purpose.
> 
> How would you mark that up instead? <address> (currently) doesn't allow 
> block-level descendents.

That has now been fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 21 February 2008 19:34:06 UTC