W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2013

Re: HTML as application manifest format

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Thu, 1 Aug 2013 12:44:19 +0100
Cc: public-webapps@w3.org
Message-Id: <B0CDECF1-AE64-44A9-B371-F72230E49681@gmail.com>
To: Kornel Lesiński <kornel@geekhood.net>
Or you could perhaps use XML. A bit like, er, this:

http://www.w3.org/TR/widgets/

On 18 Jul 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 11:44:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:12 UTC