Initialization might fail when surrounded by p-element

[ItsAsbreuk]

This is a strange issue that we've encountered during development of our own custom elements (non x-tags, sorry).

Yet, it also seems to hit the x-tags - from a quick investigation.

The issue seems to be: Whenever a customelement is wrapped inside a p-element, the dom seems to do a miscalculation on some child-elements. That is: some childNodes might be missing.

The effect can be seen at the flipbox-demo, when you wrap both flipboxes inside a p-element. The result is that the first still works, but the second doesn't. It has to do with the presents of the div-element - as far as i can see.

I made a small jsbin to show when the dom fails to see some child-elements --> look at the console to find out that the 3th element seems to be empty.

Even though i'm not using x-tags, it would be great if you guys know what's going on and find a solution.

Thx,

Marco Asbreuk

[csuwildcat]

It almost looks like a browser bug.

[ItsAsbreuk]

It does look like indeed. But isn't: if you try your example (and wrap it with p), you'll see the second flipbox fail. The same for the jsbin.

FYI, my system: OS-X 10.10.2 browsers tested: Safari 8.0.3 FF 35.0.1 Opera 27.0 Chrome 40.0.2214.111 Chrome 42.0.2297.0 canary

[ItsAsbreuk]

and, what makes it even more weird: it depends on what type of child-element is within: not all fail... div does and fieldset fails. And when it encounters an unprocessable element, the rest of the content is disregarded. So, you could end up with a "partial" inner-content

[ItsAsbreuk]

my best bet would be not to see it as a bug that has to be repaired, but to find a way to be able to read the innercontent, even in these situations.

[ItsAsbreuk]

sorry, not mentioned right: it sure looks like a browser-bug of coarse. but all browsers seem to behave the same

[ItsAsbreuk]

I see this as a huge problem. Because we cannot predict how/where users are going to place the custom elements.

I like the principle of being able to write html-markup inside a custom-element which will be processed. The only predictable way (and workable, though less than it was before), is by allowing only comment-nodes inside a custom element.

I'm considering to use this principle for our custom elements. Related to flipbox, it would mean something like this:

<p>
<x-flipbox><!--
      <div><h1>Front</h1></div>
      <div><h1>Back</h1></div>
--> </x-flipbox>
</p>

We use a html-parser to create nodes from a string, thus we can transform the content of the commentnode into dom-nodes, which can be processed further.

[ItsAsbreuk]

I also posted the issue at Polymer: https://github.com/Polymer/polymer/issues/1180#issuecomment-75794009

So we know what makes it happen: it's up to x-tag if/how to deal with it.

I'll close the issue.