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
