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

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>

> 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 19:40:23 UTC