Skip to content

Instantly share code, notes, and snippets.

@marcoscaceres

marcoscaceres/manifest-options.md

Last active December 13, 2022 02:00
Show Gist options
  • Star 9 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
  • Save marcoscaceres/7783977 to your computer and use it in GitHub Desktop.
Save marcoscaceres/7783977 to your computer and use it in GitHub Desktop.
Download ZIP
In-lining manifests.
Raw
manifest-options.md

Conclusions

updated on 19th of December

Thanks everyone who participated in the discussion! It was tremendously userful

So, what we are going to do initially is only support:

<link rel="manifest" href="...some URL...">

By virtue of this being a URL, if people really want to inline the manifest they can use a data: URL:

<link rel=manifest href="data:application/manifest+json,{ ... }">

Credit to @yoavweiss for proposing the above on the public-webapps mailing list.

If, after some time, we find a lot of people are inlining manifests in the wild, we can return and look at alternatives - like using <script> or <meta>.

Which one do you prefer?

We are trying to create a new manifest format for the Web. It will allow you to define metadata for a web application in one place.

Right now, we are trying to decide how to "inline" the manifest into HTML. Need your feedback.

A - using a meta element and content attribute

<!doctype html>
<html>
<head>
...
<meta name="manifest" content='{
  "name": "Example",
  "url": "/start.html",
  "mode": "standalone",
  "icons": [{
      "src": "icon/lowres",
      "density": "1",
      "width": "64",
      "type": "image/webp"
    }, {
      "src": "icon/hd",
      "density": "2",
      "width": "64"
  }]
}'>
...

B - using a script tag

<!doctype html>
<html>
<head>
...
<script type="application/manifest+json">
{
  "name": "Example",
  "url": "/start.html",
  "mode": "standalone",
  "icons": [{
      "src": "icon/lowres",
      "density": "1",
      "width": "64",
      "type": "image/webp"
    }, {
      "src": "icon/hd",
      "density": "2",
      "width": "64"
  }]
}
</script>

External linking

<link rel="manifest" href="app.json">`

OR

  <script src="app.json" type="application/manifest+json"></script>

Got a better idea?

Please share it in the comments!

@cranca
Copy link

cranca commented Dec 5, 2013

I also agree with the link solution. It's cleanest and doesn't add more noise to HTML docs... But if I had to choose a inline way I like manifest proposal because it's more semantical than script.

@andreasbovens
Copy link

I'm with @pornel. It would be nice to (re)use <meta> and <link> elements as much as possible.

@tobie
Copy link

tobie commented Dec 5, 2013

Using a meta element and JSON in the content attribute is a terrible idea. Here's why.

  1. It forces using single quotes to wrap the content attribute, special-casing this attribute in the process. So while you can easily wrap an onclick attribute with double or single quotes, e.g.:

    <a href="#" onclick="alert('clicked!');">Click me!</a>
<a href='#' onclick='alert("clicked!");'>Click me!</a>

    that wouldn't work for our manifest. The following works:

    <meta name='manifest' content='{ "name": "Example" }'>

    But this would not (the content isn't valid JSON):

    <!--- THIS WON'T WORK -->
<meta name="manifest" content="{ 'name': 'Example' }">

    This would be very inconsistent with the rest of the platform.

  2. What happens when you have apostrophes within your content? When inlined using the meta element it would have to be escaped, e.g.:

    <meta name='manifest' content='{ "name": "Here\'s an example" }'>

    But that wouldn't be necessary when linking manifests. So copy/pasting from manifests originally written to be linked might end up wrecking havoc when used inline. (This is a situation analogous to closing script tags within inlined JavaScript which is a source of countless bugs).

Using meta elements for each property, e.g.:

<meta name="app-title" content="Example">
<meta name="app-mode" content="standalone">

won't work well for nested or enumerated content (try describing the icons mentioned above, it's hard), and it won't translate easily to a linked format.

Of course, the best option would be to create a manifest element, but that's not possible for legacy reasons (afaik, parsers switch to body content as soon as they find a tag which isn't blessed as that of a child of the head element).

In conclusion, the only reasonable option is to use a script tag for inline content. For linked manifest, using the link element is appealing, but is inconsistent with using the script tag when inline, so I'd probably suggest using script tags for both.

@dret
Copy link

dret commented Dec 5, 2013

regarding "We are trying to create a new manifest format for the Web" in the intro: isn't HTML5 defining just that in http://www.w3.org/TR/html5/browsers.html#offline ?
my guess this is more about the mechanics about how to to make it available? but isn't that also specified in HTML5 already? could somebody please briefly point out how this gist relates to what's specified in HTML5? thanks!

@dret
Copy link

dret commented Dec 5, 2013

if this is only about where to make the manifest available and how, then linking definitely should be the way to go. this way all the REST mechanics can apply: potentially multiple media types (if somebody ever comes up with a different manifest format), and maybe even PATCH formats for manifests if there are huge manifests, and there should be a way how diffs can be communicated. use web architecture as much as possible, and in this case, any solution other than linking seems vastly inferior. define and register a link relation type, and make sure that the linking mechanism does not hardcode the manifest media type to it.

@kevburnsjr
Copy link

Require <link> and allow developers to reference inline manifests using fragment identifiers.

<link rel="manifest" href="#inline-manifest">
<script id="inline-manifest" type="application/manifest+json">
{
  "name": "Example",
  "url": "/start.html",
  "mode": "standalone",
  "icons": [{
      "src": "icon/lowres",
      "density": "1",
      "width": "64",
      "type": "image/webp"
    }, {
      "src": "icon/hd",
      "density": "2",
      "width": "64"
  }]
}
</script>

@CodyErekson
Copy link

I like option B, using <script> tags. Mainly for portability reasons. Being able to easily pull this data into other code with little effort will probably be of enormous value.

@DavidCarcamo
Copy link

external link to a JSON file, please no inline script tag, or JSON in meta tag.

@triblondon
Copy link

I agree with @tobie. We should have options for both external linking and inline embedding of the manifest data, and the only existing tag which gives us that ability in a <head> context is <script>. But, I would be concerned about shifting data for which there are already defined meta tags (as @pornel points out) into the manifest, as developers will then inevitably have to use both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment