Let's say that you've visited a website and want to share it with your friends. At the bottom of the article is a list of popular sharing destinations - Facebook, BlueSky, LinkedIn, Telegram, Reddit, HackerNews etc.
You click the relevant icon and get taken to the site with the sharing details pre-filled.
The problem is, every different site has a different intent for sharing links and text. For example:
-
https://www.facebook.com/sharer.php?u=…&t=… -
https://www.linkedin.com/sharing/share-offsite/?url=… -
https://bsky.app/intent/compose?text=… -
https://www.threads.net/intent/post?url=…&text=… -
https://www.reddit.com/submit?url=…&title=…
As you can see, some only allow a URL, some text and a URL, and some just a plain text which could contain the URl. A bit of a mess! It's probably impossible to get every site to agree on a standard for their sharing intent. But there could be a standard for exposing their existing sharing mechanism.
That's the proposal from Ben Werdmuller with "Share Openly".
ShareOpenly knows about most major social networks, as well as decentralized platforms like Mastodon, Bluesky, and Known.
However, if ShareOpenly is having trouble sharing to your platform, and if your platform supports a share intent, you can add the following metatag to your page headers:
<link rel="share-url" href="https://your-site/share/intent?text={text}">Where
https://your-site/share/intent?text=is the URL of your share intent.The special keyword
{text}will be replaced with the URL and share text.
I think that's a pretty nifty solution.
For sites which take a URl and an (optional) title, the meta element looks like:
HTML
<link rel="share-url" href="https://www.facebook.com/sharer.php?u={url}&t={text}"> <link rel="share-url" href="https://lemmy.world/create_post?url={url}&title={text}">
For those which only take URl, it looks like:
<link rel="share-url" href="https://www.linkedin.com/sharing/share-offsite/?url={url}">
It's slightly trickier for sites like Mastodon and BlueSky which only have a text sharing field and no separate URl. The current proposal is just to use the text. For example
<link rel="share-url" href="https://bsky.app/intent/compose?text={text}">
But it could be something like
<link rel="share-url" href="https://mastodon.social/share?text={text}%0A{url}">
What Next?
The HTML specification has this to say about adding new link types:
Extensions to the predefined set of link types may be registered on the microformats page for existing rel values.
Adding to that page merely requires a formal specification to be written up. After that, some light lobbying might be needed to get social networks to adopt it.
So, I have three questions for you:
- Do you think
<link rel="share-url"is a good idea for a new standard? - What changes, if any, would you make to the above proposal?
- Would you be interested in using it - either as a sharer or sharing destination?
Please leave a comment in the box - and remember to hit those sharing buttons!
13 thoughts on “What about using rel="share-url" to expose sharing intents?”
@Edent A few years ago I ran a (flawed) little poll with the intent to get a bit of an idea of whether people use share buttons. Might be of interest.
https://fedi.vale.rocks/notice/AbMVOUA2MBBDdbOLTs
| Reply to original comment on fedi.vale.rocks
Maybe rel=sharer? It's implicitly a URL (and in theory could be some other form of URI I guess).
| Reply to original comment on bsky.app
@Edent I am not sure I understand.
1. If I understand it correctly, this would need to be implemented by websites that "receive" the share data. Eg. Facebook or a Mastodon instance?
2. If 1. is true, then who would consume this link tag and act on it? Individual websites like yours? A service like shareopenly? The user agent, eg. the browser? When? How often?
3. If 1. is false and this is meant to be implemented on the share source (eg. your website), then what's the advantage over the links you have at the bottom of your post? Again, who is meant to consume the (hidden) link tags?
4. Finally, more philosophically, are share links actually used? I feel like people usually either share things manually (or via their Mobile OS share mechanism) or not at all. I don't remember ever using one of those links.
| Reply to original comment on fedi.splitbrain.org
@splitbrain
1. Yes.
2. Probably the user-agent, but other tools as well. The same as a share intent on a mobile.
3. It would enable more dynamic share buttons.
4. Yes. Look at the utm tracking links littering every social media service.
| Reply to original comment on mastodon.social
Nice idea but this:
"Extensions to the predefined set of link types may be registered on the microformats page for existing rel values."
is very, very, very foolish.
Who runs that page/ site? How are they accountable? How are disputes (for example over which extensions to include on or exclude from that page) managed?
Feels analogous to opensearch.xml which lets browsers support site-search: has a similar templating syntax
Is this for browsers or other websites to consume though?
Your browser could store "openshare.xml" of sites you visit, and then surface them natively, but that's a much bigger spec challenge
| Reply to original comment on bsky.app
If it's for other websites to crawl/index then what are they going to do with 10s/100s thousands of different share intents?
(think if suddenly every Discourse forum instance suddenly had an openshare.xml for creating a new thread)
| Reply to original comment on bsky.app
@dalias @Edent I see. So I need to actively add share targets. Probably in a similar way that I need to allow web notifications or install a site as a PWA.
Now it is already possible to register a PWA as a share target for mobile phones (using the share_target in the manifest). And there is also the JavaScript share API (https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share), so I feel like all that is missing is better support for the latter on Desktop?
Actually the share_target and the manifest.json is probably the better implementation than a new link element: https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Manifest/Reference/share_target
| Reply to original comment on fedi.splitbrain.org
@Edent semantically any link points to a url, so calling it 'share-url' would be similar if 'stylesheet' was 'stylesheet-url'.
| Reply to original comment on indieweb.social
What about using rel="share-url" to expose sharing intents? | Hacker News
| Reply to original comment on news.ycombinator.com
@Edent is this the right place to put the links? Couldn't this be a bookmarklet or browser extension? Couldn't be something that browsers just built in and allowed folks to customize? Where is the right place to solve this problem? Can we start there?
| Reply to original comment on mastodon.social
@mgifford I think I agree with you that this sounds more like a feature of the user agent than the website.
Adding and changing a share target is much easier there and with a bit of clever design it would work with any reachable page or resource, not just those web pages where the authors thought of adding share buttons
@Edent
| Reply to original comment on graz.social
Any such standard should expicitly state that Link: HTTP headers are an equivalent method for specifying such metadata. For some sites, adding a header is probably easier to implement. And when this doesn't get specified, sometimes we get partially-implemented standards.
The alternative would be a .well-known URL, e.g. .well-known/share, which contains the posting specification. But I think the approach you propose, with its placeholders, is preferable.
So yes: this seems good to me!
More comments on Mastodon.