Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: On 2014-11-10 10:35, Anne van Kesteren wrote: On Fri, Nov 7, 2014 at 7:38 PM, Roger Hågensen resca...@emsai.net wrote: A worthy goal would be to help developers de-clutter websites from all those share icons we see today, so if this could be steered towards that it would be great. That is what the proposal is doing. The share button would be part of the browser UI. Perhaps you misunderstood it? (However, it is unclear whether all domains are interested in such a migration.) I must have miss-understood, I saw window.close() mentioned and I thought this was a javascript API suggestion for yet another way to sharing things. I looked a bit close now and wonder if this is related in any way to https://wiki.mozilla.org/Mobile/Archive/Sharing ? Do you plan to go for a OpenShare route (modeled after OpenSearch) or something simpler like I mentioned earlier? If all a web author need to do is slap a rel=share on a a tag or a link tag in the head and then have it automatically appear/listed in a browser Share UI for that page then that would be ideal in my oppinion. For the record: Every browser has a “Share UI” already. It is called the address bar. You do not need to do anything to opt into it besides using URLs. Granted, lots of hipster developers bend around backwards to avoid using URLs, but to me it seems you already have a usable mechanism. May I ask if the “share” idea is conflating mechanism and policy? Something like a OpenShare could build further on this hopefully, but for wide adoption the simpler the better. Also OpenSearch is for searching an entire site or parts of it, wile a OpenShare would be just for one page or link so that would be overkill and it would cause another HTTP request to occur which is a waste IMO. I'm also curious if any browsers actually do something if multiple rel=bookmark exist in a page (head and body), are they taken into account in the Bookmark UI at all? I certainly can not recall eve seeing this happen. A quick test in Chrome, Firefox, Opera, IE here with the following in head: link href=http://example.com/test3; rel=bookmark title=Test 3 link href=http://example.com/test4; rel=bookmark title=Test 4 And the following in body; a href=http://example.com/test!; rel=bookmark title=Test 1Click Here1/a a href=http://example.com/test2; rel=bookmark title=Test 2Click Here2/a a href=http://example.com/test0; title=Test 0Click Here0/a The result is the same, if I use the Browser UI bookmark then the head links are ignored, and if I right link the body a link then I'm not given a bookmark choice at all, just copy the url or save it. If bookmark is so ignored perhaps it would be best to take bookmark (and to some extent canonical) and roll that into a rel=share standard which is defined/tied to this activities/intent proposal? Note! Firefox allows right clicking any URL and choosing to Bookmark it, and IE does the same but it called Favorites there instead, in either case I assume that rel=bookmark is ignored and the title is also ignored as the test0 link which does not specify rel bookmark is treated identically to them. Opera and Chrome does not seem to allow right clicking a URL and bookmark it. As I do not have Safari I have no idea what it does in these cases. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/ -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
Anne van Kesteren ann...@annevk.nl writes: A couple of us at Mozilla have been trying to figure out how to revive activities/intents for the web. Both work relatively well in closed environments such as Firefox OS and Android, but seem harder to deploy in a generic way on the web. What we've been looking at instead is solving a smaller use case. A Sharing API to start and then hopefully reuse the building blocks for other features that need to be liberated. https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very minimal Sharing API could look like. Our thinking is that something like the overlay browsing context could be reused to make e.g. input type=file or save as extensible going forward. However, admittedly it still doesn't really click. It feels a bit too much like e.g. the various search extensions browsers offer. Too much work for little return. Furthermore, freeing the web somehow from closely knitted silos seems like a worthwhile goal, but is often counter to what those silos are interested in. So it might be that we're still not quite there yet, thoughts appreciated. I would actually love it if I got something more like the search extensions, as they do work unobtrusively and without scripting. I also find creating OpenSearch XML easier than scripting stuff. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: On 2014-11-13 18:19, Nils Dagsson Moskopp wrote: AFAIK, all of these interface details lie outside the scope of the HTML specification (and rightly so, IMHO). If you need a standard symbol for bookmarks I suggest to use U+1F516 BOOKMARK, which looks like this „“. Then don't spec it but advise or suggest it. Even the bookmark example at https://html.spec.whatwg.org/multipage/semantics.html#link-type-bookmark says A user agent could determine which permalink applies to which part of the spec thereby acting as a advisory hint/best practice suggestion (note the use of could). I also tested the example code (with doctype html obviously) and the browser behaviouir is still the same, rel=bookmark is simply ignored. In that case shouldn't rel=bookmark be removed from the WHATWG HTML spec to reflect actual use? As long as it is produced and there do exist consumers? Probably not – many browsers also do ignore rel=alternative, the cite attributes on quotations, the datetime attribute on ins and del elements and so on. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
Hi Anne, Great to see that this is being worked on! And it's great to see that it enables integration with built-in share functionality provided by the UA. I also *really* like the idea of integrating with save as and input type=file. However there's a couple of use cases that seems good to address. First off, I think we also need to enable websites to render a share button inside the page. This is sometimes useful simply in order to share a canonical URL for a piece of content, rather than the URL that the user is currently looking at. For example in a feed page which contains multiple articles it'd be good to enable sharing a specific article. Second, it would be good to enable sharing more than just URLs. While URLs are definitely a very common use case, being able to directly share for example an image. For example to share an image with an email application in order to add the image itself as an attachment. This is also needed for the save as and input type=file use cases. Another example of this is sharing a piece of text. I've seen websites which allow selecting a piece of text and then click a twitter button in order to tweet the selected text. Though I'm not sure how common this is. In order to support this we need not just a way to register handlers, but also a more powerful API for those handlers to receive the shared content. This is needed in order to enable the handler to receive a blob. A last use case which I think at this point is a bit more theoretical is the ability to search the web for websites that can handle sharing. This in order to enable UAs to build UI which allows the user to not just choose from websites that the user has accepted registration from, but also to search the web for other websites to share through. This might be less useful for the simple case of sharing a generic URL since there would be lots and lots of websites that could handle that, and very little data to enable the UA to find the most relevant ones. But if we expand this API to cover more than sharing (which I hope we eventually will), or if we enable registering for handling sharing of particular types (images vs. music vs. pdf vs. spreadsheets) then this might be a more interesting use case. / Jonas On Mon, Nov 3, 2014 at 8:42 AM, Anne van Kesteren ann...@annevk.nl wrote: A couple of us at Mozilla have been trying to figure out how to revive activities/intents for the web. Both work relatively well in closed environments such as Firefox OS and Android, but seem harder to deploy in a generic way on the web. What we've been looking at instead is solving a smaller use case. A Sharing API to start and then hopefully reuse the building blocks for other features that need to be liberated. https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very minimal Sharing API could look like. Our thinking is that something like the overlay browsing context could be reused to make e.g. input type=file or save as extensible going forward. However, admittedly it still doesn't really click. It feels a bit too much like e.g. the various search extensions browsers offer. Too much work for little return. Furthermore, freeing the web somehow from closely knitted silos seems like a worthwhile goal, but is often counter to what those silos are interested in. So it might be that we're still not quite there yet, thoughts appreciated. (I put WebApps and TAG on bcc, hope that's okay.) -- https://annevankesteren.nl/
Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: I just checked WHATWG HTML5 and rel=bookmark isn't there at all (I didn't check W3C HTML5 though). The section on the bookmark link type in WHATWG HTML can be found here: https://html.spec.whatwg.org/multipage/semantics.html#link-type-bookmark The section on the bookmark link type in W3C HTML can be found here: http://www.w3.org/TR/html5/links.html#link-type-bookmark -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: Which brings another issue, how far is too far? Should the naming be standardized as well? Right click a URL on a page and what do you see? Chrome shows Copy link adress Firefox shows Bookmark This Link and Copy Link Location IE shows Add to favorites... Copy shortcut Opera Copy link address Right click a page and what do you see? Chrome shows nothing Firefox shows nothing IE shows Add to favorites... Create shortcut Opera Add to Speed Dial Add to bookmarks Copy address Right click a address field and what do you see? Chrome shows Copy Firefox shows Copy IE shows Copy Opera Copy Very confusing and inconsistent. I'd like to see the following: Right click a URL on a page and see Copy Link Bookmark/Share Link... Right click a page and see Copy Link Bookmark/Share Link... Right click a address field and see Copy Link Bookmark/Share Link... For touch screens/devices holding the finger for x amount of time would equal a right click. Copy Link will simply copy to the clip board. Drag and Drop behaves the same as Copy Link. Bookmark/Share Link... will present a Share API. Opera has a neat thing when you bookmark a page, you are given a option of either a normal bookmark or a Speed Dial bookmark (tiny icon), and it also lets you choose the look of your bookmark (site logo, page thumbnail or text), by the looks of it very easy to add other forms of bookmarks or sharing to that UI (Facebook an Twitter etc.) To me there is no difference between a bookmark of a link or sharing a link, a bookmark is simply you sharing with yourself. I also wonder if a standardized icon/symbol should exist for a Bookmark/Share button on the surrounding UI of a browser. Opera has a heart symbol, Firefox has a star and clipboard/list thingy, IE has a star, and Chrome has a star. A star has been used for Favorite/Bookmark for quite a while. So what about Bookmark/Share ? Does a book with a star make sense or is that too cluttered? Or is Opera on trend with their heart? AFAIK, all of these interface details lie outside the scope of the HTML specification (and rightly so, IMHO). If you need a standard symbol for bookmarks I suggest to use U+1F516 BOOKMARK, which looks like this „“. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New approach to activities/intents
On 2014-11-13 18:11, Nils Dagsson Moskopp wrote: Roger Hågensen resca...@emsai.net writes: I just checked WHATWG HTML5 and rel=bookmark isn't there at all (I didn't check W3C HTML5 though). The section on the bookmark link type in WHATWG HTML can be found here: https://html.spec.whatwg.org/multipage/semantics.html#link-type-bookmark The section on the bookmark link type in W3C HTML can be found here: http://www.w3.org/TR/html5/links.html#link-type-bookmark I have no explanation for the missing it's entry in the WHATWG spec, I could have sworn I did search for bookmark. As to the W3C, I suspect I searched the wrong document (wouldn't be the first time I've done that). -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] New approach to activities/intents
On 2014-11-13 18:19, Nils Dagsson Moskopp wrote: AFAIK, all of these interface details lie outside the scope of the HTML specification (and rightly so, IMHO). If you need a standard symbol for bookmarks I suggest to use U+1F516 BOOKMARK, which looks like this „“. Then don't spec it but advise or suggest it. Even the bookmark example at https://html.spec.whatwg.org/multipage/semantics.html#link-type-bookmark says A user agent could determine which permalink applies to which part of the spec thereby acting as a advisory hint/best practice suggestion (note the use of could). I also tested the example code (with doctype html obviously) and the browser behaviouir is still the same, rel=bookmark is simply ignored. In that case shouldn't rel=bookmark be removed from the WHATWG HTML spec to reflect actual use? -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] New approach to activities/intents
On 2014-11-11 23:31, Markus Lanthaler wrote: On 7 Nov 2014 at 20:01, Nils Dagsson Moskopp wrote: Roger Hågensen resca...@emsai.net writes: A link element in the header, maybe call it link rel=share href=http://example.com/article/12345/; / or link rel=share / if the current url (or the canonical url link if present) should be used, although I guess in a way rel=share will probably replace the need to use rel=canonical in the long run. I do not understand. Why should one invent a rel value (“share”) that conveys the same semantics as an already existing one (“canonical”) ? I also have to admit that I struggle to see what value adding a rel=share link to a page adds!? If you look at how people share links (they copy and paste what's shown in the browser's address bar) then I wonder why anything at all is needed on the page to be shared... The story is obviously different for Share Web APIs or share endpoints as they are called in https://wiki.whatwg.org/wiki/Sharing/API (Facebook, Reddit, bitly etc.). Then a rel=share could be used to provide hints for those (in the form of a OpenShare standard similar to OpenSearch?). But good point nonetheless, rel=bookmark is very underused as well, probably because it's original intent was superseded by people bookmarking http://example.com/somepage#section I just checked WHATWG HTML5 and rel=bookmark isn't there at all (I didn't check W3C HTML5 though). The most interesting question however is why (desktop) browsers haven't added a share button till now.. Wish I knew. As I mentioned in another post just bookmarking a url is not fully supported still. (right click a URL in Opera and Chrome, I see no Bookmark option there, Firefox and IE does however). Anyway, my point was (probably muddled by me) that a Sharing API may just encompass the whole sharing path, which as you said above starts with people copying/dragging/right clicking a address bar or URL. Once that URL is captured (and any possible hints) then it's passed to the Share API, and I feel it is important that the initial user step is also covered. (as that is not documented at all currently right?) Which brings another issue, how far is too far? Should the naming be standardized as well? Right click a URL on a page and what do you see? Chrome shows Copy link adress Firefox shows Bookmark This Link and Copy Link Location IE shows Add to favorites... Copy shortcut Opera Copy link address Right click a page and what do you see? Chrome shows nothing Firefox shows nothing IE shows Add to favorites... Create shortcut Opera Add to Speed Dial Add to bookmarks Copy address Right click a address field and what do you see? Chrome shows Copy Firefox shows Copy IE shows Copy Opera Copy Very confusing and inconsistent. I'd like to see the following: Right click a URL on a page and see Copy Link Bookmark/Share Link... Right click a page and see Copy Link Bookmark/Share Link... Right click a address field and see Copy Link Bookmark/Share Link... For touch screens/devices holding the finger for x amount of time would equal a right click. Copy Link will simply copy to the clip board. Drag and Drop behaves the same as Copy Link. Bookmark/Share Link... will present a Share API. Opera has a neat thing when you bookmark a page, you are given a option of either a normal bookmark or a Speed Dial bookmark (tiny icon), and it also lets you choose the look of your bookmark (site logo, page thumbnail or text), by the looks of it very easy to add other forms of bookmarks or sharing to that UI (Facebook an Twitter etc.) To me there is no difference between a bookmark of a link or sharing a link, a bookmark is simply you sharing with yourself. I also wonder if a standardized icon/symbol should exist for a Bookmark/Share button on the surrounding UI of a browser. Opera has a heart symbol, Firefox has a star and clipboard/list thingy, IE has a star, and Chrome has a star. A star has been used for Favorite/Bookmark for quite a while. So what about Bookmark/Share ? Does a book with a star make sense or is that too cluttered? Or is Opera on trend with their heart? -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] New approach to activities/intents
On 2014-11-10 10:35, Anne van Kesteren wrote: On Fri, Nov 7, 2014 at 7:38 PM, Roger Hågensen resca...@emsai.net wrote: A worthy goal would be to help developers de-clutter websites from all those share icons we see today, so if this could be steered towards that it would be great. That is what the proposal is doing. The share button would be part of the browser UI. Perhaps you misunderstood it? (However, it is unclear whether all domains are interested in such a migration.) I must have miss-understood, I saw window.close() mentioned and I thought this was a javascript API suggestion for yet another way to sharing things. I looked a bit close now and wonder if this is related in any way to https://wiki.mozilla.org/Mobile/Archive/Sharing ? Do you plan to go for a OpenShare route (modeled after OpenSearch) or something simpler like I mentioned earlier? If all a web author need to do is slap a rel=share on a a tag or a link tag in the head and then have it automatically appear/listed in a browser Share UI for that page then that would be ideal in my oppinion. Something like a OpenShare could build further on this hopefully, but for wide adoption the simpler the better. Also OpenSearch is for searching an entire site or parts of it, wile a OpenShare would be just for one page or link so that would be overkill and it would cause another HTTP request to occur which is a waste IMO. I'm also curious if any browsers actually do something if multiple rel=bookmark exist in a page (head and body), are they taken into account in the Bookmark UI at all? I certainly can not recall eve seeing this happen. A quick test in Chrome, Firefox, Opera, IE here with the following in head: link href=http://example.com/test3; rel=bookmark title=Test 3 link href=http://example.com/test4; rel=bookmark title=Test 4 And the following in body; a href=http://example.com/test!; rel=bookmark title=Test 1Click Here1/a a href=http://example.com/test2; rel=bookmark title=Test 2Click Here2/a a href=http://example.com/test0; title=Test 0Click Here0/a The result is the same, if I use the Browser UI bookmark then the head links are ignored, and if I right link the body a link then I'm not given a bookmark choice at all, just copy the url or save it. If bookmark is so ignored perhaps it would be best to take bookmark (and to some extent canonical) and roll that into a rel=share standard which is defined/tied to this activities/intent proposal? Note! Firefox allows right clicking any URL and choosing to Bookmark it, and IE does the same but it called Favorites there instead, in either case I assume that rel=bookmark is ignored and the title is also ignored as the test0 link which does not specify rel bookmark is treated identically to them. Opera and Chrome does not seem to allow right clicking a URL and bookmark it. As I do not have Safari I have no idea what it does in these cases. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] New approach to activities/intents
On 7 Nov 2014 at 20:01, Nils Dagsson Moskopp wrote: Roger Hågensen resca...@emsai.net writes: A link element in the header, maybe call it link rel=share href=http://example.com/article/12345/; / or link rel=share / if the current url (or the canonical url link if present) should be used, although I guess in a way rel=share will probably replace the need to use rel=canonical in the long run. I do not understand. Why should one invent a rel value (“share”) that conveys the same semantics as an already existing one (“canonical”) ? I also have to admit that I struggle to see what value adding a rel=share link to a page adds!? If you look at how people share links (they copy and paste what's shown in the browser's address bar) then I wonder why anything at all is needed on the page to be shared... The story is obviously different for Share Web APIs or share endpoints as they are called in https://wiki.whatwg.org/wiki/Sharing/API (Facebook, Reddit, bitly etc.). The most interesting question however is why (desktop) browsers haven't added a share button till now.. -- Markus Lanthaler @markuslanthaler
Re: [whatwg] New approach to activities/intents
On Fri, Nov 7, 2014 at 7:38 PM, Roger Hågensen resca...@emsai.net wrote: A worthy goal would be to help developers de-clutter websites from all those share icons we see today, so if this could be steered towards that it would be great. That is what the proposal is doing. The share button would be part of the browser UI. Perhaps you misunderstood it? (However, it is unclear whether all domains are interested in such a migration.) -- https://annevankesteren.nl/
Re: [whatwg] New approach to activities/intents
On 2014-11-07 20:01, Nils Dagsson Moskopp wrote: Roger Hågensen resca...@emsai.net writes: A link element in the header, maybe call it link rel=share href=http://example.com/article/12345/; / or link rel=share / if the current url (or the canonical url link if present) should be used, although I guess in a way rel=share will probably replace the need to use rel=canonical in the long run. I do not understand. Why should one invent a rel value (“share”) that conveys the same semantics as an already existing one (“canonical”) ? Three reasonings: 1. HTTP (301) redirects are advised over rel=canonical, Matt Cutts at Google has posted about that in the past as far as I recall. And it makes sense as the bots don't need to parse the page to get the canonical url. 2. Bookmarking should be of the current page the user has displayed, if they bookmark the page and a different url is bookmarked I'd consider that undesired behaviour (in the eyes of the user) unless a UI informs them or gives them an option. 3. rel=share has already has been invented though I'd hardly call 5 letters an invention. rel=share also shows clear intent. A bookmark may be user specific or private to that user. A canonical (or HTTP 301) indicate to the browser or bot that the page is over there and not here. A share is intended to to be, well shared. It semantically makes sense, at least to me. rel=bookmark and rel=canonical and a rel=share are all hints. A search engine for exasmple if it sees a rel=share link that is different from say the canonical url (either via HTTP 301 or current page or rel=)canonical) should probably ignore it as such a share link may have a share tracking url with a reference ID in it. Also, rel=share is in the wild, I had a url to a list of rel= occurrences on the web but ironically I did not bookmark i/note it down. While it was low on the list, it was there. Anyway, this is one place where the rel=share idea is mentioned. https://wiki.mozilla.org/Mobile/Archive/Sharing There is also a rel=share-information floating around out there, but the search engines aren't making it easy for me to search this stuff (I'm probably using the wrong syntax/markup). But I found it referenced here https://code.google.com/p/huddle-apis/wiki/AuditTrail There is a rel=share example use on page 5 of https://tools.ietf.org/id/draft-jones-appsawg-webfinger-00.txt Used exactly as how I described it. Here is a example of rel=share-link being used https://github.com/engineyard/chat/blob/master/views/index.jade And rel=share is used in an example here https://code.google.com/p/huddle-apis/wiki/Folder#Response And stated specifically here https://code.google.com/p/huddle-apis/wiki/Folder#Sharing_a_folder As I see it there share is not the same as bookmark or canonical. There may be some overlap with rel=share and a normal link though (if rel=share is used outside the html head). -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] New approach to activities/intents
On 2014-11-03 17:42, Anne van Kesteren wrote: https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very minimal Sharing API could look like. I have often pondered the same when seeing a Share button or icon on a webpage. Some solutions have a single icon that pops up a menu, while other sites has a row of the most common social sites. In retrospect however I realize that any Share API would be no different than how people currently share or bookmark things. A worthy goal would be to help developers de-clutter websites from all those share icons we see today, so if this could be steered towards that it would be great. There are two ways to do this that I'd recommend. A link element in the header, maybe call it link rel=share href=http://example.com/article/12345/; / or link rel=share / if the current url (or the canonical url link if present) should be used, although I guess in a way rel=share will probably replace the need to use rel=canonical in the long run. Then browser devs can simply utilize that info in their own Share UI (which presumably is tied into the accounts set up on the device/machine in some way). A browser UI could provide a nice looking and device friendly way to add/edit/remove social services that have sharing capabilities (Google+, Facebook, Twitter, Skype, etc.) If the share link is missing this does not mean the page can not be shared, in that case it should be treated as a page is normally treated today, the share link is just a browser hint as to the ideal link to use when sharing this page. Also note that using the link element allows the possibility of using hreflang to present multiple share links (one international aka English and one in the language of the page), or use media to provide multiple share links for different types of devices. There already is a link rel=search so a rel=share just makes sense IMO. It certainly will get rid of the clutter of share icons and buttons on websites (over time), those can be a pain to click on using touch devices (without zooming first), a browser Share UI could easily be hidden on the edge and make se of swipe left from edge or swipe right from edge (or top/bottom etc.) or use gestures to open a Share UI. Some of those share icons may fail to list the social network the user prefer (like email for example) but if that is all setup in the browser then the user can share it at one (or multiple) social services just the way they like it. Also note that title can be applied to such a share link as well, thus providing a suggested title the browser can choose (or not) to use when sharing it. Any icons/logo is either taken from the icon/logo of the current page or from the href linked page (and whatever icon/logo that may have). Existing services like AddThis or ShareThis (two of the more popular ones I believe?) should be able to access the link rel=share params via javascript (to access hreflang and media and title) so they will still remain competitive solutions; I aløso believe there are browser plugins for these two services as well and the browser can/could provide the rel=share link to those types of plugins. Also note that there can be multiple link rel=share and that if allowed when speced that rel=share could be allowed to be global, that way the links to be shared could be inline in the document thus part of the content and useable by the user which is always ideal. Anyway, I'll shut up now before I veer way off topic here. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: A link element in the header, maybe call it link rel=share href=http://example.com/article/12345/; / or link rel=share / if the current url (or the canonical url link if present) should be used, although I guess in a way rel=share will probably replace the need to use rel=canonical in the long run. I do not understand. Why should one invent a rel value (“share”) that conveys the same semantics as an already existing one (“canonical”) ? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
