| 18:30 | <domfarolino> | Does a DocumentFragment contain a "Document" object? |
| 18:33 | <domfarolino> | What I'm trying find out is: if you have a script inside a template element, what's the script's "parser document"? The outer document? Or is there another parser created for the DocumentFragment, that parses the script element? |
| 18:59 | <Domenic> | Great question... |
| 18:59 | <Domenic> | <template>s all share a separate no-browsing context document |
| 18:59 | <Domenic> | But I think the parser still operates on the main document... let's see... |
| 19:00 | <Domenic> | Ah, "Set the element's parser document to the Document", not a lot of precision there... :-/ |
| 19:02 | <Domenic> | domfarolino: My read of the spec is that the parser document is the outer document. All the handling of the template contents and template contents owner document seems to happen at insertion (in https://html.spec.whatwg.org/#appropriate-place-for-inserting-a-node), whereas setting the "parser document" seems to happen at element creation. |
| 19:03 | <domfarolino> | Domenic: https://bugs.chromium.org/p/chromium/issues/detail?id=1070667 |
| 19:03 | <domfarolino> | This bug seems to want to change what the parser document will be, if I'm reading it correctly |
| 19:04 | <Domenic> | Hmm hmm |
| 19:04 | <domfarolino> | > My read of the spec is that the parser document is the outer document. |
| 19:04 | <domfarolino> | I agree, that's how the spec reads currently it seems |
| 19:05 | <domfarolino> | Yeah, Chrome seems to have this OwnerDocumentForCurrentNode() retargeting mechanism that mason seems at least interested in introducing to the spec (though no issues about it are filed under his name) |
| 19:05 | <Domenic> | I'd be curious to see what tests say about cross-browser behavior here, both for the case he's mentioning, and the script case. |
| 19:06 | <Domenic> | My guess (not digging in too deeply) is that for the case he's mentioning Chrome is correct, and any other behavior would be bad. So the spec needs updating. But the implications of that for the script case might not be correct. |
| 19:07 | <Domenic> | Hmm, maybe not though, he might be wrong |
| 19:07 | <Domenic> | I think in particular if we changed it in the way he suggests then custom elements would not work inside <template>s |
| 19:07 | <Domenic> | Hmm which is maybe... correct? Weekend brain... |
| 19:10 | <domfarolino> | (brb code searching to try and figure out the exact implications on scripts that move documents) |
| 19:35 | <domfarolino> | Domenic: OK, I don't believe there's any consequence to scripts moved from templates => outer doc. When #prepare-a-script is initially entered for those scripts, they're not run because they're not connected. So #prepare-a-script returns early, removing the "parser document" from the script. Later when the script becomes connected, the "parser document" is never consulted in #prepare, because it is null |
| 19:36 | <Domenic> | Nice, that makes sense to me |
| 19:36 | <domfarolino> | As an aside, I have a CL a brewing for the tests Chrome fails in https://wpt.fyi/results/html/semantics/scripting-1/the-script-element/moving-between-documents?label=experimental&label=master&aligned |
| 19:38 | <Domenic> | Oh sweet |
| 22:07 | <alystair> | Why does insertAdjacentElement return the resulting element, yet insertAdjacentHTML doesn't have a return value? Sensibly it should return a NodeList. Has this ever been discussed? |