I remain ambivalent here. This feels like we are encroaching on HTML by allowing non-Javascript scripts, which really should be up to that spec. It is also confusing, in that we are allowing things that are currently forbidden, so it would give me pause when reading - I would end up questioning my understanding of the text. The only reason I can think of for allowing this is to let things like WASM be referenced using a polyfill, which I guess is handy? But also seems somewhat niche. @iherman I think this is something you wanted - what do you think?

The html spec already mentions you can reference external css and json module scripts from the element, but the latter wouldn't currently be allowed. If we want to make sure we stay within the bounds of the html spec, could we just make that a qualifier:

Any resource [html] allows the script element to reference is an exempt resource.

(I think it might be helpful to rework the core media type references in all these definitions, like maybe putting a single note before the list that these exemptions are in addition to them.)

I like this a lot better - it defers everything to html. The old wording felt very much like "you could if you could, but you can't so you can't".

I like the proposed text, but shouldn't it say

Any resource [html] allows the script element to reference that is nota core media type is an exempt resource.

But, in general, deferring to the HTML (or other spec) is a good idea...

that is nota core media type

That was the parenthesis I had below the suggested text. I find stating this makes reading the exemptions more confusing than they need to be, since core media types are just explicit exemptions from fallbacks by media type. If you don't know the details, it can leave you wondering why core media types aren't exempt from fallbacks.

I think a general note before the list that these exemption are in addition to any core media type designations would serve the same purpose.

This is perhaps more clear, but I think it remains too broad. For instance, this means that all style content is an exempt resource, as is all content reference by style sheets (e.g. a background image referenced from CSS does not need to be a core media type, nor does it need a fallback). Is this really what the WG intended when we made this change? And if it is, I think we should be clear about that.

The original goal was to not flag resources harmlessly travelling in the container as having to meet core media type fallback requirements. It then morphed into also using these for scripts. The part of about exempting foreign resources was a convenient side effect when we were mapping out the resource types.

What if we go the rendering route instead of focusing on the methods? So something like:

it is not directly rendered in its native format in an EPUB content document

A data file used by a script to write to canvas, or an image added to the dom with a fallback, would be fine. As would wasm files.

But it wouldn't work for static content like images referenced from styles rules as they'd attempt to present the image in whatever format it's in.

It would also keep the foreign resource exemption stuff intact.

Yeah, this matches my intuitive feeling for embedded in this context, and feels like it captures the intent better. I would support this wording.

Although... someone may trick the system. Say I have an image in jpg and, for whatever reason, I want it to be treated as an exemption. I then include a jpg->png transformation somewhere, which is used to render the image. Ie, the jpg image is not rendered in its native format, therefore it is an exemption...

Maybe

It cannot be directly rendered in its native format in an EPUB content document

Say I have an image in jpg and, for whatever reason, I want it to be treated as an exemption.

But a jpeg is already a core media type so it shouldn't need an exemption to travel in the container. It's not going to get flagged as a foreign resource without a fallback, which is what happens when you list these non-cmt data files in the manifest.

Epubcheck might warn you that you appear to have an unused publication resource, but that's only a usage message so it's not a problem for publishing.

It cannot be directly rendered in its native format in an EPUB content document

There's a lot of stuff that will render inside an iframe. Wouldn't this exclude json, xml, etc.?

There's a lot of stuff that will render inside an iframe. Wouldn't this exclude json, xml, etc.?

But those are not rendered "natively" but through a transformation process. It is not in the default rendering engine's capability to render them. So they would be covered as well.

But those are not rendered "natively" but through a transformation process.

I'm not sure I follow. What do you mean by a transformation process? If I reference a json or xml file from the src attribute of an iframe, that's what is loaded into the iframe (with some differences between browsers).

Your exemption says it must not be possible for the format to display at all in xhtml. Or is "it cannot be" an instruction to the author and not a quality of the rendering engine?

But those are not rendered "natively" but through a transformation process.

I'm not sure I follow. What do you mean by a transformation process? If I reference a json or xml file from the src attribute of an iframe, that's what is loaded into the iframe (with some differences between browsers).

Is that formally defined somewhere, or is it just "done" by browsers? Ie, is it an added functionality by browsers (or webviews)? If the former, then of course it is clearly 'inherited' by an RS. But if it is the latter, then we may be on a slippery ground: do we have to take it for granted that a RS would do that?

(The only exception is of course XHTML. That is "natively" rendered.)

All that being said, we are talking about something very minor here, so I won't object to do what you originally proposed to do. The fact that we are having this discussion shows that the line I was proposing raises more questions than what is worth...

Is that formally defined somewhere, or is it just "done" by browsers?

This is what confuses me about making it dependent on what can render natively in an xhtml (or svg) document. Even reading systems don't have to render everything epub supports. (Would image data be illegal to use in a reading system without a viewport?) I think we're opening a can of worms that's open to all kinds of interpretation.

We're probably also getting a little picky over an edge case that we have little to no control over anyway. The bigger problem was, as Brady suggested, not opening a loophole for unintended cases, like images called from css. We can't check if scripts are behaving honestly, so any restriction we come up with will depend on the author being aware of the rule and adhering to it.

Does this need a clarification about how such resources are defined? Something like "Resources of core media types that match an exemption remain core media types and are not reclassified as exempt resources." That is, a jpg referenced from a script is not an exempt resource, it remains a core media type. Or maybe that isn't true - I guess it depends if core media types can also be exempt, although we seem to consider these two distinct classes.

Agree, the more we can clarify here the better. I've added a couple of additional sentences to make clear that CMTs do not become exempt resources because they share the same inclusion mechanisms and exempt resources without the exemption would be foreign resources. Hopefully, that improves it a bit.

Nit: "a resource" or perhaps "resources"

Oops, thanks!

I am having a little trouble with the double negatives ("not exempt"/"would not result"), but I have no specific suggestion to make it clearer.

I've tweaked this a bit in the last commit and added the additional context of it being a foreign image resource.

Nit: "a [=foreign resource=]"?