Use that, and the browser/native platform integration is already there, and ShareOpenly becomes more of stopgap measure.
The only real problem is that you can’t feature-detect share_target support—so you can’t detect if the user is able to add a web app to the user agent’s share targets.
As for ShareOpenly using these things, see https://shareopenly.org/share/?url=https://example.com, and it requires the user to paste a value in once, and then by the looks of it it will remember that site via a cookie. Not great, but I guess it works. But I’m sceptical anyone will really use it.
OK well I think there's one superior aspect to the main post which is that it is short and not difficult to understand all of what will happen. This web-share-target requires more thinking about.
Also some stuff I dislike:
>The user agent MAY automatically register all web share targets as the user visits the site, but it is RECOMMENDED that more discretion is applied, to avoid overwhelming the user with the choice of a large number of targets.
Yeah, specs that leave it open to site discretion whether or not to be abusive have a great deal of success.
>This specification has no known accessibility considerations.
No really!?
Yeah a screenreader functions as a sequential medium, so what happens with registry of all share targets with screenreader, in fact what happens when screenreader comes to site, screenreader now will tell you that you have shares first? This is up to the browser how they tell the user that there are shares and ask for their input? So it will work differently between browsers?
I have found some bugs before in Google provided specs that were somewhat annoying for screenreader usage, and evidently the reasoning they must have had was that there were no known accessibility considerations because they sure didn't specify any.
> Yeah a screenreader functions as a sequential medium, so what happens with registry of all share targets with screenreader, in fact what happens when screenreader comes to site, screenreader now will tell you that you have shares first? This is up to the browser how they tell the user that there are shares and ask for their input? So it will work differently between browsers?
Both Android and iOS have sharing mechanisms that work just fine with screen readers. They show the most common/likey/favourited options first, with an option to expand to other apps/share targets. My phone has dozens of options, but I rarely need to scroll beyond the first line to find the share target I'm looking for.
The share dialog is an OS/browser control, not something the web page needs to render, so it's as accessible as the browser decides it should be. Many Linux distros lack such a control, but on Android/iOS/Windows/presumably macOS, this is a solved problem.
the problem for me at any rate, reading the spec, is trying to think out exactly how this will be affected by the ability of the site to add multiple share targets
as quoted
>The user agent MAY automatically register all web share targets as the user visits the site, but it is RECOMMENDED that more discretion is applied, to avoid overwhelming the user with the choice of a large number of targets.
The spec evidently feels it won't make any difference at all, but I'm not sure, and it's harder for me to reason about this than the simple rel share url thing.
> The only real problem is that you can’t feature-detect share_target support
I didn't know this existed, so the first thing I did is check the caniuse website, and yeah not even they have info about the Web Share Target API[1][2]. As of writing this comment, they only have info about the Web Share API[3].
Because as with many, many, many APIs that Chrome ships it's not a spec:
- there's a giant banner on the left saying "unofficial"
- The "Status of this document" section states the following:
--- start quote ---
This document is a draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.
--- end quote ---
But just because it was shipped in Chrome and has some napkin scribbles resembling an official spec, people will both claim it's a spec and expect everyone to implement it.
This document is a draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.
It’s been implemented in Chromium for 4–6 years, Firefox’s position is positive (admittedly that was 2019), WebKit’s is neutral, and there are bugs open in both Firefox and WebKit.
I regularly criticise Google-only specs and point out how they’re not standards in any way, but this one is not really like that—it’s just that the other two platforms are missing a couple of other pieces that are better to get in place first, and it’s not a high priority for them.
And certainly in the context of this rel="share-url" outsider proposal, nah, the share_target manifest reference is still way more “official” than that.
It makes it a non-official Chrome-only non-standard
> Firefox’s position is positive (admittedly that was 2019), WebKit’s is neutral,
Positions don't make a spec
> but this one is not really like that—it’s just that the other two platforms are missing a couple of other pieces
It literally means that in the very literal sense of the word literal:
The "Status of this document" section states the following:
--- start quote ---
This document is a draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.
--- end quote ---
Which part of that tells you that "it's not like that"? It's not even on a standards track. It's not even a Working Draft (the very first level of a spec when vendors agree on the idea, but haven't iterated on the API: https://www.w3.org/policies/process/#rec-track)
> the share_target manifest reference is still way more “official” than that.
Google presents these napkin scribbles in the w3c format precisely so that gullible people would wave them around as actual specs.
But unlike the proposal by the blog author, it's already been implemented by at least one browser vendor and received positive responses from another.
Sure, we could throw in another spec and maybe Mozilla will implement this one and maybe Safari won't be neutral to the new one, but why go through that effort when there's already a working solution to this problem?
Does anyone even use share buttons? I always just copy the link, and it seems that anyone I see sharing things does the same. It feels more like a way for the social media companies to advertise/track, and those sites have been sending less and less traffic for years, so I wonder why every site still has them.
They also track your friends and acquaintances through shares. Even if you don't give them access to contacts, and don't even use TikTok beyond scrolling through videos, they will start suggesting people who have seen your shares as your friends.
Yeah I don't know if I've ever used them. Maybe once or twice ever. For me the main problem is UX. Sharing from my platform (copy url on computer, share button on android) is always in the same place. But the share button built in is never in the same place across different websites, how could it be?
They do. I built a file sharing page for friends and most were confused how to share me a link to a file. I implemented the copy url button they asked for and no complaints, even though the url is always visible on every browser they use
Exposing the sharing intent is a problem, not a goal.
Sharing a link is easy. That's why URLs were invented. Exposing the sharing intent is only beneficial to companies that want to track you.
Sure, pressing "share on facebook" might be slightly lower friction than copy-pasting the link, but if the sharing isn't worth that friction, perhaps don't?
The article is proposing a technical solution to a business problem.
I have no doubt this proposal or any other similar proposal would work well in the 90s or early 2000s. Let's go one step further and let browsers work with all those third party website and figure all the details for sharing, and websites never embed anything.
But you see, that's not the problem. These share buttons are often trojans on websites. Facebook tracks you via those share buttons even if you have never had a Facebook account. And people come up with various solutions to tackle that -- adblockers just block network traffic, while a small amount of website owners create a separate switch which you can toggle and then share with Facebook. Isn't all of that stupid? I don't see why Facebook, Instagram will be eager to opt in to this solution and make the experience good.
Yeah, for those branded buttons on websites this isn't an alternative. They want all their JavaScript for collect information on the user, even if they don't press the button.
I believe this is to play with (mobile) browser's share button, while even there I don't get how this is supposed to work.
First: How does this figure out where I want to share to? And then: Would it have to load the shared-to page first, parse it to see if there is such a Tag and then interpret it?
exactly my thought, links work fine as they are, my biggest problem with them is 9 times of 10 I don't know where they lead. Fixing one "share" use case isn't solving a misuse
Does this mean that, when the user clicks a "share to social.network" button in random.com, the browser would first request the full html page of social.network (in the background) only to parse the rel="share-url" link? Seems a bad design.
Only tangentially related to the main subject, but the post ends with:
> Extensions to the predefined set of link types may be registered on the microformats page for existing rel values.
Please don't. WHATWG's tendency to self-anoint and all its idiosyncrasies notwithstanding, the IANA maintains the link relation registry[1]. Use the procedure prescribed in the RFCs.
Looking at ShareOpenly, I think this is basically a reaction to "Mastodon instances make social sharing complicated from the web". A "share to Mastodon" button is impossible, and a button for every Mastodon instance in existence is impractical. Thus a "fuck it, I guess just put in a URL and we'll work out how to send something to it" solution.
Speaking as someone who never ever uses a share button I think this is misguided, we should just remove that entire class of widget from the web, and people who want to share things can copy-paste the URL into their platforms of choice.
I think the sort of person who would paste/type the URL for another social service into the freeform "or some other service" input on ShareOpenly is exactly the sort of person who has that web literacy, though. Which I guess doesn't support my "delete them all!" desire, but rather sadly reinforces keeping the status quo.
So, it's a way to tell other applications how they would craft a URL on your site such that they can prefill a form on your site?
A meta tag in the html of your webpages seems like the wrong place for that info since it's not something that changes per page unlike the OpenGraph/TwitterCard meta tags that tell third-party apps how to generate a preview of the page.
Surely a better place would be example.com/.well-known/share-url.
One thing I really don't like about it is the implication that the url and the share-button could refer to different things. I feel like browser vendors probably care about knowing whether users use the share button or copy/paste the URL, but hypothetically they know already and I don't feel like most (any?) websites need that information -- it might correlate to a sophistication-level of the user and be used for targeting by scammers, and that could be bad.
For me, I use history.replaceState to change the url after I've got my campaign tracking to the share link, this way the browser's built-in share button does all the work for me. I can detect trivial-reload by checking the cookie I dropped when the page came in, so I don't mis-attribute shares. It is a shame I cannot do this so easily without JavaScript, but I'm sure I can actually buy non-JavaScript users from Google (and other ad platforms) so I'm not sure it's worth worrying about.
I was thinking A button can also be an alternative with all data sent as post, but apparently the button attributes don’t include any ability to specify form values. This has to be done via JS or via additional tags (which is still an option).
There’s already a better spec from 2016, which has even been shipping in the Chromium family since 2019 (Android) or 2021 (desktop):
https://w3c.github.io/web-share-target/
https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
Use that, and the browser/native platform integration is already there, and ShareOpenly becomes more of stopgap measure.
The only real problem is that you can’t feature-detect share_target support—so you can’t detect if the user is able to add a web app to the user agent’s share targets.
As for ShareOpenly using these things, see https://shareopenly.org/share/?url=https://example.com, and it requires the user to paste a value in once, and then by the looks of it it will remember that site via a cookie. Not great, but I guess it works. But I’m sceptical anyone will really use it.
OK well I think there's one superior aspect to the main post which is that it is short and not difficult to understand all of what will happen. This web-share-target requires more thinking about.
Also some stuff I dislike:
>The user agent MAY automatically register all web share targets as the user visits the site, but it is RECOMMENDED that more discretion is applied, to avoid overwhelming the user with the choice of a large number of targets.
Yeah, specs that leave it open to site discretion whether or not to be abusive have a great deal of success.
>This specification has no known accessibility considerations.
No really!?
Yeah a screenreader functions as a sequential medium, so what happens with registry of all share targets with screenreader, in fact what happens when screenreader comes to site, screenreader now will tell you that you have shares first? This is up to the browser how they tell the user that there are shares and ask for their input? So it will work differently between browsers?
I have found some bugs before in Google provided specs that were somewhat annoying for screenreader usage, and evidently the reasoning they must have had was that there were no known accessibility considerations because they sure didn't specify any.
> Yeah a screenreader functions as a sequential medium, so what happens with registry of all share targets with screenreader, in fact what happens when screenreader comes to site, screenreader now will tell you that you have shares first? This is up to the browser how they tell the user that there are shares and ask for their input? So it will work differently between browsers?
Both Android and iOS have sharing mechanisms that work just fine with screen readers. They show the most common/likey/favourited options first, with an option to expand to other apps/share targets. My phone has dozens of options, but I rarely need to scroll beyond the first line to find the share target I'm looking for.
The share dialog is an OS/browser control, not something the web page needs to render, so it's as accessible as the browser decides it should be. Many Linux distros lack such a control, but on Android/iOS/Windows/presumably macOS, this is a solved problem.
the problem for me at any rate, reading the spec, is trying to think out exactly how this will be affected by the ability of the site to add multiple share targets
as quoted >The user agent MAY automatically register all web share targets as the user visits the site, but it is RECOMMENDED that more discretion is applied, to avoid overwhelming the user with the choice of a large number of targets.
The spec evidently feels it won't make any difference at all, but I'm not sure, and it's harder for me to reason about this than the simple rel share url thing.
> The only real problem is that you can’t feature-detect share_target support
I didn't know this existed, so the first thing I did is check the caniuse website, and yeah not even they have info about the Web Share Target API[1][2]. As of writing this comment, they only have info about the Web Share API[3].
[1]: https://github.com/Fyrd/caniuse/issues/4670
[2]: https://github.com/Fyrd/caniuse/issues/4906
[3]: https://caniuse.com/web-share
Links on support:
https://github.com/mdn/browser-compat-data/blob/main/manifes... (data integrated into the MDN page I linked)
Chromium: https://chromestatus.com/feature/5662315307335680, implemented on Android from M71 and desktop from M89.
WebKit: standards position is neutral <https://github.com/WebKit/standards-positions/issues/11>, and https://bugs.webkit.org/show_bug.cgi?id=194593 shows plenty of developer interest but doesn’t look to have been touched by Apple.
Firefox: standards position is positive <https://mozilla.github.io/standards-positions/#web-share-tar...>, but https://bugzilla.mozilla.org/show_bug.cgi?id=1476515 has languished.
Because as with many, many, many APIs that Chrome ships it's not a spec:
- there's a giant banner on the left saying "unofficial"
- The "Status of this document" section states the following:
--- start quote ---
This document is a draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.
--- end quote ---
But just because it was shipped in Chrome and has some napkin scribbles resembling an official spec, people will both claim it's a spec and expect everyone to implement it.
> There’s already a better spec from 2016
aka
This document is a draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.
It’s been implemented in Chromium for 4–6 years, Firefox’s position is positive (admittedly that was 2019), WebKit’s is neutral, and there are bugs open in both Firefox and WebKit.
I regularly criticise Google-only specs and point out how they’re not standards in any way, but this one is not really like that—it’s just that the other two platforms are missing a couple of other pieces that are better to get in place first, and it’s not a high priority for them.
And certainly in the context of this rel="share-url" outsider proposal, nah, the share_target manifest reference is still way more “official” than that.
> It’s been implemented in Chromium for 4–6 years
It makes it a non-official Chrome-only non-standard
> Firefox’s position is positive (admittedly that was 2019), WebKit’s is neutral,
Positions don't make a spec
> but this one is not really like that—it’s just that the other two platforms are missing a couple of other pieces
It literally means that in the very literal sense of the word literal:
The "Status of this document" section states the following:
--- start quote ---
This document is a draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.
--- end quote ---
Which part of that tells you that "it's not like that"? It's not even on a standards track. It's not even a Working Draft (the very first level of a spec when vendors agree on the idea, but haven't iterated on the API: https://www.w3.org/policies/process/#rec-track)
> the share_target manifest reference is still way more “official” than that.
Google presents these napkin scribbles in the w3c format precisely so that gullible people would wave them around as actual specs.
But unlike the proposal by the blog author, it's already been implemented by at least one browser vendor and received positive responses from another.
Sure, we could throw in another spec and maybe Mozilla will implement this one and maybe Safari won't be neutral to the new one, but why go through that effort when there's already a working solution to this problem?
I've responded to a similar question in a sibling comment: https://news.ycombinator.com/item?id=44989500
Does anyone even use share buttons? I always just copy the link, and it seems that anyone I see sharing things does the same. It feels more like a way for the social media companies to advertise/track, and those sites have been sending less and less traffic for years, so I wonder why every site still has them.
Yeah, they do. We’ve hooked up analytics to test it in the past and the average user absolutely uses them.
[dead]
tiktok share links also dox you. they have a banner with the name and profile picture of the person that shared it
They also track your friends and acquaintances through shares. Even if you don't give them access to contacts, and don't even use TikTok beyond scrolling through videos, they will start suggesting people who have seen your shares as your friends.
[dead]
Facebook's too.
Yeah I don't know if I've ever used them. Maybe once or twice ever. For me the main problem is UX. Sharing from my platform (copy url on computer, share button on android) is always in the same place. But the share button built in is never in the same place across different websites, how could it be?
They do. I built a file sharing page for friends and most were confused how to share me a link to a file. I implemented the copy url button they asked for and no complaints, even though the url is always visible on every browser they use
I only ever click Firefox's email link button, or copy the page link for posting on HN.
On iOS, it is much fast to share with a contact or an app with the share button than by copying and then switching to another app and pasting.
The TFA is about how to craft a "Share on {ExternalSite}" URL, not a "Share this page" button.
People use apps nowadays to do everything, the only way to get links out of apps is share buttons.
Exposing the sharing intent is a problem, not a goal.
Sharing a link is easy. That's why URLs were invented. Exposing the sharing intent is only beneficial to companies that want to track you.
Sure, pressing "share on facebook" might be slightly lower friction than copy-pasting the link, but if the sharing isn't worth that friction, perhaps don't?
The article is proposing a technical solution to a business problem.
I have no doubt this proposal or any other similar proposal would work well in the 90s or early 2000s. Let's go one step further and let browsers work with all those third party website and figure all the details for sharing, and websites never embed anything.
But you see, that's not the problem. These share buttons are often trojans on websites. Facebook tracks you via those share buttons even if you have never had a Facebook account. And people come up with various solutions to tackle that -- adblockers just block network traffic, while a small amount of website owners create a separate switch which you can toggle and then share with Facebook. Isn't all of that stupid? I don't see why Facebook, Instagram will be eager to opt in to this solution and make the experience good.
Yeah, for those branded buttons on websites this isn't an alternative. They want all their JavaScript for collect information on the user, even if they don't press the button.
I believe this is to play with (mobile) browser's share button, while even there I don't get how this is supposed to work.
First: How does this figure out where I want to share to? And then: Would it have to load the shared-to page first, parse it to see if there is such a Tag and then interpret it?
Maybe I am missing something.
exactly my thought, links work fine as they are, my biggest problem with them is 9 times of 10 I don't know where they lead. Fixing one "share" use case isn't solving a misuse
Does this mean that, when the user clicks a "share to social.network" button in random.com, the browser would first request the full html page of social.network (in the background) only to parse the rel="share-url" link? Seems a bad design.
That's how I'm reading it? It's a bit clunky, but sometimes you have to be pragmatic :(
Only tangentially related to the main subject, but the post ends with:
> Extensions to the predefined set of link types may be registered on the microformats page for existing rel values.
Please don't. WHATWG's tendency to self-anoint and all its idiosyncrasies notwithstanding, the IANA maintains the link relation registry[1]. Use the procedure prescribed in the RFCs.
1. <https://www.iana.org/assignments/link-relations/link-relatio...>
This is what I currently use on my blog and it works particularly well:
Plus if the page has images, the browser will automatically use it.That will work for sharing (except on Firefox), but only Chromium support actually receiving these share events, which is half the spec.
Looking at ShareOpenly, I think this is basically a reaction to "Mastodon instances make social sharing complicated from the web". A "share to Mastodon" button is impossible, and a button for every Mastodon instance in existence is impractical. Thus a "fuck it, I guess just put in a URL and we'll work out how to send something to it" solution.
Speaking as someone who never ever uses a share button I think this is misguided, we should just remove that entire class of widget from the web, and people who want to share things can copy-paste the URL into their platforms of choice.
I agree. Except we aren't there with web literacy and having that integrated UX is significant.
I think the sort of person who would paste/type the URL for another social service into the freeform "or some other service" input on ShareOpenly is exactly the sort of person who has that web literacy, though. Which I guess doesn't support my "delete them all!" desire, but rather sadly reinforces keeping the status quo.
I don't care for the dash myself. I would have chosen something more like rel="shareable"
So, it's a way to tell other applications how they would craft a URL on your site such that they can prefill a form on your site?
A meta tag in the html of your webpages seems like the wrong place for that info since it's not something that changes per page unlike the OpenGraph/TwitterCard meta tags that tell third-party apps how to generate a preview of the page.
Surely a better place would be example.com/.well-known/share-url.
One thing I really don't like about it is the implication that the url and the share-button could refer to different things. I feel like browser vendors probably care about knowing whether users use the share button or copy/paste the URL, but hypothetically they know already and I don't feel like most (any?) websites need that information -- it might correlate to a sophistication-level of the user and be used for targeting by scammers, and that could be bad.
For me, I use history.replaceState to change the url after I've got my campaign tracking to the share link, this way the browser's built-in share button does all the work for me. I can detect trivial-reload by checking the cookie I dropped when the page came in, so I don't mis-attribute shares. It is a shame I cannot do this so easily without JavaScript, but I'm sure I can actually buy non-JavaScript users from Google (and other ad platforms) so I'm not sure it's worth worrying about.
I was thinking A button can also be an alternative with all data sent as post, but apparently the button attributes don’t include any ability to specify form values. This has to be done via JS or via additional tags (which is still an option).