Comments (18)
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>
.
from manifest.
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.
from manifest.
work started...
from manifest.
It was suggested on twitter that we call the attribute "app". Any thoughts?
from manifest.
I think it would send the wrong message. What about using <link> ?
from manifest.
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.
from manifest.
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.
from manifest.
I agree. manifest
or appmanifest
seem more appropriate to me.
from manifest.
The problem is that people keep confusing this with appcache manifest.
from manifest.
Taking the risk to sound like a broken record, doing
<link re='manifest' href='manifest.webapp'>
could make everybody happy.
from manifest.
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)?
from manifest.
True. I tried to come up with more alternatives, but ended up finding appconfig
the second best option after all. :)
from manifest.
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:
- "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."
- Fetching and CORS is already defined (see obtain the resource).
- "manifest" is not taken yet.
- It's similar to linking to a stylesheet
- 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.
from manifest.
Ok, I've started working on adding <link rel=manifiest>
. Will send PR later today. @skddc, would appreciate your input.
from manifest.
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>
.
from manifest.
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?
from manifest.
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.
from manifest.
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:
- Go back to using an attribute on the HTML element.
- 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.
- 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 oflink
.
from manifest.
Related Issues (20)
- Icon purpose "any" is confusing HOT 4
- suggest in standard calling website->webapp process unified "add to home screen" or such in all browsers (not install) HOT 7
- Define "web application" HOT 9
- Identifier for external interpretation HOT 4
- x HOT 1
- err_invalid_url HOT 1
- Reword ‘member’ to ‘field’ HOT 1
- Feature request: "isolate web app" hint HOT 10
- When generating a 'default' manifest (where there wasn't any linked), manifest_url doesn't exit
- Privacy consideration specifies an unenforceable "MUST NOT" condition on developers
- Way to detect if a web app is installed HOT 2
- Manifest id should strip fragment at parse time HOT 1
- IHeyReally HOT 1
- Wammi123
- Wammi123
- IHeyReally-85d32
- Wammi123
- HTML Tidy action broke
- مانفیست
- All String should be localizable HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from manifest.