Re: Fall back strategy for manifest

Asking Jonas to comment, as he has a different way of looking at the problem.   

On Tuesday, February 4, 2014 at 5:35 PM, Marcos Caceres wrote:

> 
> 
> On Tuesday, February 4, 2014 at 4:26 PM, Robin Berjon wrote:
> 
> > On 04/02/2014 12:12 , Marcos Caceres wrote:
> > > Yeah, of course there it sounds silly. But there are already multiple
> > > ways to provide the application's name (e.g.,
> > > "apple-mobile-web-app-title") - the manifest adds yet another.
> > > (...)
> > > Maybe, but I don't see how else to prollyfill this - particularly for
> > > icons (see [1], icons is crazy proprietary town!)? I was actually
> > > going to build the above to show how the manifest can be used to
> > > target any browser that supports "add to home screen" (by just
> > > converting the manifest members into their proprietary
> > > equivalents)... I thought it was a good idea and not very contrived
> > > :(
> > 
> > 
> > 
> > 
> > Maybe I'm being thick but taking a static resource and using it to add 
> > static information to another static resource doesn't strike me as a 
> > great use for a polyfill! 
> 
> 
> 
> Correct. But, without it all legacy user agents and non-supporting browsers would not get an application-name or the icons. This goes directly back to Kenneth's claims [1] that at least some developers want to put this metadata in a JSON document outside of HTML. 
> 
> Now you are seeing the problem I'm trying to highlight and why I started this thread in the first place: we are taking stuff we copied from HTML and putting it into JSON ... only to shove it back into HTML(!). That feels really wrong to me and it appears you agree. 
> > You're sending a scripts that detects if 
> > manifests are supported, if not downloads the manifest, parses it, uses 
> > that information to add meta... hasn't the user left your site by then?
> 
> 
> 
> That's a risk and could be a real problem with relying on a manifest + polyfill instead of inserting this stuff directly into the HTML. 
> > 
> > What happens if it immediately strikes me as wonderful and I immediately 
> > bookmark it before your script has run? What happens if I'm an old 
> > school crawler?
> 
> 
> 
> Again, these are *exactly* the problems with replicating the HTML metadata in the manifest instead of just using the HTML: putting the metadata into the manifest is basically giving the middle-finger to legacy user agents and any other application that consumes HTML but knows nothing about manifests. 
> 
> My question to the TAG is (and not to Robin): is it ok for manifest to replicate functionality from HTML when it is demonstrable that it could lead to excluding support for legacy user agents and non-supporting applications? I'm here asking the TAG for guidance because I need your help convincing implementers of the manifest spec that replicating functionality already provided by HTML is a bad idea. 
> 
> I, of course, could be wrong - and Kenneth presented strong counter arguments in [1]. The TAG's guidance would be really appreciated to help settle this matter (and so I can finish the spec:)). 
> > It really looks to me like you want a build step, or failing that 
> > server-side generation.
> 
> 
> 
> Yes. Which again highlights why including "name" and "icons" in the manifest doesn't seem like a good idea. Again, I'm asking for guidance here specifically about "name" and "icons" (and not the other stuff that is in the manifest but not in HTML). 
> 
> [1] http://lists.w3.org/Archives/Public/www-tag/2014Jan/0154.html

Received on Thursday, 6 February 2014 01:00:22 UTC