On 8/2/07, Andy Mabbett <[EMAIL PROTECTED]> wrote: > I addressed this in: > > <http://microformats.org/wiki/hcard-brainstorming#ADR_with_no_children>
I've been trying to find an explanation of what 'extended-address' actually means, the examples in the vCard spec seem to omit it. >From its order in the sequence of the fields in ADR, however, I think it's reasonably clear that it's more specific than the street address, so would be something like 'Flat 2b'. This also seems to be the common usage in hCard. For those reasons I'm unconvinced about putting all the address data available into that one field. It might be useful if someone could experiment with conforming agents to see if they can take multi-line imput for different ADR fields? > but people (Brian Suda, chiefly) insisted that my suggestion should not > be followed, and that such addresses should instead be wrapped with > class="label" - which is supposedly for: > > "formatted text corresponding to delivery address" > > Note the use of "formatted". Can you elaborate on what the issue is there? Most text on web pages is formatted, and I think in this context it just means 'with linebreaks' which fairly simple parsing rules would solve. My main hesitation about using LABEL is that it isn't part of ADR and so isn't appropriate for the ADR-without-hCard usages. > More recently, Tantek added: > > <http://microformats.org/wiki/hcard-brainstorming#implied_adr_subproperties> > > which strikes me as unworkable, being overly complex and not suitable > for internationalisation (not just in non-English speaking countries, > but outside the USA) I agree that i18n issues make this a bit too strict (I have similar reservations about the implied-n optimisations but that's tangential). IMO it may be that the best option is to say that ADR can exist without subproperties for hCard / solo-ADR use for the purposes of semantically expressing 'hey this is an address' but then to offer no mapping to vCard unless the sub-properties are present. -Ciaran McNulty _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
