Should <address> be more general-purpose? (In HTML5)
Home / Web Technology / Should <address> be more general-purpose? (In HTML5)
The Web Hypertext Application Technology Working Group (WHATWG) has recently created The WHATWG Forums Forum.
I've made my first topic there, called Should <address> be more general-purpose?. This is a subject I've seen debated from time to time. Now we have an opportunity to influence its semantics in HTML5 without having to use a mailing list.
I'm not sure if W3C will be open to changing the meanings of established HTML elements, so this might be for naught.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Last edited by Ben Millard on 22 Feb 2007 07:10 pm; edited 1 time in total
Share: 
| Cerbera wrote: |
| I'm not sure if W3C will be open to changing the meanings of established HTML elements, so this might be for naught. |
_________________
Simon Pieters
Share:
To be honest, I never use <address>. Is there any practical benefit in doing so?
Share:
| kiwibrit wrote: |
| To be honest, I never use <address>. Is there any practical benefit in doing so? |
a fuzzy warm feeling that you're being plus-parfait, semantically...and the hope that, in future, there may be some user agent or automated robot that actually makes use of it...
_________________
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
| redux wrote: | ||
a fuzzy warm feeling that you're being plus-parfait, semantically...and the hope that, in future, there may be some user agent or automated robot that actually makes use of it... |
Hmm... I'll take that as a 'no' then
_________________
Jack Pickard The Pickards Information Services| Blog | Twit
Share:
But what about the infinite possibilities of a truly semantic web!?!? 
I think its more likely that someone (Google) will develop a reliable 'smart' algorithm for determaning addresses and their related information on a page, than it is that the whole, or even a significant proportion of the web actually start using these tags.
Or am I being defeatist?
_________________
creator of Talklets
Talklets ,
Share:
I think the main benefit would be it allows markup to be a bit more logical and easier to style on contact pages and suchlike. Instead of <p class="address"> and .address { ... } you'd have <address> and address { ... }.
Since the element is rarely used, I thought the discussions for HTML5 would be a good time to try and make it more useful.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
I'm with Cerbera. It should be for anyone's address, including postal address format._________________
www.brucelawson.co.uk
Web Evanglist, Opera, WaSP Accesibility Task Force
Study the Web Standards Curriculum
International Lothario (retired)
Share:
I'm slowly integrating <address> into most of my current employers website - The company now has to add extra information to our usual email disclaimer with VAT Reg Numbers and company registration numbers etc etc.
They also wanted this on the website and I find (although not semantically correct) <address> is useful for this information aswell as usual contact info.
www.wautonsamuel.co.uk
M
Share:
I still think <date> with an attribute for country would have been far superior tag. Using this thought process postcode/zip tag too. <address> is a rather pointless IMO._________________
Johan De Silva / Portfolio | Place of Work @Flipside | Read my movie reviews punk!
Share:
+1 vote for genericising the address element for use with any address.
I don't think the fact that Google may or may not plan to spot addresses is relevant. Google is not (yet) a universal parser through which all data is exchanged, but a specific service.
If we're searching for addresses via Google, then that's one thing, but I'd like my UA to be able to spot address details based on the semantics of the markup, rather than through the intervention of a 3rd party such as Google.
I think the likely low adoption rate is also irrelevant. Markup is about semantics. It's about what's best/right (by virtue of what makes most sense), not what's likely to prove popular.
That said, genericising the address element will almost certainly be seen as a popular move which is likely to increase its uptake.
Like Patrick (and doubtless others here), I use the address element in a way which, whilst currently technically incorrect, I believe can be potentially more useful now and which will be recognised as more appropriate in future.
Share:
| Johan007 wrote: |
| I still think <date> with an attribute for country would have been far superior tag. |
There is <time>, btw.
_________________
Simon Pieters
Share:
| zcorpan wrote: | ||
|
1. The first of Feb 2006 (UK)
2. The second of Jan 2006 (US)
3. 1 divided by 2 divided by 2006
If we knew the country format US or UK a devices would then know how to display or read out the date.
| Code: |
| <date lang=”en-GB”>1/2/2006</date>
<date lang=”en-US”>2/1/2006</date> |
Sure you can just write "Jan" etc... but when dealing with db's it is often just easier to write in numbers.
_________________
Johan De Silva / Portfolio | Place of Work @Flipside | Read my movie reviews punk!
Share:
Check Simon's link to the <time> element proposed in HTML5. Basically, if you wrap a <time> element around an arbitrary date you can use the datetime attribute to specify it in the standardised format HTML5 UAs will understand. (If the proposal gets implemented, that is.)
For example, I think this would be acceptable:
| Code: |
| <time datetime="2006-02-01">1/2/2006</time> |
Some languages can use different date formats. Knowing lang wouldn't be enough for UAs to unambiguously determine the date every time. Requiring UAs to hardcode an index of every date format supported by every possible language would probably be an unpopular implementation requirement. Even if lang represented a country (which it doesn't), the the formats they officially support can change which means UAs would get out of date. There's also a lot of problems with regional timezones, which can change frequently in unsystematic ways (such as non-standardised "daylight saving" sessions).
By having a datetime attribute using a standardised format, HTML5 UAs can use one algorithm which doesn't change.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Cerbera wrote: | ||
| Check Simon's link to the <time> element proposed in HTML5. Basically, if you wrap a <time> element around an arbitrary date you can use the datetime attribute to specify it in the standardised format HTML5 UAs will understand. (If the proposal gets implemented, that is.)
For example, I think this would be acceptable:
Some languages can use different date formats. Knowing lang wouldn't be enough for UAs to unambiguously determine the date every time. Requiring UAs to hardcode an index of every date format supported by every possible language would probably be an unpopular implementation requirement. Countries occasionally change the formats they officially support, so UAs would get out of date. |
There's different calendars in use around the world at different times too, eg. the date of the October Revolution would (I think) be
| Code: |
| <time datetime="1917-11-07">25th October 1917</time> |
Dates are a pain to deal with, particularly years earlier than 1753.
_________________
Jim O'Donnell
work: Royal Observatory Greenwich
play: eatyourgreens
Share:
Page 1 of 1
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum