Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
Tantek wrote: The microformat chunks (e.g. hCards, hCalendar events, hReviews etc.) that have an id attribute are much easier to automatically reference (and thus link to and browser/scroll to from search results) than those without. +1 I absolutely think that IDs make referencing easier but I'm thinking more about IDs on the elements *containing* the hCard(s) rather than on the hCard itself. I've been working on a JavaScript hCard/GoogleMaps mashup (building on what I did for http://austin.adactio.com/) with the aim of releasing it for anybody to use on their site (the more tools that encourage people to use microformats, the better). I want it to be modular so that people can have more than one map per page. To do this, the script currently takes a single required argument: the ID of a containing element for a series of hCards. Here's a working demo of what I've got so far: http://2006.dconstruct.org/location/ The JavaScript is here: http://2006.dconstruct.org/scripts/map.js Unfortunately, it isn't quite as simple as add this script tag to your document for anybody to use this: the Google Maps API demands that each domain has their own API key so anyone who would want to use this would have to go off to Google first (register if they don't yet have an account), and request an API key. That's a few too many hoops to jump through. :-( But anyway, back to the topic at hand... When you mark up people/companies as hCards or hCalendar events or hReviews, along with other things on a single page, try using an id attribute on the root element (the element with class=vcard etc.) and report back how ti works with you. If this works for folks, I'll add it to hcard-authoring as a recommended good practice. Regardless of my wish for an ID on the über-element containing the hCards/hCalendars/hReviews, the idea of associating unique a ID with a specific microformat chunk sounds like a good one to me. If a convention arose for people to mark up their own hCard with something like id=author or id=me, then it would be easier for people to build/use tools to extract just that single hCard, leaving any others on the page alone if desired. Perhaps this is something that could also be recommended as a best practice... if enough people start doing it, that is. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
On 23 Jun 2006, at 09:52, Jeremy Keith wrote: Tantek wrote: The microformat chunks (e.g. hCards, hCalendar events, hReviews etc.) that have an id attribute are much easier to automatically reference (and thus link to and browser/scroll to from search results) than those without. +1 I absolutely think that IDs make referencing easier but I'm thinking more about IDs on the elements *containing* the hCard(s) rather than on the hCard itself. I'm slightly wary of any pattern that prescribes doing anything outside the root element of a given µF. context. One proposal would be to introduce a very simple pattern for groups of hCards - just like groups in address book programs (friends, family, collegues etc). In XHTML we already have a mechanism of grouping elements - the class attribute. So how about treating hCards that share a common class name other than 'vcard' as a loose group? div class=vcard brighton div class=fnJeremy Keith/div /div div class=vcard brighton div class=fnAndy Budd/div /div div class=vcard div class=fnDrew McLellan/div /div Granted, there's danger of the concept duplicating problems already solved by either XFN, or by intrinsic groupings already created by the values within the hCards themselves. Most groupings I imagine are based on location, companies, or XFN properties like friends, collegues, family. I think we'd also need to see more real-world examples to demonstrate a need for something like this. I guess two examples would be your d.Construct Locations page, where groups are travel, accomadation, freewifi, etc, and the LPG site I did the other week where all my hCards were gas stations, and would be sensible to group as such. It gets more complex with the d.Construct case, though, where you'd actually want to group everything overall into one 'dconstruct' group too. e.g. div class=vcard travel dconstruct div class=fn orgBrighton Train Station/div /div The above would belong to the travel group and the dconstruct group. I'm not sure how a parser would know how those should be nested, however. (Does each of travel, accomodation, freewifi contain a dconstruct group, or does the dconstruct group contain the others?). So you'd need rules about group name exclusivity .. and all in all I think I've talked myself out of the idea ;) drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
On 6/23/06, Drew McLellan [EMAIL PROTECTED] wrote: One proposal would be to introduce a very simple pattern for groups of hCards - just like groups in address book programs (friends, family, collegues etc). In XHTML we already have a mechanism of grouping elements - the class attribute. So how about treating hCards that share a common class name other than 'vcard' as a loose group? div class=vcard brighton div class=fnJeremy Keith/div /div div class=vcard brighton div class=fnAndy Budd/div /div div class=vcard div class=fnDrew McLellan/div /div I think it's only logical. However, using IDs is what gives the capability to address a specific microformat content outside of the context of the document (URL, in less fancy words). How would one use classes to do the same? :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
On 23 Jun 2006, at 11:51, Dimitri Glazkov wrote: On 6/23/06, Drew McLellan [EMAIL PROTECTED] wrote: One proposal would be to introduce a very simple pattern for groups of hCards - just like groups in address book programs (friends, family, collegues etc). In XHTML we already have a mechanism of grouping elements - the class attribute. So how about treating hCards that share a common class name other than 'vcard' as a loose group? div class=vcard brighton div class=fnJeremy Keith/div /div div class=vcard brighton div class=fnAndy Budd/div /div div class=vcard div class=fnDrew McLellan/div /div I think it's only logical. However, using IDs is what gives the capability to address a specific microformat content outside of the context of the document (URL, in less fancy words). How would one use classes to do the same? Oh, it wouldn't. I was thinking more along the lines of Jeremy's idea of addressing a group of hCards. As for addressing an specific hCard from outside the document, then indeed, we just need a small set of ID conventions. An ID must be unique in a document of course, so these should be namespaced in some way, so as not to force publishers to rework existing documents. e.g. 'author-vcard', not just 'author'. The only requirement on parsers then should be fragment support, which is already a requirement. drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
At first look i really like this idea, but then i though about it for a minute You are adding 'brighton' into the class attribute, which violates the human readable aspect of Microformats. This would be better... div class=vcard span class=fnJeremy Keith/span in span class=groupBrighton/span /div in hCard there already is a property for grouping, class=category so you could use div class=vcard span class=fnJeremy Keith/span in span class=categoryBrighton/span /div or even a class=category rel=tag href=http://en.wikipedia.org/wiki/Brighton;Brighton/a Then you could begin to make a distributed web-sized group. It is slightly more difficult for a parser to find a class=category, then look up the tree and see if it is a child of class=vcard rather than putting them both on the root-element. The other downside to adding semantics outside of the scope of hCard, is that it is impossible to determine if it is a CSS style or a semantic attribute. div class=vcard brighton call-out-box.../div is call-out-box also a group or a style? I would recommend looking into using the category property for groups. -brian Drew McLellan wrote: I'm slightly wary of any pattern that prescribes doing anything outside the root element of a given µF. context. One proposal would be to introduce a very simple pattern for groups of hCards - just like groups in address book programs (friends, family, collegues etc). In XHTML we already have a mechanism of grouping elements - the class attribute. So how about treating hCards that share a common class name other than 'vcard' as a loose group? div class=vcard brighton div class=fnJeremy Keith/div /div div class=vcard brighton div class=fnAndy Budd/div /div div class=vcard div class=fnDrew McLellan/div /div Granted, there's danger of the concept duplicating problems already solved by either XFN, or by intrinsic groupings already created by the values within the hCards themselves. Most groupings I imagine are based on location, companies, or XFN properties like friends, collegues, family. I think we'd also need to see more real-world examples to demonstrate a need for something like this. I guess two examples would be your d.Construct Locations page, where groups are travel, accomadation, freewifi, etc, and the LPG site I did the other week where all my hCards were gas stations, and would be sensible to group as such. It gets more complex with the d.Construct case, though, where you'd actually want to group everything overall into one 'dconstruct' group too. e.g. div class=vcard travel dconstruct div class=fn orgBrighton Train Station/div /div The above would belong to the travel group and the dconstruct group. I'm not sure how a parser would know how those should be nested, however. (Does each of travel, accomodation, freewifi contain a dconstruct group, or does the dconstruct group contain the others?). So you'd need rules about group name exclusivity .. and all in all I think I've talked myself out of the idea ;) drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
I tend to agree with Brian's assessment. Categories/tags are the best way to do named groups of things, and that works across microformats as well (in case you wanted to group Brighton people and Brighton events and reviews of Brighton related things). I would recommend using Tags to be even more specific than just the plain string, as Brian suggests as an alternative. div class=vcard span class=fnJeremy Keith/span in a class=category rel=tag href=http://en.wikipedia.org/wiki/Brighton;Brighton/a /div Not that it is ambiguous at all in this case, but in general using rel-tag tags/categories provides a much better specificity, and provides a nice UI hook for what did the author *mean* by Brighton? (Imagine distinguishing Paris, France vs. Paris, Texas for example). And in this case, it wouldn't hurt to mark it up as the locality as well. div class=vcard span class=fnJeremy Keith/span in span class=adr a class=category locality rel=tag href=http://en.wikipedia.org/wiki/Brighton;Brighton/a /span /div This definitely sounds like a good candidate for hcard-authoring in a how to collect hCards into groups or sets section. Tantek On 6/23/06 7:41 AM, brian suda [EMAIL PROTECTED] wrote: At first look i really like this idea, but then i though about it for a minute You are adding 'brighton' into the class attribute, which violates the human readable aspect of Microformats. This would be better... div class=vcard span class=fnJeremy Keith/span in span class=groupBrighton/span /div in hCard there already is a property for grouping, class=category so you could use div class=vcard span class=fnJeremy Keith/span in span class=categoryBrighton/span /div or even a class=category rel=tag href=http://en.wikipedia.org/wiki/Brighton;Brighton/a Then you could begin to make a distributed web-sized group. It is slightly more difficult for a parser to find a class=category, then look up the tree and see if it is a child of class=vcard rather than putting them both on the root-element. The other downside to adding semantics outside of the scope of hCard, is that it is impossible to determine if it is a CSS style or a semantic attribute. div class=vcard brighton call-out-box.../div is call-out-box also a group or a style? I would recommend looking into using the category property for groups. -brian Drew McLellan wrote: I'm slightly wary of any pattern that prescribes doing anything outside the root element of a given µF. context. One proposal would be to introduce a very simple pattern for groups of hCards - just like groups in address book programs (friends, family, collegues etc). In XHTML we already have a mechanism of grouping elements - the class attribute. So how about treating hCards that share a common class name other than 'vcard' as a loose group? div class=vcard brighton div class=fnJeremy Keith/div /div div class=vcard brighton div class=fnAndy Budd/div /div div class=vcard div class=fnDrew McLellan/div /div Granted, there's danger of the concept duplicating problems already solved by either XFN, or by intrinsic groupings already created by the values within the hCards themselves. Most groupings I imagine are based on location, companies, or XFN properties like friends, collegues, family. I think we'd also need to see more real-world examples to demonstrate a need for something like this. I guess two examples would be your d.Construct Locations page, where groups are travel, accomadation, freewifi, etc, and the LPG site I did the other week where all my hCards were gas stations, and would be sensible to group as such. It gets more complex with the d.Construct case, though, where you'd actually want to group everything overall into one 'dconstruct' group too. e.g. div class=vcard travel dconstruct div class=fn orgBrighton Train Station/div /div The above would belong to the travel group and the dconstruct group. I'm not sure how a parser would know how those should be nested, however. (Does each of travel, accomodation, freewifi contain a dconstruct group, or does the dconstruct group contain the others?). So you'd need rules about group name exclusivity .. and all in all I think I've talked myself out of the idea ;) drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
Tantek wrote: Not that it is ambiguous at all in this case, but in general using rel-tag tags/categories provides a much better specificity, and provides a nice UI hook for what did the author *mean* by Brighton? (Imagine distinguishing Paris, France vs. Paris, Texas for example). And in this case, it wouldn't hurt to mark it up as the locality as well. div class=vcard span class=fnJeremy Keith/span in span class=adr a class=category locality rel=tag href=http://en.wikipedia.org/wiki/Brighton;Brighton/a /span /div That looks a good solution. Leaving aside the reltag, the category solution could still be used with a unique identifier for the document: div class=vcard span class=fnJeremy Keith/span in span class=adr a class=category locality href=#brightonBrighton/a /span /div Here, the category is pointing to a part of the current document that has been uniquely identified with id = brighton. This wouldn't be a good candidate for a reltag (it would create a circular reference), but it would solve the problem of grouping together many hcards into different groups on a single document... thereby paving the way for parsers to extract just the hcards for people in a particular category. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
I've been suggesting this for awhile. There are numerous benefits, besides addressing. For one thing, I'd like to see an AJAX library that pulls out one or more discontinuous DIVs from a remote webpage into the local page -- doing something like an iframe does, but using the remote page essentially as a database. This also is useful for the notion of including remote data by reference (http://microformats.org/wiki/include-pattern). Chris On 6/22/06, Tantek Çelik [EMAIL PROTECTED] wrote: In my experience with both searching for microformats and revealing them and linking to them, I have found an interesting pattern that I would like to share with folks. The microformat chunks (e.g. hCards, hCalendar events, hReviews etc.) that have an id attribute are much easier to automatically reference (and thus link to and browser/scroll to from search results) than those without. I've done this with my hCard on my home page: http://tantek.com/ E.g. span class=vcard id=myhcard a class=url fn href=http://andy.example.com;Andy Smith/a /span When you mark up people/companies as hCards or hCalendar events or hReviews, along with other things on a single page, try using an id attribute on the root element (the element with class=vcard etc.) and report back how ti works with you. If this works for folks, I'll add it to hcard-authoring as a recommended good practice. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Agent Provocateur, Citizen Agency Open Source Ambassador-at-Large Work / citizenagency.com Blog / factoryjoe.com/blog Cell / 412 225-1051 Skype / factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
On Jun 22, 2006, at 1:54 PM, Tantek Çelik wrote: The microformat chunks (e.g. hCards, hCalendar events, hReviews etc.) that have an id attribute are much easier to automatically reference (and thus link to and browser/scroll to from search results) than those without. In the past, I've added ID attributes to pages with multiple hCards thinking this would be useful for taking actions on specific contacts, but then discovered that most tools didn't recognize fragment URLs. Last I checked, I believe X2V wasn't recognizing fragment URLs, so it wasn't possible to export a single vcard from a document containing multiple hCards. To work around this, I made a proxy service to strip documents down to single fragments: http://makedatamakesense.com/fraggle/ For example, Tantek has 26 hCards on his home page, but you can pull out just his own by running the page through this proxy: http://makedatamakesense.com/fraggle/?url=http%3A%2F%2Ftantek.com%2F% 23hcard And then I went back and looked at X2V again, and now it seems to be recognizing fragment URLs. Technorati's vcard export still ignored the fragment in URLs, so I thought this might still be useful there. But it seems to be doing some odd conversion of URLs that makes this impossible. This: http://feeds.technorati.com/contacts/http://makedatamakesense.com/ fraggle/?url=http%3A%2F%2Ftantek.com%2F%23hcard Becomes this: http://feeds.technorati.com/contacts/http://tantek.com/#hcard And it converts all 26 hCards. So it looks like I wasted a little time on that proxy. But if there is some service out there that doesn't recognize fragment URLs, and anyone wants to take advantage of ID attributes on microformats, you can use it. On a side note: as I was going through the hCard examples looking for pages with multiple hCards to see if any of them had ID attributes already, I noticed a lot of pages in that list don't actually have hCards at all. For example, I remember Neil Dunn once had a nicely styled hCard on this page, but now it's gone: http://www.ndunn.com/2005/10/7/hCard So what's the protocol here? Should such links be removed from the wiki? Moved to a formerly had hCards section? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
On 6/22/06 5:44 PM, Scott Reynen [EMAIL PROTECTED] wrote: On Jun 22, 2006, at 1:54 PM, Tantek Çelik wrote: The microformat chunks (e.g. hCards, hCalendar events, hReviews etc.) that have an id attribute are much easier to automatically reference (and thus link to and browser/scroll to from search results) than those without. In the past, I've added ID attributes to pages with multiple hCards thinking this would be useful for taking actions on specific contacts, but then discovered that most tools didn't recognize fragment URLs. Last I checked, I believe X2V wasn't recognizing fragment URLs It's been recognizing them for a while. The key is, in order for X2V to process it, you must escape the # as %23. For example, Tantek has 26 hCards on his home page, but you can pull out just his own by running the page through this proxy: http://makedatamakesense.com/fraggle/?url=http%3A%2F%2Ftantek.com%2F% 23hcard No need. The get vCard link at the bottom my home page already does this using the support in the X2V code which the Technorati Contacts Feed Service is using. And then I went back and looked at X2V again, and now it seems to be recognizing fragment URLs. Technorati's vcard export still ignored the fragment in URLs, That is incorrect. Just go try clicking on the aforementioned link and you'll get a single vCard in the resultant .vcf. On a side note: as I was going through the hCard examples looking for pages with multiple hCards to see if any of them had ID attributes already, I noticed a lot of pages in that list don't actually have hCards at all. For example, I remember Neil Dunn once had a nicely styled hCard on this page, but now it's gone: http://www.ndunn.com/2005/10/7/hCard So what's the protocol here? Should such links be removed from the wiki? Moved to a formerly had hCards section? No established protocol. Certainly lack of an hCard would be a problem so at a minimum, it would be deserving of a move to the Examples with some problems section. http://microformats.org/wiki/hcard#Examples_with_some_problems Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
