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

tl;dr - a few counter points for consideration, but I’m generally ok with adding both the declarative inline alternative and with dropping the arguments on the API in V1. For the declarative solution, we would drop using <link> in favor of <script> entirely.  

On Wednesday, December 4, 2013 at 9:40 AM, Jonas Sicking wrote:
> 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.


I thought this was because <script> and <style> are “this page’s script and style” (i.e., the scope is very specific).  

This is different to the manifest, which is “this loosely grouped set of navigable resources forms a web-app”.  

Also, appcache is a really good counter example of something that doesn’t do this… oh.. wait :)  
  
> 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.

Sure, I can sympathize with that, but the trend and best practice is still not to include things inline (e.g., as per CSP).

I’m not saying we shouldn’t allow it - just sayin’ its kinda crappy because it encourages bad development practices (leading to single page apps, etc.).   

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

Right, but HTTP2 is supposed to erode those differences. Also, in many cases it’s not really necessary to download the manifest at all (because the user may not be on the page long enough to make a decision about bookmarking), so it’s wasted bytes to include them.  
> It seems to me that the same arguments applies to metadata such as
> what's included in the manifest.

Yes.   
> 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?
Absolutely. I personally think there are better ways of dealing with these things, but I’m certainly not adverse to including this.  
> I don't have a strong opinion on if we should use <script
> type=manifest>{ ... }</script>,  

This one is the most sane, IMO. There is precedence for this on the Web.  
> <meta name=manifest content="{ ... }>,
> <link rel=manifest content="{ ... }">,


I think developers will object to the above. If src-n was an abomination to some, then I can’t imagine the above being well received.
     
> <manifest>{ ... }</manifest>


This wouldn’t work… not in the head, at least as it would auto close head so it gets rendered in legacy browsers. See livedomviewer here:
http://tinyurl.com/knbhe3s

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

That would be great. Reading the HTML spec, I think we can.  

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


Sure, enhancing the data in the way allowed by the API as I am proposing is a "nice to have” feature.  

But I’ll note that the same thing you are trying to prevent can be achieved by using the declarative solution, in that the data can by dynamically generated in javascript and inserted into the DOM:

<script>
var app = {name: customName};
manifest = document.createElement(“script”);
manifest.type = “manifest”;
manifest.innerText = JSON.stringify(app);   
document.head.appendChild(manifest);
</script>
  
In other words, it doesn't guarantee the availability of the data (unless we are really mean an disallow dynamic modification of this type of data, but that would be quite developer hostile). So, instead of simply making developers go through all the pain above, allowing the API to take an object saves a bunch of hassle. Having said that, it’s just sugar so I’m ok to drop it… we can add it again later if people want it.  

√

Received on Wednesday, 4 December 2013 05:26:14 UTC