Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected result upgraded plain DOM to custom element instance #166

Closed
JanMiksovsky opened this issue May 29, 2013 · 6 comments
Closed

Comments

@JanMiksovsky
Copy link

The gist at https://gist.github.com/JanMiksovsky/5667061 demonstrates a simple custom element called which surrounds its content with "BEGIN" and "END" markers. The HTML provides three cases of being used. The first and third cases get upgraded by Polymer as expected. The second case case, however, does not get upgraded as expected. This markup:

<p>
    <test-element>
        <div>p holding custom element with content in div</div>
    </test-element>
</p>

produces the DOM:

<p>
    <test-element>
        #document-fragment
            "        "
    </test-element>
    <div>p holding custom element with content in div</div>
</p>

Actual result:
BEGIN END
p holding custom element with content in div

Expected result:
BEGIN
p holding custom element with content in div
END

It appears that the contents of the <test-element> end up under the wrong element (the outer <p> instead of the <test-element>). If the outer <p> is changed to a <div>, things work as expected. Likewise, if the inner <div> is changed to a <span>, things work as expected. The problem appears to arise with an outer <p> and an inner <div>.

@sjmiles
Copy link
Contributor

sjmiles commented May 29, 2013

The P element represents a paragraph. It cannot contain block-level elements (including P itself).

http://www.w3.org/TR/html401/struct/text.html#h-9.3.1

@JanMiksovsky
Copy link
Author

@sjmiles Ah. Weird. Somehow I've coded HTML for years without ever hitting this case and discovering a <p> can't contain elements like divs. Thanks for your patience.

@sjmiles
Copy link
Contributor

sjmiles commented May 30, 2013

Yes it's a bit obscure. Somebody else hit this earlier, which is the reason I knew the answer right away. :)

@JanMiksovsky
Copy link
Author

Wait a second... is the rule that a div isn't ever allowed in a paragraph — or is the rule that this won't be parsed as I'd expected (with a div nested inside a p).

Here's my concern: Suppose I have a custom element that you want to use. My element's shadow may or may not contain a div; you have no idea whether it does or not. You want to use my element in a paragraph. Can you?

In other words, does the presence of a div (or other block-level element) "taint" a custom element, such that it can't ever be used inside a paragraph? That would be pretty unfortunate, as this would effectively leak a detail of the custom element's implementation to consumers.

@JanMiksovsky JanMiksovsky reopened this May 30, 2013
@dfreedm
Copy link
Member

dfreedm commented May 31, 2013

It appears that the rule scott mentioned means that a div won't be parsed as you expected. If you create a div, you can append it as a child of a p.
Also, it appears that ShadowRoots would not "taint" an element that can be in a p.

Here's a JS bin with the findings: http://jsbin.com/uziwug/2/edit

@dfreedm dfreedm closed this as completed May 31, 2013
@JanMiksovsky
Copy link
Author

@azakus Thanks for the experiment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants