Using Microformat for address and coordinate output
Tobias Maier - November 22, 2006 - 17:49
| Project: | Location |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | duplicate |
Description
It would be a great benefit to use Microformats for the address output.
I think that the hcard-Microformat or the geo-Microformat fits.
What do you think about this?
#1
here comes the first patch for this.
Changes:
theme_location()andtheme_location_de()One issue/question: What should we do (which hcard-class) with $location['name']? We can't say if it is the organization or the name of a person or anything else...
?>at the end of location.inc and location.de.inc#2
I forgot to mention that I added the $hide argument for functions like theme_location_de()...
btw. it seems like that this function can't be overwritten (like every other theme-function)
#3
since the class "fn" is required I added this one to $location['name']
#4
Here is an example you can find on one of my sites:
standorte/waschsalon-albertrosshaupterstrasse-munchen
btw. I like the Tails extension for Firefox 2.0 to view and export microformats from websites.
#5
This patch looks much bigger than it should, I'm guessing it's a line ending problem, either unix or windows based.
Not sure if location module had it wrong or your patch but be good to double check that :-)
#6
it is so big, because I removed blanks in the end of lines...
They were so much so that this patch got far too big...
I putted this in an own patch: http://drupal.org/node/100830
it is really not an important patch, but the code looks cleaner IMHO...
#7
I hope this patch works...
is clean now..
#8
Building on the patches above, I added http://microformats.org/wiki/geo support. My patch definitely needs review because a) I applied the above patches manually and ended up moving around some curly braces (some possibly in the wrong spot).
#9
Oh man. I gotta learn about microformats and geo-microformats before I can even test these patches? Any volunteers? I'm curious myself, but can't expense the time at the moment.
Taking a quick look at the microformat classes, I'm anxious to get both 'geo' and 'adr' class support.
Richard, if you're not sure your braces are in the right places, would you mind testing it and seeing if it works and outputs the appropriate HTML?
Tobias, would you be willing to a look if you get a chance. I would like to commit a verifiedly working version of this patch soon.
-Ankur
#10
I added Richards' patch to my one and made it translatable
You can see it live at
http://www.muenchner-waschsalon.de/standorte/waschsalon-aidenbachstrasse...
But to be honest: I dont like the way lat/lon gets presented to the end user.
my second thought is that I dont even know if we should bother the end-user with such specific data like this...
#11
oh sorry
I tried a new editor which added a few new tabulators instead of two blanks.
here comes the corrected patch
#12
Hello Ankur,
whats your opinion about this?
Personally I prefer the version without lat/lon (#7).
#13
Yeah, it would probably look aesthetically displeasing to have the lat/lon displayed for every address that has a pair figured out. Perhaps we can make it something configurable? or leave it up to the themer if the themer chooses to replace the theming function with one of their own.
Will update the patch so that it is configurable.
In the meantime, do microformats support fields that can be a part of a microformatting, but somehow hidden and parseable by something that collects microformat data?
#14
Sure, you could hide the microformat text using CSS.
Would be a technique similar to one of these: http://www.mezzoblue.com/tests/revised-image-replacement/
That would probably be the best be to comply fully with the microformat, no?
#15
For reference, this is exactly what Flickr does as evidenced here:
<div style="position: absolute; right:7px; bottom:7px; font-family: Arial; font-size: 11px; color: #999"><i>40°24' 54" N, 3°41' 57" W<span class='geo' style='display:none'><span class='latitude'>40.414933</span><span class='longitude'>-3.699259</span></span></i></div>#16
the right way to do the same what flickr does is
<span class='geo'><abbr class='latitude' title="40.414933">40°24' 54" N</abbr>, <abbr class='longitude' title="-3.699259">3°41' 57" W</abbr></span>and if you want to never show it then this should be right
<span class='geo'><abbr class='latitude' title="40.414933" /><abbr class='longitude' title="-3.699259" /></span>see point 5 of http://microformats.org/wiki/hcard#Semantic_XHTML_Design_Principles
#17
Tobias, right on.
And we should *not* hardcode display:none, that should go into the CSS file.
Just wanted to illustrate the point that we can use the full geo format and CSS to hide what we don't need, just like Flickr. That way people can use CSS to turn on and off what they don't want.
Seems like that solves this issue -- time for an updated patch?
#18
allright, here it is
it uses
<abbr />to hide latitude and longitude in general#19
+1
Haven't tested the patch yet, but I like the idea of adding microformats for the addresses, and it fixes #109954 as well, which didn't close the tags properly in the .de include.
#20
Applied to DRUPAL-4-7 and DRUPAL-5
#21
subscribing
#22
Pancho, you're subscribing to an issue that's been marked fixed? Did the application of this patch break something?
#23
#24
I have just spotted a little bug in this: the latitude variable is being used twice, one in the right place and one in place of the longitude variable. Also, I can't see this in the current 5.x version of location.inc. Was it intentionally taken out in 1.45.2.5?
For testing these out by the way, the Operator toolbar for Firefox is very handy.
#25
Has this been fixed?
#26
It moved to the .theme file.
Fixed in seperate issue, thanks.
#27
Committed a followup change to follow the recommendation from #16