Remove the inert document from the HTML fragment parsing algorithm#11970
Remove the inert document from the HTML fragment parsing algorithm#11970
Conversation
|
This is speculative editing following #11669 (comment) to see what it would mean to remove the inert document from the HTML fragment parsing algorithm. There are two questions, one small and one big. Small: Is it necessary to put something on the stack of open elements to not violate assumptions elsewhere? At least Chromium and WebKit put a Big: What were the side effects of using an inert document that implementations might have achieved in some other way, and that also need to be spec'd? The main reason for exploring this is to pave way for cc @zcorpan |
annevk
left a comment
There was a problem hiding this comment.
I think I agree this is what we need to do, but I don't want to lose sight of the requirements for streamHTML() (and setHTML()) while we do this. For those cases we do still want to create in a separate document (and then maybe mutate) before moving things over.
| data-x="concept-tree-child">children</span>, in <span>tree order</span>.</p></li> | ||
| <li><p><span data-x="concept-node-append">Append</span> the resulting <code>Document</code> | ||
| node's <span>document element</span>'s <span data-x="concept-tree-child">children</span> to | ||
| <var>target</var>, in <span>tree order</span>.</p></li> |
There was a problem hiding this comment.
This will create the wrong mutation records.
| <li><p>Let <var>document</var> be a <code>Document</code> node whose <span | ||
| data-x="concept-document-type">type</span> is "<code data-x="">html</code>".</p></li> | ||
| <li><p>Let <var>parser</var> be a new <span>HTML parser</span> associated with | ||
| <var>context</var>'s <span>node document</span>.</p></li> |
There was a problem hiding this comment.
This seems wrong as this would mean the parser will potentially manipulate that document. Though exactly how this is layered today is unclear.
There was a problem hiding this comment.
Here are the bits that I could find beyond inserting nodes:
- https://html.spec.whatwg.org/multipage/parsing.html#the-initial-insertion-mode (setting the quirks mode)
- https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token (increment and decrement document's throw-on-dynamic-markup-insertion counter)
- https://html.spec.whatwg.org/multipage/parsing.html#the-end (Update the current document readiness to "interactive" and lots of other things)
I'll have to check how implementations deal with these cases.
Do you mean for sanitizer, or are there other reasons to use an intermediate document? My thinking was that we'd integrate the sanitizer into the parser so that it's streaming in order to support |
(See WHATWG Working Mode: Changes for more details.)
/dynamic-markup-insertion.html ( diff )
/parsing.html ( diff )
/xhtml.html ( diff )