Associate a web app with a manifest #17

marcoscaceres opened this Issue Apr 24, 2013 · 18 comments


None yet

6 participants


There is currently no declarative means for an web application to associate itself with a manifest. This would be good for autodiscovery by the UA, for search engines, and for when javascript is disabled.

Something like:

<!doctype html>
<html config="/manifest/">
<!-- OR --> 
<link rel="appconfig | config | appmanifest | manifest | details | appdetails " src="/manifest/">

We could also use

<html manifest='manifest.json'>

and have the UA reading the file as a JSON file and if not working, reading it as an appcache manifest. That would work except that if people use a JSON file and the UA doesn't know about application manifest, things wouldn't work. If UAs commit to implement it, we could solve that problem quickly.
I'm saying that because I believe that the manifest attribute would be the best thing to do but if people are happy with using the config attribute or <link>, we can do that too.

I think we should add this to the specification very quickly. It is an incredible advantage to the manifest format and would allow some new Web APIs to be based on this manifest instead of adding tons of stuff in <meta>.


Though that would be the ideal solution, I'm not sure it will fly: it would break compatibility with legacy user agents and user agent's that may choose not to support this for a while (so you could only really add the attribute dynamically with JS, after doing feature detection or browser sniffing) - or you would need to do content negotiation on the server, which is also painful.

About adding it to the spec, I agree we should add this quickly - I'll do it in the next few days. Here are some potential attribute names: appconfig | config | appmanifest | details | appdetails. 🌟 More suggestions welcomed!!! 🌟

As we are extending HTML, I'm wondering if we need to do this with coordination with the HTML/WHATWG as an extension spec? @darobin might know, but we can cross that bridge when we get to it.


work started...


It was suggested on twitter that we call the attribute "app". Any thoughts?


I think it would send the wrong message. What about using <link> ?


I need to check the processing model of link and implications of using it. I think it would be good to get @hsivonen to provide some guidance here also.

@marcoscaceres marcoscaceres closed this in #43 May 29, 2013
nikhilm commented May 30, 2013

Is this closed for discussion?

appconfig just makes things confusing. The web runtime is clearly using the term 'manifest' everywhere, including this spec, and the conventional manifest.webapp or manifest.json filename used by web apps. In this context appmanifest would be better no?

<html appconfig="/path/to/manifest.json">

seems very odd, not to mention that the manifest is not a configuration, but a declaration of what this application is. A configuration is something that decides some imperative behaviour of the program and is open to end-user customization to affect the behaviour of the program.

skddc commented May 30, 2013

I agree. manifest or appmanifest seem more appropriate to me.


The problem is that people keep confusing this with appcache manifest.

@marcoscaceres marcoscaceres reopened this May 30, 2013

Taking the risk to sound like a broken record, doing

<link re='manifest' href='manifest.webapp'>

could make everybody happy.


What we are missing are the technical arguments/implications for one or the other. What are the pros and cons of each approach (using an immutable attribute vs using link)?

skddc commented May 31, 2013

True. I tried to come up with more alternatives, but ended up finding appconfig the second best option after all. :)


So, link is defined as:

The link element allows authors to link their document to other resources.

So fits really nicely. Things I really like:

  1. "User agents may opt to only try to obtain such resources when they are needed, instead of pro-actively fetching all the external resources that are not applied."
  2. Fetching and CORS is already defined (see obtain the resource).
  3. "manifest" is not taken yet.
  4. It's similar to linking to a stylesheet
  5. it reuses existing HTML infrastructure without the need of extending HTML. We just need to add "manifest" to HTML's link type section.

Will provide more thoughts on this a bit later, but the above is a start.


Ok, I've started working on adding <link rel=manifiest>. Will send PR later today. @skddc, would appreciate your input.

hsivonen commented Jun 4, 2013

If the manifest includes NavigationController-ish stuff so that resource loads depend on the manifest, an attribute on the root element should be used for the same reason that the current app cache uses an attribute on the root element instead of <link>.

@marcoscaceres marcoscaceres closed this in #45 Jun 6, 2013

I personally really like using tags for such things.

Still, if:

  • the app cache manifest requires to be defined as @hsivonen mentioned as a root element attribute,
  • and if our webapp manifest intends to be the new place to declare the app cache manifest,
    we may need to declare it via an attribute as well.

@hsivonen could you please provide the reference to the constraint you mentioned?


I don't think the same restrictions apply as in app cache, which is why we went from having an attribute to having the link element.

@marcoscaceres marcoscaceres reopened this May 21, 2014

In light of recent bugs #187 #186 #188, it seems that <link> might not be the right tool for the job. The only reasonable alternative appears, to me, to be:

  1. Go back to using an attribute on the HTML element.
  2. Respect HTML:
    • fire events.
    • respect the media attribute as well as all other attributes.
    • respect the silly crossorigin attribute requirement for CORS.
    • deal with consequences that could come from new attributes being added to link in the future.
    • pick elements based on "suitability" (based on attributes) rather than tree order.
  3. Continue to violate HTML:
    • don't fire events.
    • don't honor media attribute.
    • use tree order to determine which element is picked.
    • possibly override how CORS behavior works for 'manifest' link types.
    • ignore hreflang attribute, and possibly other attributes of link.
@marcoscaceres marcoscaceres added a commit that referenced this issue May 22, 2014
@marcoscaceres marcoscaceres Rewrite of fetching and processing (closes #17, #186, #188, #195, #198 )
* Formalizes using link element as the solution (closes #17)
* Banned media attribute. At least, we say that it's not considered
during processing. (closes #186)
* Added text about when events need to be fired (closes #188)
* The fetch part of the specification now mentions the crossorigin
attribute (closes #195)
* fixed copy/pasta error relating to icons/orientation (closes #198)
* fixed a whole bunch of editorial issues.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment