« Return to Thread: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

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

by wycats :: Rate this Message:

| View in Thread

jQuery seems to think it buys us something because we have implemented exactly that.

Yehuda Katz
(ph) 718.877.1325

On Wed, Apr 25, 2012 at 2:34 PM, Ryosuke Niwa <rniwa@...> wrote:

I agree. Changing the context element based on the first element is strange and counter-intutitive and doesn't buy us anything.

For example, enforcing the "in table" insertion mode when we encounter td as the first element doesn't guarantee into where this fragment is inserted. In fact, it can be inserted as an immediate child of a shadow root for the component model.

- Ryosuke

On Wed, Apr 25, 2012 at 1:51 PM, Erik Arvidsson <arv@...> wrote:

My concern with the proposal is that it currently requires libraries
to still do a regexp and special case frameset and html.

We should imply the correct context for all tags in HTML5, not matter
if we like them or not. I think it is important that any valid HTML
with one top level node works and results in a firstChild that
directly map to the input.

On Wed, Apr 25, 2012 at 12:39, Rafael Weinstein <rafaelw@...> wrote:
>> frag.innerHTML = "<frameset></frameset>a"

The context for this should be HTMLHtmlElement

<frameset>


"a" gets dropped because it not valid as a child of <html>

>> frag.innerHTML = "<html><body>foo</html>bar<tr></tr>"

"root" context

<html>
<head>
<body>

foobar

>> frag.innerHTML = "<html><body>foo</html><tr></tr>"

<html>
<head>
<body>
foo

--
erik

« Return to Thread: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML