W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2014

Re: [whatwg] New approach to activities/intents

From: Roger Hågensen <rescator@emsai.net>
Date: Fri, 07 Nov 2014 19:38:42 +0100
Message-ID: <545D11B2.1010005@emsai.net>
To: whatwg@lists.whatwg.org
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 
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 
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/
Received on Friday, 7 November 2014 18:39:14 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:26 UTC