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

On Dec 3, 2013 11:18 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:
> On Wednesday, December 4, 2013 at 4:16 PM, Jonas Sicking wrote:
>
> > > 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.
>
>
> Sorry, I should have clarified this a bit more. This isn’t about single
page vs multipage apps (of course there will be apps that are single page!)
- it’s about the expectation by browser vendors that apps would be
developed as single page and what we are seeing in the data about single
page apps: When looking at apps that declare “*-mobile-web-app-capable”,
which are supposed to be single page apps by design, we found that very few
apps are actually built as single page.
>
> I haven’t yet published this data in the use cases document, but it’s
pretty clear that developers are adding “*-mobile-web-app-capable” and:
>
> 1. not actually testing what that does (one finds
“*-mobile-web-app-capable” with no <meta viewport>, which means they are
serving a “desktop site” and pretending it’s installable… some of the sites
also lack icons, etc.).
> 2. not actually caring that only the bookmarked page will open full
screen and any clicked link will throw the user back into the Web browser.
> 3. finding it too hard to build their app as a single page app, but
allowing for install-ability regardless (e.g., ESPN, Vanity).
>
> Having said that, there are issues also with navigating installed web
apps. The phonegap guys have a wealth of experience to share here, though
they are proponents of single page apps to overcome limitations in the Web
platform (e.g., avoiding the flash of white when loading another web page
when navigating). Anyway, we can deal with those issues later - but just
want to be clear about what we’ve seen in the dataset we’ve been looking at
in WebMob and what the forthcoming issues are going to be if this goes
mainstream.

I don't see how any of this is related to inline vs external manifests? All
of the problems above seem equally likely to happen no matter where the
manifest lives.

Am I missing something?

Or are you saying that either single-page or multi-page apps should be
discouraged?

> > 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"
> > }'>
>
>
> I really don’t like this - specially messy with the single quote/double
quote thing which is one screws it up is a huge pain in the as to debug.
Structured content really feels like it should be in an element.

Sure, all else being equal I too would prefer to put the structured content
inside an element. Unfortunately all else isn't equal IMHO.

Apart from syntax issues, using <script> also loses us the ability to use a
http header which was a nice benefit.

/ Jonas