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

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.

There’s already a better spec from 2016, which has even been shipping in the Chromium family since 2021:

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.

I don't care for the dash myself. I would have chosen something more like rel="shareable"

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

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.

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.

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.