Re: [whatwg] New approach to activities/intents

[Nils Dagsson Moskopp]

Roger Hågensen  writes:

> On 2014-11-10 10:35, Anne van Kesteren wrote:
>> On Fri, Nov 7, 2014 at 7:38 PM, Roger Hågensen  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  tag or a 
>  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 
> :
> http://example.com/test3"; rel="bookmark" title="Test 3">
> http://example.com/test4"; rel="bookmark" title="Test 4">
>
> And the following in ;
> http://example.com/test!"; rel="bookmark" title="Test 1">Click 
> Here1
> http://example.com/test2"; rel="bookmark" title="Test 2">Click 
> Here2
> http://example.com/test0"; title="Test 0">Click Here0
>
> 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

Re: [whatwg] New approach to activities/intents

[Nils Dagsson Moskopp]

Roger Hågensen  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

Re: [whatwg] New approach to activities/intents

[Nils Dagsson Moskopp]

Anne van Kesteren  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.  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

Re: [whatwg] New approach to activities/intents

[Roger Hågensen]

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

[Roger Hågensen]

On 2014-11-13 18:11, Nils Dagsson Moskopp wrote:

Roger Hågensen  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:


The section on the bookmark link type in W3C HTML can be found here:




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

[Nils Dagsson Moskopp]

Roger Hågensen  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

Re: [whatwg] New approach to activities/intents

[Nils Dagsson Moskopp]

Roger Hågensen  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:


The section on the bookmark link type in W3C HTML can be found here:


-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] New approach to activities/intents

[Jonas Sicking]

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 .

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  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  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.  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]

On 2014-11-11 23:31, Markus Lanthaler wrote:

On 7 Nov 2014 at 20:01, Nils Dagsson Moskopp wrote:

Roger Hågensen  writes:


A link element in the header, maybe call it http://example.com/article/12345/"; />
or  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

[Markus Lanthaler]

On 7 Nov 2014 at 20:01, Nils Dagsson Moskopp wrote:
> Roger Hågensen  writes:
> 
>> A link element in the header, maybe call it > href="http://example.com/article/12345/"; />
>> or  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

[Roger Hågensen]

On 2014-11-10 10:35, Anne van Kesteren wrote:

On Fri, Nov 7, 2014 at 7:38 PM, Roger Hågensen  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  tag or a 
 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 
:

http://example.com/test3"; rel="bookmark" title="Test 3">
http://example.com/test4"; rel="bookmark" title="Test 4">

And the following in ;
http://example.com/test!"; rel="bookmark" title="Test 1">Click 
Here1
http://example.com/test2"; rel="bookmark" title="Test 2">Click 
Here2

http://example.com/test0"; title="Test 0">Click Here0

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

[Anne van Kesteren]

On Fri, Nov 7, 2014 at 7:38 PM, Roger Hågensen  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

[Roger Hågensen]

On 2014-11-07 20:01, Nils Dagsson Moskopp wrote:

Roger Hågensen  writes:


A link element in the header, maybe call it http://example.com/article/12345/"; />
or  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

[Nils Dagsson Moskopp]

Roger Hågensen  writes:

> A link element in the header, maybe call it  href="http://example.com/article/12345/"; />
> or  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

Re: [whatwg] New approach to activities/intents

[Roger Hågensen]

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 href="http://example.com/article/12345/"; />
or  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/