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.

Sign up for GitHub

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

Jump to bottom

Associate a web app with a manifest #17

Closed
marcoscaceres opened this issue Apr 24, 2013 · 18 comments · Fixed by #43, #45 or #203
Closed

Associate a web app with a manifest #17

marcoscaceres opened this issue Apr 24, 2013 · 18 comments · Fixed by #43, #45 or #203
Labels
Feature Request P1 question

Comments

@marcoscaceres
Copy link
Member

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

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

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.

@jmajnert jmajnert mentioned this issue Apr 25, 2013
Open
@marcoscaceres
Copy link
Member Author

work started...

@ghost ghost assigned marcoscaceres May 13, 2013
@marcoscaceres marcoscaceres mentioned this issue May 24, 2013
Merged
@marcoscaceres
Copy link
Member Author

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

@mounirlamouri
Copy link
Member

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

@marcoscaceres
Copy link
Member Author

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
@marcoscaceres
Merge pull request #43 from marcoscaceres/appconfig-attribute
c39f90c 
Added `appconfig` attribute to html element (closes #17)
@nikhilm
Copy link

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.

@raucao
Copy link
Contributor

raucao commented May 30, 2013

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

@marcoscaceres
Copy link
Member Author

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

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

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

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)?

@raucao
Copy link
Contributor

raucao 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

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

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

@hsivonen
Copy link
Member

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 mentioned this issue Jun 5, 2013
Merged
@AMorgaut
Copy link

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

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

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 added a commit that referenced this issue May 22, 2014
@marcoscaceres
Rewrite of fetching and processing (closes #17, #186, #188, #195, #198 )
7e71539 
* 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 marcoscaceres mentioned this issue May 22, 2014
Merged
marcoscaceres added a commit that referenced this issue May 23, 2014
@marcoscaceres
Merge pull request #203 from w3c/cors
381efb2 
Rewrite of fetching and processing (closes #17, #186, #188, #195, #198)
@mgiuca mgiuca mentioned this issue Nov 5, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature Request P1 question
Projects
None yet
Milestone
No milestone
6 participants
@raucao @AMorgaut @nikhilm @hsivonen @mounirlamouri @marcoscaceres