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

On Wed, Dec 4, 2013 at 7:16 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Dec 3, 2013 9:25 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:
> > 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”.
>
> Some web-apps are single-page. If they are simple enough I don't see
> anything wrong with that.
>
> > > 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.
>
In terms of performance, even single page Web apps can benefit from keeping
the manifest in an external, long-term cacheable resource, assuming that
the HTML is modified more often than the manifest itself. (hence have a
shorter freshness lifetime)
Inline CSS/script have a performance benefit since they remove a request to
an external resource from the critical path.
A manifest is not in the critical path,and therefore an external resource
can be loaded asynchronously, after all other resources were loaded, and
after the page's onload event. If you add it to the HTML, you force that
data into the critical path, which may have a negative performance impact,
if the manifest not a small one.

> >
> > Sure, I can sympathize with that, but the trend and best practice is
> still not to include things inline (e.g., as per CSP).
>
> CSP is adding new features specifically to support inline CSS/scripts
> since they are so liked by authors.
>
The reason hashes are added to CSP is not because of authoring comfort
(hand writing SHA-1 hashes is not anyone's idea of a good time ;) ), but
because in some cases inline CSS & scripts are critical for performance.

> > 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.).
>
> For simple apps I don't see anything wrong with single-page.
>
> I'd rather spend time on making multi-page experiences good so that
> authors don't avoid it, than try to force it.
>
> I.e. the thing that I think is bad practices is when developers that have
> multi-page UIs use excessively complicated solutions to create a
> single-page implementation. We should improve the web so that they don't
> have to.
>
> I don't think single-page apps is something that is inherently bad.
>
> > > <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.
>
> I think the src-n dislike came from the fact that it tried to use
> something that has always been a dictionary with a limited and defined set
> of keys and tried to use it as an array with an unbounded key set.
>
> That's very different from what we are doing here which is sticking a very
> large value into an attribute.
>
> Personally my vote goes to using <link rel=manifest> for external
> manifests, and <meta name=manifest> for internal manifests. That has a nice
> symmetry and reuses existing elements in a proper way.
>
> And you can put line breaks inside attributes. They don't show up in the
> attribute value but that seems ok here.
>
> And you don't have to escape quotes as long as you use apostrophes as to
> delimit the attribute value. I.e. the following is just fine.
>
> <meta name=manifest content='{
> "a": 1,
> "b": "foopy"
> }'>
>
> > > 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.

> >
> > That would be great. Reading the HTML spec, I think we can.
>
> I prefer link/meta as the above is pretty verbose and a lot to remember.
> And using <link> to link to external manifests just make so much sense.
>
> But I'll defer to you on this.
>
> > 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>
>
> Like I said, I'm not trying to force anyone's hand. There is also
> robots.txt and document.write(). I'm just trying to avoid accidental hiding
> from crawlers.
>
> / Jonas
>

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.