Re: HTML as application manifest format
I've no experience of the previous XML manifest files but I must admit that I find the arguments for HTML quite persuasive. My default and original position would have been for JSON. I know that I for one will now be more open toward using HTML as a data definition format in my own work. On Tue, Aug 6, 2013 at 6:31 PM, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 01 Aug 2013 17:57:20 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: HTML is the Web's serialization format *for HTML, and other text-like things*. As Kornel's example shows, HTML is *not* well suited to holding key/value pairs or the like; The ugly part is current lack of support for nested groups of metatags, but HTML is pretty good at nesting in general, so this can be fixed easily (I've proposed metagroup and permission in passing). OTOH JSON is by design set in stone, so you can't relax parsing even to fix the merge-conflict-inducing trailing comma, you can't add language attribute to values, you can't add proper comments. Here's a very interesting post about hacking JSON format, motivated by pains of using JSON for configuration: http://fadefade.com/json-comments.html Comments are irrelevant for data serialization/exchange when JSON is spit by software (and this is where JSON shines), but become a necessity in files that humans have to carefully maintain. When files are written by hand (and config files most often are) people can abuse the syntax. The comment hack proposed in aforementioned article makes JSON-with-comments incompatible with ES5 JSON and turns underspecified quirk and implementation detail into de-facto standard. JSON left out comments deliberately to avoid deteriorating by having a hacky extension point, and now a hacky extension point has been found... you have to hack them in via ugly meta values, and you don't get any of the benefit of the rest of HTML, because meta/link *is all you're doing*. Actually, if I could define app's metadata and web components all in one file that would be awesome: link rel=import manifest href=/ (and for added awesomeness I'd make that file my homepage, so I can have self-contained 1-request web app, and subpages that get the manifest and components from the page that is most likely to be cached). This is quite different from Templates, because those are actually leveraging HTML, and so using HTML as the delivery format as well just reduces impedance mismatch. I don't think that applies here. JSON is the way the web does key/value transmission. JSON is fantastic for bare key/value transmission (uncommented, unlocalized automatic data dump), but manifest is not just a basic key/value transmission. Locales tree-patching-dictionary in the spec shows that manifest already has impedance mismatch with JSON data model. -- regards, Kornel
Re: HTML as application manifest format
You could in fact even embed JSON in HTML, like JSON-LD suggests: http://json-ld.org/spec/latest/json-ld/#embedding-json-ld-in-html-documents On 4 August 2013 22:23, Melvin Carvalho melvincarva...@gmail.com wrote: On 1 August 2013 18:57, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Aug 1, 2013 at 9:24 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres w...@marcosc.com wrote: 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). FWIW, I tend to think that Kornel is hitting on something here. Whether we want it or not, HTML is the Web's serialization format. It's the one that helps us understand where hyperlinks are and how resources are interconnected. Having a manifest in that format sounds like a Good Thing. HTML is the Web's serialization format *for HTML, and other text-like things*. As Kornel's example shows, HTML is *not* well suited to holding key/value pairs or the like; you have to hack them in via ugly meta values, and you don't get any of the benefit of the rest of HTML, because meta/link *is all you're doing*. This is quite different from Templates, because those are actually leveraging HTML, and so using HTML as the delivery format as well just reduces impedance mismatch. I don't think that applies here. JSON is the way the web does key/value transmission. It's rather easy these days to embed key value pairs in HTML. 10s if not 100s of millions of sites do it using rdfa, schema.org, open graph protocol etc. The markup need not be ugly Often it's as simple of adding a rel attribute in a tag (the key), and then the value is put inside the tag. ~TJ -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718
Re: HTML as application manifest format
On Thu, 01 Aug 2013 20:24:40 +0400, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres w...@marcosc.com wrote: 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). FWIW, I tend to think that Kornel is hitting on something here. Whether we want it or not, HTML is the Web's serialization format. It's the one that helps us understand where hyperlinks are and how resources are interconnected. Having a manifest in that format sounds like a Good Thing. Hmm. JSON seems to be Mozilla's serialisation format, and is also used in Blink for a bunch of stuff. That said, people have already commented on its drawbacks: - unless you think in data structures or pad it with whitespace everywhere it is hard for humans to read - it's incredibly strict and I don't know of any concrete suggestion that would change that - there is no standard mechanism for comments - nor localisation But for vast numbers of developers meta name=key content=value stuff Is really *really* easy. It gets harder when you want to nest things - you can have meta name=icon content=icon.png but we all know that you really need one of meta name=icon content=icon.png size=12x12 meta name=icon content=icon.png,12,12 meta name=icon content=icon.png maxwidth=12px maxheight=12px or something similar that does complicate the use of meta. As Scott notes, there are in fact a lot of people using the existing widget manifest stuff apparently without tearing their hair out - as well as his list there are Sencha, Blackberry, and other reasonably well-known examples. As Marcos has pointed out elsewhere, it is feasible to relax the XML parsing to work like HTML (Opera Presto does this for XML in general, and has been able to since well before they were working on widgets), which removes the most obvious source of terrible errors. Adding a third way to encode the same semantics isn't obviously the right thing to do, but I think the idea is worth exploring. My take is that the concerns about building DOM and developers being confused are not super-critical. Yeah, I suspect that isn't as big an issue as it seems. HTML Templates produce chunks of DOM that don't run scripts or load resources, and it's unlikely that constructing a DOM tree for the manifest will cause any serious performance concerns. On the other side, if a page defines an application, and the metadata lets you take that application and run it off the page, that seems like a useful thing. From that perspective, the preformance impact of a few meta elements on a running application seems trivial. Browsers will generally be running the app (so for them the separate file is an optimisation, albeit a minimal one), while things like app stores that just parse the metadata are likely to ignore scripts etc. Another problem arises if someone tries to use script to adapt the metadata eg for localisation, and a processor doesn't apply the script - but that's a case of defining use cases, requirements, and specifying what implementations need to do with the information they get. For serious use cases I am pretty sceptical of meta elements. On the other hand I also think JSON is horrible, but there are plenty of developers who love it and want to use it for everything. Frankly I'm far more interested in looking at the approaches people are using and trying to overcome the repetitive NotInventedHere, or at least get the *same* semantics instead of *roughly the same* as we currently have. I think achieving even that limited goal would be a far greater service to developers and therefore to their users than the meagre benefits that have been offered by the slight differences we have managed to build into each system so far. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: HTML as application manifest format
On Thu, 01 Aug 2013 17:57:20 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: HTML is the Web's serialization format *for HTML, and other text-like things*. As Kornel's example shows, HTML is *not* well suited to holding key/value pairs or the like; The ugly part is current lack of support for nested groups of metatags, but HTML is pretty good at nesting in general, so this can be fixed easily (I've proposed metagroup and permission in passing). OTOH JSON is by design set in stone, so you can't relax parsing even to fix the merge-conflict-inducing trailing comma, you can't add language attribute to values, you can't add proper comments. Here's a very interesting post about hacking JSON format, motivated by pains of using JSON for configuration: http://fadefade.com/json-comments.html Comments are irrelevant for data serialization/exchange when JSON is spit by software (and this is where JSON shines), but become a necessity in files that humans have to carefully maintain. When files are written by hand (and config files most often are) people can abuse the syntax. The comment hack proposed in aforementioned article makes JSON-with-comments incompatible with ES5 JSON and turns underspecified quirk and implementation detail into de-facto standard. JSON left out comments deliberately to avoid deteriorating by having a hacky extension point, and now a hacky extension point has been found... you have to hack them in via ugly meta values, and you don't get any of the benefit of the rest of HTML, because meta/link *is all you're doing*. Actually, if I could define app's metadata and web components all in one file that would be awesome: link rel=import manifest href=/ (and for added awesomeness I'd make that file my homepage, so I can have self-contained 1-request web app, and subpages that get the manifest and components from the page that is most likely to be cached). This is quite different from Templates, because those are actually leveraging HTML, and so using HTML as the delivery format as well just reduces impedance mismatch. I don't think that applies here. JSON is the way the web does key/value transmission. JSON is fantastic for bare key/value transmission (uncommented, unlocalized automatic data dump), but manifest is not just a basic key/value transmission. Locales tree-patching-dictionary in the spec shows that manifest already has impedance mismatch with JSON data model. -- regards, Kornel
Re: HTML as application manifest format
On 1 Aug 2013, at 18:29, Kornel Lesiński wrote: On 1 August 2013 12:44:19 Scott Wilson scott.bradley.wil...@gmail.com wrote: Or you could perhaps use XML. A bit like, er, this: http://www.w3.org/TR/widgets/ Hehe ;) I'm trying to address two things: 1. it's been shown ever and over again that developers on the wild web are really bad at working with strict syntax. HTML, XHTML that won't parse with right mime type, even RSS ended up as a soup. Strict manifest will inevitably face the same tension - either single misplaced JSON comma or XML quote will break the app (and frustrate developers) or browsers and other clients will eventually give up again and accept almost-JSON soup that works. HTML already got past that and deals with real-world mess. Let's not tempt JSON5 :) I'm quite happy with JSON, XML and HTML we've never had any real issues with badly-formed Widget manifests. I don't think there have been many broken OpenSocial apps due to markup issues either for that matter. So XML seems OK with most web developers treating metadata documents like any other structured document. JSON on the other hand is a pain to write and fix by hand, even with JsonLint. However, the argument has been strongly put in favour of JSON by our friends at Mozilla, whereas I'm firmly +0 on this one. 2. Pave the cow paths. We already define web apps using meta tags, including bunch of Apple's tags for web apps (added to home screen kind). Meta is a well-understood existing mechanism that works. Everybody building web apps creates and references HTML pages with metatags all the time. Another very important aspect of it is that it lowers the learning curve a lot. You learn how to add one meta (that's the charset, should be mandatory for every dev). You then learn few more metas for favicons, google, viewport, mobile Safari. You copypaste them. *Then* you learn how to create common file, and you do it based on whatever you have working already. Very easy and gradual. I think going with meta tags is a very nice, easy way to get started and builds on existing habits. Another approach is that taken by http://schema.org/ and microdata. In general, pretty much everything in the metadata also turns up somewhere in the app html so between meta and microdata you've probably got most of the metadata covered. However, sometimes you just want the metadata without accessing the app itself. In which case, having a separate format matters. So you're back to square one again! OTOH new format, with new names, new structure, no comments in JSON case, new and annoyingly pedantic syntax and separate file from day 1 is jumping on the deep end. Well, we've had quite a long time to get used to it! Apple Dashboard, Konfabulator, Windows Vista Sidebar, OpenSocial, Opera Widget, Apache Wookie... and we're still seeing implementations of the existing Widget XML spec in all kinds of odd places (vehicle dash, TVs, electronic whiteboards in schools...) The barriers have largely been the major platforms having an attack of NIH, not any inherent technical problems with HTML vs JSON vs XML :) It's trivial for us, experienced developers in this forum, to write JSON manifest, but beginners on the web start with copypaste and very little knowledge (and that's good! That's a low barrier to entry) so reusing their skills and letting them learn in small increments will help them a lot. Also look into the future - if Web Components with link rel=import take off you'll have lots of pages importing HTML of jQuery of components. HTML import might become natural and logical way of extending pages, and JSON may remain the odd exception. -- regards, Kornel PGP.sig Description: This is a digitally signed message part
Re: HTML as application manifest format
On 1 August 2013 18:57, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Aug 1, 2013 at 9:24 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres w...@marcosc.com wrote: 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). FWIW, I tend to think that Kornel is hitting on something here. Whether we want it or not, HTML is the Web's serialization format. It's the one that helps us understand where hyperlinks are and how resources are interconnected. Having a manifest in that format sounds like a Good Thing. HTML is the Web's serialization format *for HTML, and other text-like things*. As Kornel's example shows, HTML is *not* well suited to holding key/value pairs or the like; you have to hack them in via ugly meta values, and you don't get any of the benefit of the rest of HTML, because meta/link *is all you're doing*. This is quite different from Templates, because those are actually leveraging HTML, and so using HTML as the delivery format as well just reduces impedance mismatch. I don't think that applies here. JSON is the way the web does key/value transmission. It's rather easy these days to embed key value pairs in HTML. 10s if not 100s of millions of sites do it using rdfa, schema.org, open graph protocol etc. The markup need not be ugly Often it's as simple of adding a rel attribute in a tag (the key), and then the value is put inside the tag. ~TJ
Re: HTML as application manifest format
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
PGP.sig
Description: This is a digitally signed message part
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
Re: HTML as application manifest format
On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres w...@marcosc.com wrote: 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). FWIW, I tend to think that Kornel is hitting on something here. Whether we want it or not, HTML is the Web's serialization format. It's the one that helps us understand where hyperlinks are and how resources are interconnected. Having a manifest in that format sounds like a Good Thing. My take is that the concerns about building DOM and developers being confused are not super-critical. HTML Templates produce chunks of DOM that don't run scripts or load resources, and it's unlikely that constructing a DOM tree for the manifest will cause any serious performance concerns. Embrace the hyperlinks. They're the Web. :DG
Re: HTML as application manifest format
On Thu, Aug 1, 2013 at 9:24 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres w...@marcosc.com wrote: 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). FWIW, I tend to think that Kornel is hitting on something here. Whether we want it or not, HTML is the Web's serialization format. It's the one that helps us understand where hyperlinks are and how resources are interconnected. Having a manifest in that format sounds like a Good Thing. HTML is the Web's serialization format *for HTML, and other text-like things*. As Kornel's example shows, HTML is *not* well suited to holding key/value pairs or the like; you have to hack them in via ugly meta values, and you don't get any of the benefit of the rest of HTML, because meta/link *is all you're doing*. This is quite different from Templates, because those are actually leveraging HTML, and so using HTML as the delivery format as well just reduces impedance mismatch. I don't think that applies here. JSON is the way the web does key/value transmission. ~TJ
Re: HTML as application manifest format
On 1 August 2013 12:44:19 Scott Wilson scott.bradley.wil...@gmail.com wrote: Or you could perhaps use XML. A bit like, er, this: http://www.w3.org/TR/widgets/ Hehe ;) I'm trying to address two things: 1. it's been shown ever and over again that developers on the wild web are really bad at working with strict syntax. HTML, XHTML that won't parse with right mime type, even RSS ended up as a soup. Strict manifest will inevitably face the same tension - either single misplaced JSON comma or XML quote will break the app (and frustrate developers) or browsers and other clients will eventually give up again and accept almost-JSON soup that works. HTML already got past that and deals with real-world mess. Let's not tempt JSON5 :) 2. Pave the cow paths. We already define web apps using meta tags, including bunch of Apple's tags for web apps (added to home screen kind). Meta is a well-understood existing mechanism that works. Everybody building web apps creates and references HTML pages with metatags all the time. Another very important aspect of it is that it lowers the learning curve a lot. You learn how to add one meta (that's the charset, should be mandatory for every dev). You then learn few more metas for favicons, google, viewport, mobile Safari. You copypaste them. *Then* you learn how to create common file, and you do it based on whatever you have working already. Very easy and gradual. OTOH new format, with new names, new structure, no comments in JSON case, new and annoyingly pedantic syntax and separate file from day 1 is jumping on the deep end. It's trivial for us, experienced developers in this forum, to write JSON manifest, but beginners on the web start with copypaste and very little knowledge (and that's good! That's a low barrier to entry) so reusing their skills and letting them learn in small increments will help them a lot. Also look into the future - if Web Components with link rel=import take off you'll have lots of pages importing HTML of jQuery of components. HTML import might become natural and logical way of extending pages, and JSON may remain the odd exception. -- regards, Kornel
HTML as application manifest format
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
