Skip to content

some confusion around data URLs #2485

Closed

Description

@rdeltour

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?

Activity

  1. mattgarrish commented on Nov 29, 2022

    @mattgarrish
    Member

    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.

  2. mattgarrish commented on Nov 29, 2022

    @mattgarrish
    Member

    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.

  3. rdeltour commented on Nov 29, 2022

    @rdeltour
    MemberAuthor

    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?

  4. rdeltour commented on Nov 29, 2022

    @rdeltour
    MemberAuthor

    If we make clear they are not publication resources so can't be listed in the manifest that should plug that hole back up.

    ah read that too fast, yes, that should do the work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    EPUB33Issues fixed in the EPUB 3.3 revisionSpec-EPUB3The issue affects the core EPUB 3.X Recommendation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions