Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?

On Mon, Dec 9, 2013 at 1:33 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>> > > or
>> > > something else. Like you said, I think it's a conversation we need to
>> > > have with the HTML people.
>> >
>> >
>> > I’ll investigate a bit more. I’ve added a bug here:
>> > https://github.com/w3c/manifest/issues/91
>> >
>> > I’ll just note that having <link rel=manifest> and <script type>
>> > manifest would kinda suck… if we can just have:
>> >
>> > * <script type=“application/manifest+json” src=“manifest.json”></script>
>> > * <script type=“application/manifest+json”>{}</script> that would be
>> > great.
>
> Implementations would probably have to be careful and exclude this kind of
> scripts from the usual script handling (e.g. blocking of the HTML parser,
> triggering the preloader, etc), to reduce the impact on the critical path.

This is a good point. Would this have performance implications for
down-level browsers? I don't know if prescanners etc in contemporary
browsers are smart enough to ignore <script> tags that use a non-JS
type attribute.

> IMO, it might be better not to define an explicit way to inline the
> manifest, and let authors simply use data URIs to do that, if they see such
> a need.
> e.g.  <link rel=manifest href="data:application/manifest+json,{ ... }">
>
> If this becomes a common authoring pattern, an explicit mechanism might be a
> good fit. Otherwise, there may not be a need.

This sounds mostly ok.

The only problem is that we need to figure out how updates works. Once
the user has bookmarked a website, it's important that the website can
update the data that's stored in the manifest. For example that they
can tweak their icon as they slightly change their branding. Or that
they can add that they now need a back-button rendered.

For normal markup like <link rel=manifest href="/manifest.json">, the
way the implementation would do this is by remembering the URL of the
manifest, and at regular intervals reload that URL to see if anything
needs updating.

For a data: URL that obviously doesn't work as the URL will always
return exactly the same manifest.

For an inline manifest, the way to do this would be to use the URL of
the page that contains the manifest. I.e. the UA would at regular
intervals reload the URL that contains the inline manifest, and
extract the updated manifest from that.

That does bring up a important question though. How does a developer
migrate from an inline manifest to an external manifest if the
application grows. I don't think there are clean solutions for that.
You could at that point honor a link to an external manifest. Not
great, but should work pretty intuitively in most cases.

So if we were to use data-URLs, then I think we still would have to
write language into the spec for how to treat those to allow them to
be updated.

All in all though, this is a pretty good argument against internal
manifests in any form.

/ Jonas

Received on Tuesday, 17 December 2013 08:30:19 UTC