You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I find the spec slightly confusing around data URLs:
the "Data URLs" section says resources in data URLs are not publication resources.
the publication resource definition says data URLs are an exception to the requirement to list publication resources in the manifest, which kinda implies resources in data URLs are publication resources.
Which is true?
Can a data URL be listed in the manifest? (the manifest MUST only list publication resources)
If yes, a navigation document that is not in the spine can be defined as a data URL… do we need more restrictions?
With the caveat that I haven't gone back to reread what the spec says, but from memory you can't open a data url in a top-level context, so what would be the point of listing them in the manifest? You can't reference manifest entries from content documents, so if you can't reference them from the spine then there's nothing you can do with them.
They aren't unique publication resources in content documents since they're technically part of the html/svg file, not a separate resource (same as an embedded svg isn't a publication resource).
All that to say I agree that the definition is weird if it's calling them publication resources. Maybe it was meant to be more of a note, but I'll take a look.
If yes, a navigation document that is not in the spine can be defined as a data URL… do we need more restrictions?
Ya, that would be problematic! If we make clear they are not publication resources so can't be listed in the manifest that should plug that hole back up.
what would be the point of listing [data URLs] in the manifest?
the only reason I can see is to define a manifest fallback for when the URL is used in a context where no intrinsic fallback can be provided (e.g. embed element).
It's an edge case and I can't see a realistic reason to do so, but we could always be surprised.
I'm more concerned about being able to create EPUBs with navigation documents or overlays as data URLs, and that would be (currently) legit while being totally unsupported (I expect, I haven't tested this).
What about forbidding data URLs in the package document altogether ()? Have anyone ever found a use of data URLs there?
Activity
mattgarrish commentedon Nov 29, 2022
With the caveat that I haven't gone back to reread what the spec says, but from memory you can't open a data url in a top-level context, so what would be the point of listing them in the manifest? You can't reference manifest entries from content documents, so if you can't reference them from the spine then there's nothing you can do with them.
They aren't unique publication resources in content documents since they're technically part of the html/svg file, not a separate resource (same as an embedded svg isn't a publication resource).
All that to say I agree that the definition is weird if it's calling them publication resources. Maybe it was meant to be more of a note, but I'll take a look.
mattgarrish commentedon Nov 29, 2022
Ya, that would be problematic! If we make clear they are not publication resources so can't be listed in the manifest that should plug that hole back up.
rdeltour commentedon Nov 29, 2022
the only reason I can see is to define a manifest fallback for when the URL is used in a context where no intrinsic fallback can be provided (e.g.
embedelement).It's an edge case and I can't see a realistic reason to do so, but we could always be surprised.
I'm more concerned about being able to create EPUBs with navigation documents or overlays as data URLs, and that would be (currently) legit while being totally unsupported (I expect, I haven't tested this).
What about forbidding data URLs in the package document altogether ()? Have anyone ever found a use of data URLs there?
rdeltour commentedon Nov 29, 2022
ah read that too fast, yes, that should do the work!