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

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

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

I’ll bounce it to HTMLs people and see what they say.

Received on Wednesday, 4 December 2013 07:19:04 UTC