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

On Tue, Dec 3, 2013 at 2:18 PM, Marcos Caceres <w3c@marcosc.com> wrote:
>> > Would it suffice to use the API? It’s much simpler than trying to write out JSON by hand and wouldn’t require us to create any new special script type, etc.
>> >
>> > <script>
>> > if(“requestBookmark” in navigator){
>> >
>> > var appDetails = {name: “Awesome app!”, mode: “standalone”};
>> > navigator.requestBookmark(appDetails).then(happy,sad);
>> > }
>> > </script>
>>
>>
>> I don't think so. That wouldn't let search engines find it. It also
>> wouldn't let us hook it up to the bookmark menu unless the page always
>> calls requestBookmark very early in the page load sequence at all
>> times.
>
> Right, but the search engine use case is what <link rel=“manifest” href=“foo.json"> is for.

I think we might be talking past each other.

We currently have both <script>...</script> and <script src="...">, as
well as both <style>...</style> and <style src>. A big reason we have
both is for author convenience.

If you have a script or CSS resource that is shared between lots of
pages then it's convenient to allow the script/CSS to live in an
external file such that you can just change it once to have the change
applied to everyone that links to it.

But if you have a script/CSS which is very specific to a single page,
then it's very annoying to have to create a separate file that lives
side-by-side with your HTML file and whenever you make a change to
your HTML which requires a change in the script/CSS also open and
change the external file. It also means that if you move/backup/email
your HTML, you have to remember to include the script/CSS file. Hence
we allow script/CSS to live inline inside the HTML.

There are performance benefits to allowing both as well. With an
external script/CSS the script/CSS can be cached and not have to be
downloaded with every HTML file that uses them. But if only a single
HTML file uses the script/CSS then the extra network roundtrip
involved with fetching another resource can be saved by including the
script/CSS inline.

It seems to me that the same arguments applies to metadata such as
what's included in the manifest.

If you have a big "app" consisting of multiple HTML files then having
them all link to an external manifest makes a lot of sense. That way
you only need to change a single location when you want to change
something and the risk of the different pages of your app getting
out-of-sync is reduced.

However if your "app" is very simple and just consists of a single
HTML page, then forcing that HTML to link to an external resource is
just annoying for the developer. By allowing the manifest to live
inside the HTML it makes maintaining the manifest easier and the
developer is less likely to forget to do so. This also simplifies
creating tutorials and filing bugs since you can create single-file
examples.

Does this explain the use case better?

I don't have a strong opinion on if we should use <script
type=manifest>{ ... }</script>, <meta name=manifest content="{ ... }>,
<link rel=manifest content="{ ... }">, <manifest>{ ... }</manifest> or
something else. Like you said, I think it's a conversation we need to
have with the HTML people.

As for the API, I generally don't like the idea of having a script API
which allows passing a full manifest constructed in JS to the UA as
part of the API. That solution discourages finding manifests using
search engines which effectively hides critical metadata. While I
don't want to *force* developers to expose metadata to search engines,
I want to try to avoid that happening accidentally since this metadata
seems extraordinary useful when indexing the web.

So while I'm happy to have the requestBookmark API, I think that
calling registerBookmark should always use the metadata in the DOM. We
could even force it to refer to the markup that was initially loaded
when the page was parsed, but I think that would be too confusing.

/ Jonas

Received on Tuesday, 3 December 2013 23:41:36 UTC