Conversation
foolip
force-pushed
the
foolip/patching
branch
from
0793d49 to
cc8f93c
Compare
Depends on w3c/trusted-types#597 for Trusted Types integration.
foolip
force-pushed
the
foolip/patching
branch
from
cc8f93c to
f1f9151
Compare
foolip
force-pushed
the
foolip/patching
branch
from
97365c8 to
5c6fc51
Compare
source
Outdated
| <ol> | ||
| <li><p><span data-x="concept-node-remove">Remove</span> all <var>target</var>'s <span | ||
| data-x="concept-tree-child">children</span>, in <span>tree order</span>, with the <i>suppress | ||
| observers flag</i> set.</p></li> |
There was a problem hiding this comment.
This flag is currently internal to DOM (and just got renamed).
I also don't see how you are accounting for the suppression by creating your own mutation records. Am I missing something?
There was a problem hiding this comment.
There's actually no good reason to suppress mutation observer here, I tested it for innerHTML in https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=14325 and mutation observer is triggered. I'll remove the flag here.
There was a problem hiding this comment.
You probably have to use the "replace all" algorithm though as I doubt removing the nodes one-by-one gives the record we want here.
source
Outdated
| <li><p>Let <var>disposition</var> be the result of invoking the <span | ||
| data-x="tt-shouldblock">should sink type mismatch violation be blocked by content security | ||
| policy?</span> algorithm given <span>this</span>'s <span>relevant global object</span>, | ||
| "ShadowRoot streamHTMLUnsafe", "script", and "".</p></li> |
source
Outdated
| <ol> | ||
| <li><p>Let <var>input</var> be the result of <span | ||
| data-x="concept-idl-convert">converting</span> <var>chunk</var> to a <code | ||
| data-x="idl-DOMString">DOMString</code>. If this throws an exception, return <span>a promise |
source
Outdated
| data-x="concept-tree-child">children</span>, in <span>tree order</span>, with the <i>suppress | ||
| observers flag</i> set.</p></li> | ||
|
|
||
| <li> <p>Let <var>parser</var> be an <span>HTML parser</span> using the <span>streaming HTML |
There was a problem hiding this comment.
| <li> <p>Let <var>parser</var> be an <span>HTML parser</span> using the <span>streaming HTML | |
| <li><p>Let <var>parser</var> be an <span>HTML parser</span> using the <span>streaming HTML |
| </ul> | ||
|
|
||
| <p class="XXX">Achieve the above by refactoring instead of enumerating the differences.</p> | ||
| </div> |
There was a problem hiding this comment.
Given that a lot of the complexity is here, I was hoping this would have been a bit more flushed out before the stage 2 request. The overall API shape seems fine, but I feel like as we're discussing this feature we keep discovering new issues with the supposedly "straightforward" HTML parser integration and we still don't quite know what that is going to look like.
annevk
left a comment
annevk
left a comment
There was a problem hiding this comment.
I think there's another issue with how this works. Because it operates on the main document, you wouldn't be able to use declarative shadow trees. I think we need to make it work the way we want it to work for the Sanitizer API, minus the actual sanitization.
| data-x="tt-shouldblock">should sink type mismatch violation be blocked by content security | ||
| policy?</span> algorithm given <span>this</span>'s <span>relevant global object</span>, | ||
| "<code data-x="">ShadowRoot streamHTMLUnsafe</code>", "<code data-x="">script</code>", and | ||
| "".</p></li> |
2 participants
Fixes #2142.
(See WHATWG Working Mode: Changes for more details.)
/dynamic-markup-insertion.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/parsing.html ( diff )
/references.html ( diff )