Repository navigation
Are fragment identifiers allowed in manifest? #1303
Description
It appears that href attributes anywhere in the package file must be IRIs.
Each item element in the manifest identifies a Publication Resource by the IRI [RFC3987] provided in its href attribute. The IRI MAY be absolute or relative. In the case of relative IRIs, Reading Systems MUST use the IRI of the Package Document as the base when resolving these to absolute IRIs. The resulting absolute IRI MUST be unique within the manifest scope.
But we don't appear to forbid fragment identifiers. All we say about href is
An absolute or relative IRI reference [RFC3987] to a resource.
EPUBCheck complains loudly about fragment identifiers, I think because it misinterprets them as incorrect file extensions.
I'm not sure if we need to do anything here.
Activity
mattgarrish commentedon Oct 29, 2019
They should be allowed as they're needed for refines, links, previews, and probably other things.
There's just no defined reading system support for them, even for refines, I believe.
mattgarrish commentedon May 13, 2021
I didn't realize we had an open issue for this, but I've tried to address this in the PR #1670 for the URL standard.
The URL standard differentiates "relative-URL string" from "relative-URL-with-fragment string". For manifest items (and media overlay audio elements) I've replaced the general requirement for IRI references with the stricter non-fragment URL strings.
Is there any case where a manifest resource can be a fragment of another?
Allowing
linkelements to reference fragments is fine, though, and we have an example of doing just that (linking to a metadata record embedded in an html doc).add change log entry for #1303
iherman commentedon May 14, 2021
The issue was discussed in a meeting on 2021-05-13
List of resolutions:
View the transcript
4. Are fragment identifiers allowed in manifest?
See github issue #1303.
Dave Cramer: i made an epub that had fragment identifier in href
… epubcheck threw an error
… but not sure which section of the spec this requirement came from
… so something to think about, especially as we're rewriting the spec to refer to WHATWG URL spec
Ben Schroeter: would we need to do some epubcheck work if we were to decide to allow these fragment identifiers?
Dave Cramer: yes, but that shouldn't be an obstacle, not big code change
Ben Schroeter: any downside? could it be abused?
Matt Garrish: just curious what the expectation is for RS if it is a fragment? What is RS supposed to do?
… load then scroll to fragment?
… and what about only having each resource listed once?
Dave Cramer: i think this is the same as activating a link in toc, i.e., yes to scroll
… but not suppress any of the document before the fragment
Brady Duga: how would that work in the spine? So chapter 1 is beginning of chapter, but chapter 2 is link to middle of the book?
Dave Cramer: yes, but we could have a note to say not to do that
Ben Schroeter: is there a legitimate reason to do this?
… or is this just to fix the epubcheck thing?
Matt Garrish: suspect this has something to do with the requirement to point to a resource, not a fragment of that resource
Brady Duga: maybe if you want to skip some kind of chapter heading for each chapter, so that you start with the first paragraph of the chapter?
Wendy Reid: we've had some cases where the entire book is in a single HTML file
… so this would allow you to actually navigate to the inside chapters?
Ben Schroeter: what about the fact that fragments need to be allowed for refines and stuff like that?
Matt Garrish: that's not in the manifest
Dave Cramer: a valid reason for changing the spec is to make it match reality, and given that we already enforce this, allowing a fragment here would vastly complicate the responsibilities of an RS
… i think we just say hrefs in items shouldn't have fragments
Matt Garrish: and the URL spec has a type that specifically can't have fragments
… so easy to do in spec
Wendy Reid: is that the current test in the PR that you have out?
Matt Garrish: yeah (I didn't know we had an issue out for this at the time)
iherman commentedon May 14, 2021
@mattgarrish I did not close the issue until #1670 is open; we shouldn't forget to do it.
mattgarrish commentedon May 14, 2021
Right, and I have this issue linked from the PR so it should close automatically with it.