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: Wed, 25 Apr 2012 13:30:13 -0700
Message-ID: <CABMdHiRmnu7b+2zMNwF5-Lk6PPg6d2zmBTSrO3mGExmc42zsqA@mail.gmail.com>
To: Ryosuke Niwa <rniwa@webkit.org>, Yehuda Katz <wycats@gmail.com>
Cc: Webapps WG <public-webapps@w3.org>
On Wed, Apr 25, 2012 at 12:39 PM, Rafael Weinstein <rafaelw@google.com> wrote:
> Ok, so from the thread that Yehuda started last year,
>
> There seem to be three issues:
>
> 1) Interop (e.g. WRT IE)
> 2) Defining the behavior for all elements
> 3) HTML vs SVG vs MathML
>
> I think what Yehuda outlined earlier is basically right, and I have a
> proposal which accomplishes everything he wants in a different way and
> also addresses the three concerns above. My approach here is to not
> let perfect be the enemy of good.
>
> DocumentFragment.innerHTML has the following behavior. It picks an
> *implied context element* based on the tagName of the first start tag
> token which appears in the html provided. It then operates per the
> "fragment case" of the spec, using the implied context element as the
> "context element".
>
> Here's the approach for picking the implied context element:
>
> Let the first start tag token imply the context element. The start tag
> => implied context element is as follows:
>
> caption, colgroup, thead, tbody, tfoot => HTMLTableElement
> tr => HTMLTableBodyElement
> col => HTMLColGroupElement
> td, th => HTMLTableRowElement
> head, body => HTMLHTMLElement
> rp, rt => HTMLRubyElement
> Any other HTML tagName => HTMLBodyElement
> Any other SVG tagName => SVGElement
> Any other MathML tagName => MathElement
> Any other tagName => HTMLBodyElement
>
> Note a few things about this:
>
> *Because this is basically a pre-processing step to the existing
> fragment case, the changes to the parser spec are purely additive (no
> new insertion modes or other parser changes needed).
>
> *It addresses (1) by only adding new parsing behavior to new API
> (implicitly retaining compat)
>
> *It explains (2)
>
> *The only problem with (3) is the SVG style, script, a & font tags.
> Here HTML wins and I think that's fine. This problem is inherent to
> the SVG 1.1 spec and we shouldn't let it wreak more havoc on HTML.
>
> *This doesn't attempt to do anything clever with sequences of markup
> that contain conflicting top-level nodes (e.g. df.innerHTML =
> '<td>Foo</td><g></g>';). There's nothing clever to be done, and IMO,
> attempting to be clever is a mistake.
>
>
> Here's how some of the examples from the previous thread would be
> parsed. I've tested these by simply inspecting the output of innerHTML
> applied to the "implied context" element from the example.
>
> On Thu, Nov 10, 2011 at 3:43 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> What about SVG and MathML elements?
>>
>> I totally sympathize that this is a problem with <tr>, but developing
>> a complete solution that works sensibly even when you do stuff like
>> frag.innerHTML = "<head></head>"
>
> <head>
> <body>
>
>> frag.innerHTML = "<head><div></div></head>"
>
> <head>
> <body>
>  <div>
>
>> frag.innerHTML = "<frameset></frameset>a<!-- b -->"
>
> "a"
> <!-- b -->
>
>> frag.innerHTML = "<html><body>foo</html>bar<tr></tr>"
>
> foobar
>
>> frag.innerHTML = "<html><body>foo</html><tr></tr>"
>
> foo
>
>> frag.innerHTML = "<div></div><tr></tr>"
>
> <div>
>
>> frag.innerHTML = "<tr></tr><div></div>"
>
> <tbody>
>  <tr>
> <div>

Sorry, this should have been just

<tr>

>
>> frag.innerHTML = "<g><path/></g>"
>
> <g>
>  <path>
>
> [Note that innerHTML doesn't work presently on SVGElements in WebKit
> or Gecko, but this last example would result if it did]
>
>
> On Tue, Apr 24, 2012 at 5:26 AM, Rafael Weinstein <rafaelw@google.com> wrote:
>> No, I hadn't. Let me digest this thread. Much of what I'm implicitly
>> asking has already been discussed. I'll repost if I have anything to
>> add here. Apologies for the noise.
>>
>> On Mon, Apr 23, 2012 at 10:32 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
>>> Have you looked
>>> at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ?
>>>
>>> On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein <rafaelw@google.com>
>>> wrote:
>>>>
>>>> The main points of contention in the discussion about the template element
>>>> are
>>>>
>>>> 1) By what mechanism are its content elements 'inert'
>>>> 2) Do template contents reside in the document, or outside of it
>>>>
>>>> What doesn't appear to be controversial is the parser changes which
>>>> would allow the template element to have arbitrary top-level content
>>>> elements.
>>>>
>>>> I'd like to propose that we add DocumentFragment.innerHTML which
>>>> parses markup into elements without a context element. This has come
>>>> up in the past, and is in itself a useful feature. The problem it
>>>> solves is allowing templating systems to create DOM from markup
>>>> without having to "sniff" the content and only innerHTML on an
>>>> appropriate parent element (Yehuda can speak more to this).
>>>>
>>>> The parser changes required for this are a subset of the changes that
>>>> Dimitri uncovered here:
>>>>
>>>> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html
>>>>
>>>> And I've uploaded a webkit patch which implements them here:
>>>>
>>>> https://bugs.webkit.org/show_bug.cgi?id=84646
>>>>
>>>> I'm hoping this is a sensible way to make progress. Thoughts?
>>>>
>>>
Received on Wednesday, 25 April 2012 20:30:42 GMT

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