Comment by chrismorgan

Comment by chrismorgan a day ago

12 replies

View on Hacker News

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.

bryanrasmussen a day ago

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.

Reply View 2 replies
  • jeroenhd 20 hours ago

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

    Reply View 1 reply
    • bryanrasmussen 10 hours ago

      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.

      Reply View 0 replies
quectophoton a day ago

> 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

Reply View 2 replies
[removed] a day ago
[deleted]
Reply View 0 replies
troupo a day ago

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

Reply View 4 replies
  • chrismorgan a day ago

    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.

    Reply View 1 reply
    • troupo 21 hours ago

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

      Reply View 0 replies
  • jeroenhd 20 hours ago

    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?

    Reply View 1 reply