The fallback attribute of the item in the manifest

[taiyuuki]

Some EPUB OPF files are structured as follows

...
  <manifest>
    <item id="id1" href="cover.svg" media-type="image/svg+xml" properties="cover-image"/>
    <item id="id2" href="a_1_1.svg" media-type="image/svg+xml" fallback="id3"/>
    <item id="id3" href="a_1_1.xhtml" media-type="application/xhtml+xml"/>
    <item id="id4" href="a_1_2.svg" media-type="image/svg+xml" fallback="id5"/>
    <item id="id5" href="a_1_2.xhtml" media-type="application/xhtml+xml"/>
  </manifest>
  <spine toc="ncx" page-progression-direction="rtl">
    <itemref idref="id2"/>
    <itemref idref="id4"/>
  </spine>
...

The spines are reference "id2" and "id4". However, in the manifest, items id2 and id4 reference items id3 and id5 via the fallback attribute. I'm not sure why it behaves like this, or if this is in accordance with the EPUB standard. Could you ensure that the "spine" refers to the correct "item"?

[l1yefeng]

The first item in that spine is still item#id2, only that the reading system should render item#id3 if it's incapable of rendering item#id2.

Having fallback attributes like this is valid.
Ref: https://www.w3.org/TR/epub-33/#sec-resource-fallbacks

Of course, using fallback attributes could be an advanced feature if someone can add it to this library.