Manifest fallbacks

[llemeurfr]

The Manifest Fallbacks section is (still) difficult to understand.

One reason is that the examples related to fallbacks are currently placed before this section. My first proposal is therefore to move examples after the fallbacks section, at the same headings level.

We could clean it up a little bit more: the specification of fallbacks is split between the section about the item element (fallbacks from core resources) and the fallbacks section (fallbacks from foreign resources). It would IMHO be better to move the sentence "EPUB Creators MAY provide fallbacks for Core Media Type Resources (e.g., to provide a static alternative to a Scripted Content Document)." to the fallbacks section and rephrase the introductory sentence of the item section as "The fallback attribute takes an IDREF [XML] that identifies a fallback for the Publication Resource referenced from the item element, as defined in "§ 2.3.2.4.3 Manifest Fallbacks".

Also, example 29 is very difficult to understand by reading the explanation. Looking at the code I understand the following: "In the following example, an EPUB Creator inserts a reference to a local audio file directly into the spine. For this reference to be valid, a fallback to a Core Media Type Resource has to be provided, in this case an XHTML document containing a reference to the audio file.".

In this example, the item identified by "#audio01-xhtml" is not included. This does not help understanding the situation. And moving the spine extract to the start of the sample would also be helpful for the reader.

Plus, this example does not correspond to any valid use case: we've never seen audio resources in the spine, audiobooks are created in a different way. Replacing the audio file by something that EPUB creators are inclined to put in the spine would be clearer (but what?).

[dauwhe]

Agreed, with the added complication that I'm not aware of a reading system that processes manifest fallbacks. See #1464.

[llemeurfr]

Sure, clearing the feature from the spec would be better, but as it is there (even if possibly flagged discouraged), it must be correctly explained.

[mattgarrish]

Replacing the audio file by something that EPUB creators are inclined to put in the spine would be clearer (but what?).

A JPEG is probably the only thing that might have at least some real-world precedent. Maybe not for opening out of a hyperlink, but images in spine have been requested in the past to stop having to specify the fallbacks.

[shiestyle]

Yes, we hope images in spine will be accepted in order to make simpler structure FXL contents like Manga.
In my understanding, we keep this restriction because we should also take care about accessibility for such no XHTML&CSS EPUBs.

[mattgarrish]

My first proposal is therefore to move examples after the fallbacks section, at the same headings level.

I'd actually suggest we go the other way and move manifest fallbacks into a subsection of the item element, otherwise the examples become detached from both and floats between bindings. The net result would be that manifest fallbacks occur before the examples with the concept more tightly bound to the item element.

Otherwise, the suggested cleanup sounds fine.

[llemeurfr]

move manifest fallbacks into a subsection of the item element

fine by me.

A JPEG is probably the only thing that might have at least some real-world precedent.

I agree.