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

On Wed, 04 Dec 2013 08:18:31 +0100, 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.
[...]
> 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.
[...]
> 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.

Looking forward to you publishing that data. Is there a simple pointer for  
those of us who haven't been following webmob closely so we can start from  
somewhere better than "all of webmob"?

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

Indeed.

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

Yes, but I wonder how big a real problem that is. I happen to use a  
bare-bones version of vi that doesn't balance parentheses, quotes, etc,  
but I believe that shows I am a very strange person. As far as I know,  
debugging this kind of error semi-automatically is actually pretty  
trivial, and common.

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

 From an authoring perspective I don't think the verbosity is a big issue,  
and the two options *seem* about equivalent in cognitive load - switching  
elements is odd but people are clearly used to doing it for style, and  
setting a type attribute in a script element compared to using link/meta  
is the same thing.

Which makes the big question about taste in syntax (unless there is some  
real implementation or web-compat issue). So I expect it to be the hardest  
one of all to solve :)

cheers

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Wednesday, 4 December 2013 10:11:10 UTC