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 , 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 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.
Yes, from an implementation perspective yes. But in the RICG, from web
developer perspective, it was more about the strange use of the attribute.
> 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 for external manifests,
> and 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.
>
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.
>
> > > 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 and manifest
> > would kinda suck… if we can just have:
> >
> > *