-
Notifications
You must be signed in to change notification settings - Fork 66
Support additional media types? #258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
hi @ktk! Apologies for the delay in replying.
The spec does not impose this restriction. This is something MDN has listed, possibly to match Chrome or some other browser. The spec only says, as part of validate share data:
And, as part of
So, its browsers themselves that are imposing this list. However, it's for a very good reason: security. On most OSs, sharing triggers the presentation of a share sheet. That share sheet will often try to parse and/or process the data, URLs, and file(s) being shared (e.g., to create a preview) often before the user actually shares. A malicious website can (and have!) use the shared data to attack/confuse the share sheet's parser/processor. This could also (potentially) be done with "text/turtle". The restricted list chosen by browsers is fairly "battle hardened", but yes... quite restricted. So, it would be up to browser and OSs to trust "text/turtle" for them to enable it if they trust such files. Does that make sense? @ktk, for record keeping purposes, please indicate if your are satisfied with this response. |
Note that there is related discussion around types here also: It's something we may revisit in the future. |
I'm going to go ahead and close this as answered. @ktk, let me know if you have further questions or concerns (and I can reopen the issue if need be). |
Hi,
We tried to implement some use-cases with Web Share API, unfortunately we ran into limitations due to the limited set of supported Shareable file types. In our case we want to pass RDF around in the
text/turtle
serialization, which is a common media type in our field.I found #182 as well which seems related but I don't get why this is a hand-picked subset of existing media types. IMO it would make more sense to be able to use any potential media type in here, as use-cases for this API could be very generic.
What is the reasoning for the hand-picked subset available in the current spec?
The text was updated successfully, but these errors were encountered: