Philip Jägenstedt

@johannesodland I never got an update on the bug that I filed. But I'm glad to see the change was made to the spec now!

https://github.com/whatwg/html/pull/11959 shows what the change would look like.

This direction makes sense to me, but I'm not personally able to make a commitment to implement in Chromium. @zcorpan I think you've mentioned this feature, perhaps you have feedback?

That sounds sensible to me, but where in the event handler processing algorithm will you check if scripting is disabled? Browsers have internal event handlers for lots of things, so...

Hmm, scripting is disabled for nodes, and not all event targets are nodes. Is there a document you can check on instead?

If we get the document from window that should work, yes. (Window isn't a Node)

@zcorpan can you take a look at this? I've reviewed it and I think it all makes sense and matches the desired behavior now, but I'm worried there are details...

While refactoring [HTML fragment parsing algorithm](https://html.spec.whatwg.org/#html-fragment-parsing-algorithm) to support `streamHTMLUnsafe()` a few issues have surfaced that I'd like to document here for discussion. ## Inert document vs. document fragment The spec...

I agree, `setHTMLUnsafe()` can't behave like the main parser in this regard while being sync. In order to minimize differences, however, I wonder if the default for both `setHTMLUnsafe()` and...

In https://github.com/whatwg/html/issues/11964 we had consensus to advance this proposal to stage 2, with the specific scope of adding `streamHTMLUnsafe()` and adding the `runScripts` option to both `streamHTMLUnsafe()` and `setHTMLUnsafe()`.