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

That would be a major leap forward in the least right?
On Apr 25, 2012 3:41 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>
>
> > 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:05:37 UTC