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: Rafael Weinstein <rafaelw@google.com>
Date: Fri, 11 May 2012 11:27:16 -0700
Message-ID: <CABMdHiRhEu9Hyt6+=jXi7O-5HWMY44BLt3H0BBU_JfsWFdwW9A@mail.gmail.com>
To: Scott González <scott.gonzalez@gmail.com>
Cc: Henri Sivonen <hsivonen@iki.fi>, "Tab Atkins Jr." <jackalmage@gmail.com>, Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>
It feels like we're making progress here. It seems as though there are
basically two camps:

1) We shouldn't attempt to solve this problem. E.g. an explicit
context element should be required for fragment parsing.
2) The basic idea of inferring a context element is workable and there
are details to be worked out.

I suggest that we suspend for a bit the question of camp 1 vs 2 and
just focus on the best possible (i.e. mutually agreeable) solution for
camp 2. It goes without saying, that I'd really appreciate feedback in
this direction from folks who are in camp #1 -- I'm looking at you,
Hixie -- even if you hate this idea, you still have to help =-P.

Once we have a complete proposal written down, then we can decide
whether it's worth doing or not.

Now, WRT camp #2, there seem to be three issues to resolve

1) What is done with tokens which precede the first start tag?
2) What is the mechanism (if any) for handling SVG & MathML elements?
3) What is the form of the API (e.g. DocumentFragment.innerHTML,
document.parse(), etc...).

I'm actually encouraged because, while I have preferences WRT the
above, I think all the permutations would solve the use cases we have.

I'll start a new thread whose purpose is to sort out an agreeable
proposal for the behavior of camp #2.

On Fri, May 11, 2012 at 5:39 AM, Scott González
<scott.gonzalez@gmail.com> wrote:
> On Fri, May 11, 2012 at 7:13 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>>
>> However, I'm not strongly opposed to adding innerHTML to
>> DocumentFragment if we also add a method on Document that parses a
>> string using the HTML parser regardless of the HTMLness flag of the
>> document and returns a DocumentFragment (or has an optional extra
>> argument for forcing XML parsing explicitly).
>
>
> Just a side note, but at least parsing XML seems to be fairly sane today. I
> haven't really done any testing around this, but it seems like this would
> get you parsing of arbitrary XML fragments, including leading and trailing
> text nodes:
>
> (new DOMParser).parseFromString( "<x>" + string + "</x>", "text/xml"
> ).documentElement.childNodes
>
> Obviously this is overly verbose compared to document.parse( string, flag ).
Received on Friday, 11 May 2012 18:27:45 GMT

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