W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 9 May 2012 12:10:27 +0300
Message-ID: <CAJQvAudczSkqB-bq6BpL=TpYkstw92np3dDOMBw+htQM9uPH+A@mail.gmail.com>
To: public-webapps@w3.org
On Wed, May 9, 2012 at 11:39 AM, James Graham <jgraham@opera.com> wrote:
> document.parse(string, ["auto"|"html"|"svg"|"mathml"|"xml"])

Makes sense at least for the options other than "auto".

> With "auto" being the default and doing magic, and the other options
> allowing one to disable the magic.

I worry about introducing magic into APIs.  It starts with good
intentions but can lead to regrettable results.

For MathML, if the parser contains a list of all MathML elements, the
magic can work at any point in time if the parser and the input are
from the same point in time but will fail if the parser is older
vintage than the input given to it.  ("image" can be treated as MathML
here, since presumably the magic "image" is only needed for parsing
legacy HTML pages.) Are we OK with the incorrect behavior when the
input and the parser are of different vintage? (Note that the full
document HTML parsing algorithm only has this problem for camel case
SVG elements, which is a non-problem if the SVG working group can
refrain from introducing more camel case elements.)

With SVG, there's the problem that <a> is common and ambiguous.  It
seems bad to introduce an API that does reliable magic for almost
everything but is unreliable for one common thing.  Solving this
problem with lookahead would be bad, because it would be surprising
for <a> in <a></a> and <a> in <a><path/></a> to mean different things.
 Solving this problem with chameleon namespaces would introduce worse
problems.

I don't see any good way to solve the contextless <a> vs. <a> problem
with magic.  (If SVG moves away from xlink:href, we can't even use
attributes to disambiguate.)

If we end up doing (flawed) list-based magic, we need to make sure the
SVG working group is on board and henceforth avoids local name
collisions with HTML and MathML.

If the API required the caller to request SVG explicitly, would it be
a sure thing that jQuery would build magic heuristics on the library
side?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 9 May 2012 09:11:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT