-
Notifications
You must be signed in to change notification settings - Fork 13
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
Allow additional properties in manifest #43
Comments
I'm hesitant about this. This opens us up to future compatibility hazards for both specs, if they ever end up with overlapping keys. If we were to encourage merging of manifests, then I think we should just merge this spec into the web app manifest spec, so that they stay coordinated by the same editor group. |
Ideally we'd have a clear suggestion to the web developers to either always merge or always separate the manifests. This will make implementer's job easier (one fewer feature to implement and test) and web developer's project planning easier (one less decision to make). @marcoscaceres - Do you have an opinion on the correct approach here? cc @danyao |
I agree with @domenic about the compatibility risk. Editors of both specs would have to keep this special use case top-of-mind with all future changes; otherwise, a simple name conflict may silently break something and be hard to debug. The benefit is not clear to me to be worth this risk. I can support either merging the payment method manifest into the web app manifest spec, or vice versa per @domenic 's suggestion. |
Web Manifest are tied to the document that declares the If we move to a world where payment handlers are installed web applications (just like Web Share Targets are), then it would be appropriate for "supported_origins" to be part of Web Manifest, maybe under some new member like "payment_handler". That would negate the need for this specification - but comes at the cost of supporting JIT. Personally, I think it's fine... we don't JIT Web Share Targets, so we probably shouldn't need to JIT payment handlers either. |
It would be useful to merge the properties in this manifest with a Web App manifest where, for example, the payment method has a single app which is the default.
E.g. If a developer builds a payment app and hosts the app manifest at
https://example.com/manifest.json
they could also make this the payment method manifest by adding the properties:"default_applications": ["https://example.com/manifest.json"]
"supported_origins": ["https://example.com"]
The payment method identifier would then also be
https://example.com/manifest.json
Can the following text be removed or modified to allow for this:
The resulting JSON object must contain at most two items, with the possible keys "default_applications" and "supported_origins".
The text was updated successfully, but these errors were encountered: