Re: HTML as application manifest format

On Thu, 01 Aug 2013 20:24:40 +0400, Dimitri Glazkov  
<dglazkov@chromium.org> wrote:

> On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres <w3c@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
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Tuesday, 6 August 2013 16:13:11 UTC