Open mgiuca opened 4 years ago
Your suggestion makes total sense to me. The platform
member isn't defined in just one spot though, right?
It is defined centrally and linked from both ImageResource
and ExternalApplicationResource
(which could represent a problem for splitting out ImageResource
). See https://www.w3.org/TR/appmanifest/#platform-member-0
It is defined centrally and linked from both ImageResource and ExternalApplicationResource (which could represent a problem for splitting out ImageResource). See https://www.w3.org/TR/appmanifest/#platform-member-0
Thanks for clarifying. We were not including platform
as a member of ImageResource, so it would just exist in the subclass within the manifest spec, so I think we’re good.
Not used beyond related_applications in Blink:
Not used in Firefox according to @marcoscaceres
Not used in WebKit:
In supporting screenshots
in the App Info spec, I have established a Wiki page documenting platform
values. Perhaps we can reference that?
On a somewhat related note: Does anyone think it might make sense to move related_applications
to the App Info spec?
On a somewhat related note: Does anyone think it might make sense to move
related_applications
to the App Info spec?
related_applications
is directly used by the in-incubation getInstalledRelatedApps
feature, which is implemented in browsers, not by other processors. Now, that's in incubation, but my point is that it's difficult for both new APIs to be designed or for browser manufacturers to make use of metadata if it's "not really part of the manifest, just supplemental information".
Honestly, I wish we didn't split the manifest into App Info vs main. As I argued when it was proposed, I think it's an unhelpful distinction to say "these members are for browsers" vs "these members are for other manifest processors". What if a browser wants to use a member from App Info, for example if we wanted to start displaying screenshots in the browser at install time?
I agree. I sincerely hope that we can incubate App Info and then merge it back.
Now that we have App Info, does it make sense to move related_applications
there?
Currently, we have duplicate definitions of known platform values:
(Speaking of the wiki, we could also retire the Categories page, and maybe the TPAC 2018 page as well.)
@christianliebel Aaron asked the same question above; see my response.
Currently, the advice on what UAs should name their
platform
member is fairly vague:This has caused some recent confusion as
getInstalledRelatedApps
is being incubated, which uses theplatform
member of therelated_applications
member to determine whether to look at a particular app.In particular, there is confusion as to whether to name the platform after the application store (e.g.,
"play"
) or the operating system (e.g.,"android"
). Historically, Chrome has used"play"
, but that was for promoting installation of a native application from the Play Store; now it seems"play"
is being used bygetInstalledRelatedApps
to check for any Android APK, and it seems using the OS name would be more appropriate there. (Or, as @dominickng says on that thread, filter to only report apps installed by the Play Store.)We could possibly offer more guidance around when to use the name of the store, and when to use the name of the OS. It's possible that both are appropriate, depending on the context.
Some possible text:
This also means that the example under purpose member is (retroactively) wrong: it uses
"play"
when talking about icons "specifically designed for the Android platform", when it should use"android"
, since presumably that icon should also be seen when installed from another store. In general, it doesn't make sense forImageResource
s to have a storeplatform
; they should always have OSplatform
s.