Skip to content
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

Associate a web app with a manifest #17

Closed
marcoscaceres opened this issue Apr 24, 2013 · 18 comments
Closed

Associate a web app with a manifest #17

marcoscaceres opened this issue Apr 24, 2013 · 18 comments

Comments

@marcoscaceres
Copy link
Member

@marcoscaceres marcoscaceres commented Apr 24, 2013

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/">
@mounirlamouri
Copy link
Member

@mounirlamouri mounirlamouri commented Apr 24, 2013

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>.

@marcoscaceres
Copy link
Member Author

@marcoscaceres marcoscaceres commented Apr 25, 2013

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.

@marcoscaceres
Copy link
Member Author

@marcoscaceres marcoscaceres commented Apr 30, 2013

work started...

@marcoscaceres
Copy link
Member Author

@marcoscaceres marcoscaceres commented May 27, 2013

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

@mounirlamouri
Copy link
Member

@mounirlamouri mounirlamouri commented May 28, 2013

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

@marcoscaceres
Copy link
Member Author

@marcoscaceres marcoscaceres commented May 28, 2013

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 added a commit that referenced this issue May 29, 2013
Added `appconfig` attribute to html element (closes #17)
@nikhilm
Copy link

@nikhilm 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">
</html>

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
Copy link
Contributor

@skddc skddc commented May 30, 2013

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

@marcoscaceres
Copy link
Member Author

@marcoscaceres marcoscaceres commented May 30, 2013

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

@marcoscaceres marcoscaceres reopened this May 30, 2013
@mounirlamouri
Copy link
Member

@mounirlamouri mounirlamouri commented May 31, 2013

Taking the risk to sound like a broken record, doing

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

could make everybody happy.

@marcoscaceres
Copy link
Member Author

@marcoscaceres marcoscaceres commented May 31, 2013

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
Copy link
Contributor

@skddc 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. :)

@marcoscaceres
Copy link
Member Author

@marcoscaceres marcoscaceres commented May 31, 2013

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.

@marcoscaceres
Copy link
Member Author

@marcoscaceres marcoscaceres commented Jun 3, 2013

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

@hsivonen
Copy link

@hsivonen 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>.

@AMorgaut
Copy link

@AMorgaut AMorgaut commented Jun 24, 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?

@marcoscaceres
Copy link
Member Author

@marcoscaceres marcoscaceres commented Jun 24, 2013

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
@marcoscaceres
Copy link
Member Author

@marcoscaceres marcoscaceres commented 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 modified the milestones: Last Call Working Draft, First Public Working Draft May 21, 2014
@marcoscaceres marcoscaceres added the V1 label May 21, 2014
marcoscaceres added a commit that referenced this issue May 22, 2014
* 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.
marcoscaceres added a commit that referenced this issue May 23, 2014
Rewrite of fetching and processing (closes #17, #186, #188, #195, #198)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.