搂5.4 of the core defines a scripting context base on the presence of the <script> element in, say, HTML. However, the HTML <script> element is not restricted to active 'scripts', i.e., javascript code. It can hold any type of data: a typical case is schema.org metadata in JSON-LD format.
The HTML spec says of the type attribute:
Omitting the attribute, setting it to the empty string, or setting it to a JavaScript MIME type essence match [...] to be interpreted according to the JavaScript Script top-level production.
which probably gives us the way we should restrict the case when we consider the scripting context: it does not have a type or the value of the type is a JavaScript MIME type essence match.
Agree, but it might be best just to refer to the respective sections of HTML and SVG than wade into defining what is already defined (SVG just refers back to HTML, so it's ultimately just one definition).
Then we don't have to "fix" anything if the respective definitions change for any reason (webassembly?).
Then we don't have to "fix" anything if the respective definitions change for any reason (webassembly?).
If Web Assembly comes to the picture at some point (or other scripting languages, like TypeScript), that is a problem the HTML spec will have to solve. If, as you say, we find the right reference in the HTML/SVG specs to use in EPUB, it remains their problems and not ours :-)
Proposed Solution
Add a statement that HTML data blocks are not scripted content plus a note for SVG which does not define data blocks.
Most helpful comment
Agree, but it might be best just to refer to the respective sections of HTML and SVG than wade into defining what is already defined (SVG just refers back to HTML, so it's ultimately just one definition).
Then we don't have to "fix" anything if the respective definitions change for any reason (webassembly?).