- From: L. David Baron <notifications@github.com>
- Date: Tue, 16 Jan 2018 22:55:49 +0000 (UTC)
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/221/358135611@github.com>
So a few thoughts so far (in somewhat random order): * I'm slightly disturbed that [WebAppManifest uses underscores](https://w3c.github.io/manifest/#webappmanifest-dictionary) in the names of the members of the dictionary... but this is at least consistent with that, which is better than being inconsistent. (I mean... I actually like underscores in general, but they haven't been popular in web APIs elsewhere.) * I've been wondering for a while about having something MIME-type specific, for example, to address things like the use case of calendar apps that want to receive text/calendar files (even those not coming from the Web Share API). See, for example, a [recent discussion on mozilla.dev.platform](https://groups.google.com/d/topic/mozilla.dev.platform/jeTDLz38_RE/discussion) about removal of `navigator.registerContentHandler`. That's perhaps broader than a general share/share target API, but I've thought it was something useful to solve. (Consider, for example, pages from those for [WebEx conference calls](https://mit.webex.com/mit/j.php?MTID=m666813deba240a8825050a9f6dadcce7) to my dentist that offer ICS files (`text/calendar`) that I'd love to add to my google calendar from my browser.) It seems at least worth thinking about whether this API could be extended to handle that case, even if it doesn't happen right now. * a dummy parse using empty values (or nonempty alphabetic values) seems reasonable to me; I can't think of anything better offhand, though maybe @annevk has ideas * sites supporting this presumably need to be pretty careful even if the arbitrary data ends up in the query string. Limiting to being in the query string or the hash seems less than ideal, but allowing things like .. also seems less than great. (What are the rules on interpreting escaped `/`?) Imposing a particular URL structure seems less than ideal -- but on the other hand, you could think of it like form submission, which is where I suppose query strings came from in the first place. I suppose I can't make a particularly strong argument either way, but maybe others have thoughts. * the spec probably should describe the escaping of data that implementations do when substituting into the placeholders in the `url_template`; it doesn't currently appear to describe this. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/221#issuecomment-358135611
Received on Tuesday, 16 January 2018 22:56:14 UTC