Bug 25398 – throw a DOM hierarchy error on appending a plaintext element into an HTML document

• Component: DOM
• Status: RESOLVED INVALID

[Eli Grey (:sephr)]

I recommend that an error be thrown when document.createElement("plaintext") is
run. It is impossible to append a <plaintext> tag into a document without
messing up everything. Firefox actually ends it and puts a </plaintext> tag at
the end (this will do nothing if you made it with innerHTML) which should just
add the content, "</plaintext>", to the tag's text and not end it, as the end
of the document is a <plaintext>'s "ending tag".

I have never seen any scripts that progmatically create plaintext tags so it
would be best to throw an error. Under the unlikely chance that there is an
important website that actually does this, then just remove the ending tag from
the output and make it's textContent be everything after it. Appending more
elements to the documentElement should then just add to the plaintext element's
textContent.

Every other browser does the same but that doesn't mean that it makes any sense
to do so.

Reproducible: Always

Steps to Reproduce:
1. document.documentElement.appendChild(document.createElement("plaintext"))
2.
document.documentElement.appendChild(document.createElement("div")).innerHTML =
"<em>This shouldn't have emphasis (but it does).</em>"



Workaround: Use <pre> or <blockcode> (only use <blockcode> in XHTML2).

[Eli Grey (:sephr)]

Created attachment 29790 [details]
testcase

[Simon Pieters (:zcorpan)]

Throwing would be a violation of DOM Core.

I don't understand what the problem is with creating a plaintext element. It's similar to having <plaintext/> in XML.

[Eli Grey (:sephr)]

(In reply to comment #2)

Well in an HTML (not XHTML) document, it should at least not have an ending tag as there is no such thing as an ending tag for <plaintext/> as an ending tag would just become part of the single text node that is inside <plaintext> element. As you can see in the testcase, a plaintext element shows that the ending tag is generated yet disregarded unless used directly or with innerHTML. The act of inserting a plaintext element into a document should make any elements after it only be inserted as text nodes of their outer HTML.

How about document.createElement("plaintext") doesn't throw an error but trying to append it anywhere in the document throws a DOM hierarchy error?

[Alexey Proskuryakov]

The plaintext element is deprecated ("entirely obsolete, and must not be used by authors", as HTML5 puts it). It's only natural that its interaction with newer Web platform features like dynamic DOM tree manipulation can cause weird and nonsensical results.

Some situations where we'd need to pay more attention to obsolete features are when these are commonly used in actual Web pages, or when they are causing security issues. Neither seems to be the case here, so there is no need for us to change WebKit behavior.

Finally, we seem to perfectly match HTML5 here - both parsing and DOM requirements (the latter being "user agents must treat plaintext elements in a manner equivalent to pre elements").

[Eli Grey (:sephr)]

(In reply to comment #4)
> both *parsing* and DOM requirements

So would that mean that <plaintext> should support ending tags or am I reading this all wrong?

[Alexey Proskuryakov]

My understanding is that per the spec, there is no round-trip fidelity when serializing a DOM that has a plaintext element dynamically inserted into it - serializer will insert a closing tag, but parser will ignore it, and stay in PLAINTEXT mode until the very end of input stream. As long as you don't serialize or parse, plaintext behaves just like a pre element would.