Re: HTML as application manifest format

Hi Kornel,  
Although I have complete empathy about your criticisms regarding JSON, it is actually quite fit for this purpose. Using HTML in the way you describe is kinda problematic, in that it could include scripts and other resources: basically, one would need to build a DOM to parse out the information - and even if scripts where not run, or resources loaded, one would still then need to make a special HTML just for this purpose (which would confuse people, as if you use HTML you expect to be able to have access to features of the platform). We are going to need a custom processor for the JSON format, but at least parsing is already done for us (as it was with XML, though sadly it seems that devs prefer JSON).   

Thanks anyway for the suggestion and for taking time to think about the problem! Hopefully you can continue to help us with the JSON manifest.  

--  
Marcos Caceres


On Thursday, 18 July 2013 at 14:57, Kornel Lesiński wrote:

>  
> I'd like to propose using HTML as basis of manifest format, similar in  
> spirit to Web Components imports, e.g.
>  
> <link rel="manifest import" href="/my-app-definition.html">
>  
> and then my-app-definition.html could contain <link>, <meta> or other  
> elements.
>  
>  
> Rationale:
>  
> * while JSON is wonderful for automatic serialization, it's an annoying  
> format when maintained by hand (and manifest seems static and simple  
> enough to be maintained by hand).
>  
> - JSON syntax is pedantic about trailing comma. Authors have to be  
> careful when adding new element to end of a list.
>  
> - JSON does not support comments. Manifest is a central place of an  
> application, so may end up being modified by many team members, and it's  
> useful to comment why certain properties are the way they are, warn which  
> changes will cause breakage (again…), etc.
>  
> * We already have <link rel=icon sizes>, <meta name="description">, <meta  
> name="application-name"> that can be reused. Authors already know these  
> and it may be easier to define and understand how <meta> and manifest  
> properties interact.
>  
> * We already have lang & hreflang attributes, so there's no need to invent  
> locales dictionaries.
>  
> * It can be inlined naturally, saving a RTT.
>  
> * It can be mixed with Web Components allowing applications to define  
> everything in one place if they wish to.
>  
> * Simple websites can reuse homepage as their manifest file: <link  
> rel=manifest href=/>
>  
>  
>  
> Here's HTMLized example from the spec:
> http://www.w3.org/2012/sysapps/manifest/#example-manifest
>  
> <html lang="en" manifest="/cache.manifest">
> <meta name="name" content="The Example App">
> <meta name="description" content="Exciting Open Web development action!">
> <meta lang="es" name="description" content="¡Acción abierta emocionante  
> del desarrollo del Web!">
> <meta name="launch-path" content="/">
> <meta name="version" content="1.0">
> <link rel="icon" sizes="16" href="/img/icon_16.png">
> <link rel="icon" sizes="48" href="/img/icon_48.png">
> <link rel="icon" sizes="128" href="/img/icon_128.png">
> <meta name="author" content="Foo Corp.">
> <link rel="author" href="http://example.org/dev">
> <link rel="author" hreflang="es" href="https://example.org/dev/es-ES">
> <style>
> @viewport {
> min-width: 300px;
> max-width: 600px;
> }
> </style>
> <meta name="required-features" content="touch geolocation webgl">
> <meta name="permissions:contacts:description" content="Required for  
> auto-completion in the share screen">
> <meta name="permissions:contacts:access" content="read">
> <meta name="fullscreen" content="true">
> <meta name="release_notes:1.0" content="Bugs fixed. New exciting effects.  
> Ready for an official release!">
> <meta name="release_notes:0.5" content="First alpha version with still  
> some bugs but already fun!">
>  
>  
> When writing this I was surprised how well existing functionality fits  
> (and thus how much "NIH" can be avoided).
>  
> The only bit that didn't seem natural fit was <meta> for permissions, so  
> maybe a better element needs to be invented for it:
>  
> <permission for="contacts" access="read">
> <meta name="description" content="Required for…">
> <meta name="description" lang="pl" content="Wymagane do…">
> </permission>
>  
> or perhaps made generic:
>  
> <metagroup name="permissions">
> <metagroup name="contacts">
> <meta name="access" content="read">
> <meta name="description" content="Required for…">
> <meta name="description" lang="pl" content="Wymagane do…">
> </metagroup>
> </metagroup>
>  
> --  
> regards, Kornel

Received on Thursday, 1 August 2013 13:18:02 UTC