- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Thu, 26 Apr 2012 01:05:28 -0700
- To: public-webapps@w3.org
- Cc: Yehuda Katz <wycats@gmail.com>, Rafael Weinstein <rafaelw@google.com>, Anne van Kesteren <annevk@opera.com>, Ms2ger <ms2ger@gmail.com>, Henri Sivonen <hsivonen@iki.fi>
- Message-ID: <CABNRm601Yqzf-WutQ+HsZMr5tFR2Axny9rr7eW7prmH=4rzSDg@mail.gmail.com>
Anne pointed out to me that Yehuda had already proposed a very similar change to the spec on November 4th, 2011: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694 The only difference appears to be new proposal handles head, body, SVG, and MathML elements. Also, I think Anne convinced me that it's better to deduce the insertion mode from the first element than inventing a new insertion mode (I've asked him to post his reasoning). - Ryosuke 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> > > > 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 Thursday, 26 April 2012 08:06:22 UTC