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

Comments

Projects
None yet
6 participants
@marcoscaceres
Member

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

This comment has been minimized.

Show comment
Hide comment
@mounirlamouri

mounirlamouri Apr 24, 2013

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Apr 25, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Apr 30, 2013

Member

work started...

Member

marcoscaceres commented Apr 30, 2013

work started...

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres May 27, 2013

Member

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

Member

marcoscaceres commented May 27, 2013

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

@mounirlamouri

This comment has been minimized.

Show comment
Hide comment
@mounirlamouri

mounirlamouri May 28, 2013

Member

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

Member

mounirlamouri commented May 28, 2013

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

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres May 28, 2013

Member

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.

Member

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 marcoscaceres closed this in #43 May 29, 2013

marcoscaceres added a commit that referenced this issue May 29, 2013

Merge pull request #43 from marcoscaceres/appconfig-attribute
Added `appconfig` attribute to html element (closes #17)
@nikhilm

This comment has been minimized.

Show comment
Hide comment
@nikhilm

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

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

This comment has been minimized.

Show comment
Hide comment
@skddc

skddc May 30, 2013

Contributor

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

Contributor

skddc commented May 30, 2013

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

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres May 30, 2013

Member

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

Member

marcoscaceres commented May 30, 2013

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

@marcoscaceres marcoscaceres reopened this May 30, 2013

@mounirlamouri

This comment has been minimized.

Show comment
Hide comment
@mounirlamouri

mounirlamouri May 31, 2013

Member

Taking the risk to sound like a broken record, doing

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

could make everybody happy.

Member

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres May 31, 2013

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@skddc

skddc May 31, 2013

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres May 31, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 3, 2013

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@hsivonen

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

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

This comment has been minimized.

Show comment
Hide comment
@AMorgaut

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

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 24, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres May 21, 2014

Member

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

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 added V1 and removed Work in progress labels May 21, 2014

marcoscaceres added a commit that referenced this issue May 22, 2014

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.

marcoscaceres added a commit that referenced this issue May 23, 2014

Merge pull request #203 from w3c/cors
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