`createContextualFragment`: implementations preload images, spec doesn't.

[noamr]

What is the issue with the HTML Standard?

The following line has a different behaviour in the spec vs. implementation:

new Range().createContextualFragment('<img src="something.png">');

Based on the current spec, something.png should not be fetched, because the image is created in a separate document.
However, both Gecko, WebKit and chromium don't implement the inert document thing, making it so that there is a fetch call to something.png.

Should we:
a. Update the spec to reflect reality
b. Update reality to reflect the spec
c. Do (a) first and (b) after

[annevk]

I'm not sure I understand what c) means. a) seem okay though.

[noamr]

I'm not sure I understand what c) means. a) seem okay though.

(c) means to think about changing this behavior,
but only after we align the spec to reality.

[annevk]

Unless there's some kind of overarching reason I'm not aware of I don't think it's worth changing the behavior of legacy parser APIs from what is deployed.

We should think about it again though for setHTMLUnsafe() (if it's similarly impacted) and setHTML() (and streaming counterparts), but I suspect only doing "inert" for the "safe" variants is fine.

[noamr]

Unless there's some kind of overarching reason I'm not aware of I don't think it's worth changing the behavior of legacy parser APIs from what is deployed.

We should think about it again though for setHTMLUnsafe() (if it's similarly impacted) and setHTML() (and streaming counterparts), but I suspect only doing "inert" for the "safe" variants is fine.

See #11669 (comment)

The inert document is needed whenever there is a sanitizer, because the sanitizer might remove images also when unsafe.
Though we can also say that we're ok with this side effect with the unsafe+sanitizer variant.

[annevk]

Thanks, that does seem like a compelling argument for looking into b) or possibly a) but different behavior for setHTMLUnsafe() and possibly some kind of toggle to configure this. Hmm.

[noamr]

Thanks, that does seem like a compelling argument for looking into b) or possibly a) but different behavior for setHTMLUnsafe() and possibly some kind of toggle to configure this. Hmm.

Isn't the existence of the sanitizer a good enough toggle?
Alternatively, always use the inert document when creating elements by the parser, except for createContextualFragment (this only takes effect when the element is created).

In the recent blink fix for this, the inert document used for templates is reused by the sanitizer.

[annevk]

We don't want a no-op sanitizer to suddenly start having side effects.

[noamr]

We don't want a no-op sanitizer to suddenly start having side effects.

I meant the reverse, the sanitizer being a toggle to use an inert document, and having no sanitizer an indication that we can use the target document directly to create elements.

[annevk]

I know, and I don't think there should be a difference between no sanitizer and a no-op sanitizer.

[noamr]

I know, and I don't think there should be a difference between no sanitizer and a no-op sanitizer.

I don't see the reasoning but I don't have strong opinions one way or the other.

One thing we can do is make everything use the inert creation time document and for now put a note that createContextualFragment behaves differently in implementations or have a special step for it that loads images, like it does with scripts today.