4 ms·
If the script were at the top, it would run before any of the rest of the JSON gets inserted into the DOM, so it would (1) not have access to it (unless it sets
by bzbarsky 6y ago
If the script were at the top, it would run before any of the rest of the JSON gets inserted into the DOM, so it would (1) not have access to it (unless it sets up an async callback to do it) and (2) not be able to remove it from the DOM (until that callback runs).
The script might be able to set up mutation observers that notice stuff being added to the DOM and immediately remove it into a buffer the script maintains. This might actually be pretty viable.
> Or actually, you can probably just put some closing angles before the start of your render to make sure you don’t get broken from above.
That won't help with the fact that the data will actually be "corrupted" by the HTML parser. This is why all the HTML inside the JSON in the example is HTML-encoded.
One plausible fix for _that_ is to have a <plaintext> tag right after your <script>. So put the #render as the first thing in the JSON, set up mutation observers in the script, <plaintext> to prevent HTML-parsing of the rest of the doc, and this might be pretty robust to random HTML bits in the JSON data.
- lifthrasiir 6y ago> One plausible fix for _that_ is to have a <plaintext> tag right after your <script>. That seems more plausible since `<plaintext>` can't be closed. In fact mutation observers can be used to get and process the partially downloaded JSON before onload (I'm pretty sure this is possible but haven't tested, YMMV). That would be still horrible as a general solution, but might be actually an interesting solution for more limited situations.