1426224 - Unexpected nesting when assigning non-HTML empty elements to innerHTML

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Adam Katz]

When assigning innerHTML, empty elements (elements that close themselves rather than having a separate closing tag, e.g. `<x/>` vs <x></x>`) are assumed to not be empty, resulting in nesting.

Example (you can run this in your console):

  blah = document.createElement("blah");
  blah.innerHTML=`<one/><two/><three/>`;
  blah.outerHTML;

Expected results:

  "<blah><one/><two/><three/></blah>"

Actual results:

  "<blah><one><two><three></three></two></one></blah>"

These results would also be acceptable:

  "<blah><one></one><two></two><three></three></blah>"

There must be something special about <br> and <img> because this works:

blah = document.createElement("blah");
blah.innerHTML=`<img/><img><br/>`;
blah.outerHTML;

-> "<blah><img><img><br></blah>"

(I expected "<blah><img/><img>/><br/></blah" but this does reinforce the internal knowledge about *specific* empty elements, which I assume should help parsing when missing the trailing slash.)

Experienced on each of these browsers:
  Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
  Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0

Comment 1

[Adam Katz]

Also a bug in Google Blink/Chromium/Chrome:

https://bugs.chromium.org/p/chromium/issues/detail?id=796305

See also this Stack Overflow answer, which uses a loop over each element and cloneNode() to remove children as a workaround (which only works because the input data has a flat format):  https://stackoverflow.com/a/47892283/519360

Comment 2

[Robert Longson [:longsonr]]

https://developer.mozilla.org/en-US/docs/Glossary/Empty_element

Comment 3

[Adam Katz]

As an implementation of XML, shouldn't XHTML be able to parse new empty elements?  If HTML6 were to add a new empty element, shouldn't older parsers be able to recognize it properly without changing the nesting?

Comment 4

[Robert Longson [:longsonr]]

You're not using XML or XHTML here, you're using HTML, HMTL is not XML.

Comment 5

[Robert Longson [:longsonr]]

If html added a new empty element, you are right that old parsers would not parse it correctly.

Comment 6

[Adam Katz]

Attachment: HTML example (this example shows nested elements)

Comment 7

[Adam Katz]

Attachment: HTML example (this example shows nested elements)

Comment 8

[Adam Katz]

Attachment: XHTML example (this example correctly shows flat elements)

I've added two examples.  One that is HTML that exhibits the behavior as previously discussed (assumption of unclosed elements) and one that is XHTML that operates as expected, verifying the earlier comment about HTML vs XHTML.

I've also found https://www.w3.org/TR/custom-elements/ which says:

> Custom elements provide a way for authors to build their own fully-featured
> DOM elements. Although authors could always use non-standard elements in
> their documents, with application-specific behaviour added after the fact by
> scripting or similar, such elements have historically been non-conforming
> and not very functional. By defining a custom element, authors can inform
> the parser how to properly construct an element and how elements of that
> class should react to changes.

Is there a way to instruct the DOM parser about an empty element?
Should there be?

(My use case is parsing XML using ECMAscript run from within a non-XML HTML page.)