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

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

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