Re: [w3c/manifest] Use WebIDL to describe the manifest data structure (#611)

Note there is a preview [here](https://s3.amazonaws.com/pr-preview/kenchris/manifest/idl.html). In particular, the [WebAppManifest](https://s3.amazonaws.com/pr-preview/kenchris/manifest/idl.html#webappmanifest-dictionary).

So is the issue just the naming discrepancy between the manifest fields and normal web attributes ("`short_name`" vs "`shortName`")? Or is it more fundamentally that we shouldn't create an IDL that isn't actually exposed on the web?

> What exactly do you get from IDL and what would this look like?

The reason for this is mostly for readability. It's becoming increasingly harder to read the manifest spec because there are so many fields. I would like to be able to see at a glance what all the fields are and their types. WebIDL is a convenient language to describe it succinctly instead of loads of prose algorithms.

Another advantage is that an implementation could potentially just take the IDL, parse it, and generate manifest parser code. Obviously we can already do that today (but we don't do this today in Chrome), but it would make sense to have "official" IDL for the manifest, rather than implementations essentially writing their own IDL to match the prose text in this document.

Having said that, we do have to be careful because we might want to expose some of these in JavaScript APIs. The original motivation was Ken's [shortcuts proposal](https://gist.github.com/kenchris/0acec2790cd38dfdff0a7197ff00d1de), which has a `ShortcutInfo` dictionary that would be both the type of a field in the manifest _and_ the type of parameters to a JavaScript API. That `ShortcutInfo` dictionary itself has an `icons` field which has the same type as `icons` in the manifest (so that means the dictionary Ken calls `ImageResource` in his PR would also be exposed to JavaScript APIs). And Google's proposed [getInstalledRelatedApps](https://github.com/WICG/get-installed-related-apps) API would also return instances of the `related_applications` manifest member (which Ken calls `ExternalApplicationResource` in his PR).

So I think in the future, there _will_ be some of these dictionaries exposed to web APIs (and that is part of the motivation behind this change). Questions for the community:

1. Is it inappropriate to have underscores in dictionary fields that are exposed on the web?
2. If so, if we expose manifest members to JavaScript APIs, will we need to expose them under camelCase names instead?
3. If so, should we specify the manifest version and the JS version as two different IDL dictionaries, or have some kind of automated renaming mechanism like Marcos mentioned CSS does.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/611#issuecomment-332382022