"Alternatives" in the spine

[reidmore-online]

Section

https://www.w3.org/TR/epub/#sec-pkg-spine

Describe the problem

One of the challenges presented by FXL content is the lack of flexibility in the visual presentation of the content, which makes accessibility for that content more challenging. One of the suggestions has been to offer alternative versions of the content in XHTML with a reflow variant, but current methods in EPUB3 don't make that option easy.

Fallbacks have been discussed as one way to do this, but don't feel like the best fit, and some reading systems still do not support fallbacks.

A possible option is to introduce new metadata in the spine for "alternatives", where the alternative would be another item in the manifest.

Describe the fix or new feature you propose

Alternatives in the spine could look like this (just a suggestion, this is entirely open for discussion):

<manifest>
    <item id="page1" href="page1.xhtml" media-type="application/xhtml+xml"/>
    <item id="page1-reflow" href="page1-reflow.xhtml" media-type/xhtml+xml"/>
...
</manifest>
<spine>
    <itemref idref="page1" alternative="page1-reflow"/>
...
</spine>

We may want to add additional metadata to identify what kind of alternative it is, but that is open for discussion too. Maybe an extension of the properties attribute?

[mattgarrish]

I think we end up with the same problems as manifest fallbacks just in a different location.

Putting aside whether there is 1:1 mapping of representations, you still can't differentiate that one document is fixed layout and the other is reflowable because rendering properties apply to the spine items and not the individual documents that are referenced from them. Spine overrides would also have to be allowed on manifest items for it to work, but that would get messy as you'd have to set all the applicable overrides for each manifest alternative.

This is the problem that multiple renditions was trying to solve by having rootfile-level metadata to differentiate between fxl and reflowable so representations weren't layered in one publication.

[gautierchomel]

Related discussions:

• Best practice document: Extracting data for TTS and a "reader mode"
• FXL & Reflowable

We need more input from the actual practices.

[sueneu]

We need more input from the actual practices.

From Reading systems and/or ebook makers?

Would Reading systems have or be willing to share end user data?

[gautierchomel]

This was discussed in the 23 September FXL Accessibility TF.

we had a lot of discussion on how to reflow a fixed layout publication
… it's been a topic in places like the french publisher's assoc
… reading systems could offer options to reflow
… if you're using a screen reader, you may not notice if something is FXL because it renders as audio or braille
… can we leverage this, at EDRLab we are working on this
… first in Thorium Web, then later in other platforms
… and Readium Toolkit
… we've heard that some publishers are telling us its a great option, but still we want to be able to provide styling to the reflow version of the FXL
… that is a reality, there are many use cases
… Hachette and others do this already, but in closed applications
… provide both and let you switch between
… don't use multiple renditions, they use JS and internal to them
… they are willing to have that be more standardized
… [other platform] does this as well
… for press content
… it works for them but they'd like a standard
… we plan to discuss this in an upcoming PCG call
… opens a new discussion about the accessibility of FXL that we should consider a new path for work

We are currently planning the PCG presentations to gather input from people who provide synchronised FXL and RFL, understand how they work, and what they need from us.

[gregoriopellegrino]

With the publishers we work with, we see that in these cases, they opt to create two publications: one with a fixed layout and the other with reflow.

Readers consume them in a reading solution where they can switch from one mode to another by clicking a button (for the end user, the fact that these are two separate publications is transparent; for them, they are simply two ways of reading the same content.).

The link between the two "modes" is managed via the pagelist.

The complicated part is synchronizing the annotations.

[gautierchomel]

We also see two publications linked by id
With two ways to change views:

• At the document level (I start reading as paginated or as fluid, a toggle allows me to switch at any time between the views).
• At the section level (I read in paginated, select a portion and get it displayed as reflowable in a modal).

In semantic terms, this is more about two modes or views, rather than an alternate version of a main one.

[HadrienGardeur]

With the publishers we work with, we see that in these cases, they opt to create two publications: one with a fixed layout and the other with reflow.

Readers consume them in a reading solution where they can switch from one mode to another by clicking a button (for the end user, the fact that these are two separate publications is transparent; for them, they are simply two ways of reading the same content.).

This feels like re-inventing multiple renditions all over again. I was never a big fan of renditions, but at least you get the benefit of having both "publications" in the same package.

As @mattgarrish pointed out in this issue and in a call, there are two other options available if we don't want to go back to multiple renditions:

• replace spine overrides for layout with an equivalent for manifest
• or use collection to provide a second "spine"

If I expand @reidmore-online example with the collection element, where we don't have the issue of having several references to a reflowable document from an FXL one:

<metadata>
    <meta property="rendition:layout">pre-paginated</meta>
</metadata>
<manifest>
    <item id="page1" href="page1.xhtml" media-type="application/xhtml+xml"/>
    <item id="page2" href="page2.xhtml" media-type="application/xhtml+xml"/>
    <item id="page3" href="page3.xhtml" media-type="application/xhtml+xml"/>
    <item id="page4" href="page4.xhtml" media-type="application/xhtml+xml"/>
    <item id="page5" href="page5.xhtml" media-type="application/xhtml+xml"/>
    <item id="article1" href="article1.xhtml" media-type="application/xhtml+xml"/>
    <item id="article2" href="article2.xhtml" media-type="application/xhtml+xml"/>
</manifest>
<spine>
    <itemref idref="page1" alternative="article1"/>
    <itemref idref="page2" alternative="article1"/>
    <itemref idref="page3" alternative="article1"/>
    <itemref idref="page4" alternative="article2"/>
    <itemref idref="page5" alternative="article2"/>
</spine>
<collection role="alternative-spine">
    <metadata>
        <meta property="rendition:layout">reflowable</meta>
    </metadata>
    <link href="article1.xhtml"/>
    <link href="article2.xhtml"/>
</collection>

In any case, the one to one mapping between resources won't be enough, so we'll need something like SMIL, region-based navigation or rendition mapping.

[iherman]

This was discussed during the pmwg meeting on 09 October 2025.

View the transcript

Alternatives in spine - w3c/epub-specs#2806

<SueNeu> s/redetour /rdeltour

wendyreid: there was some discussion on this issue, so we need something in the spine
… besides fallback, that indicates something has an alternative
… we've had a lot of ideas about this
… including mapping between resources using something like SMIL
… I wonder if this creates other issues especially with overlay files

Hadrien: A good number of people have been using fall backs for this, particularly for comics
… I don't know if these is part of the main spec or part of the comics group
… it isn't good if something is widely used but not mentioned in the spec
… I think of newspapers and magazines where this is widely used
… I've seen this implemented as getting a list of alternatives like Libby app in the US/Canada
… it is not a one-to-one mapping
… for some publications you could tap on the article and it would open in another view
… to do something like Libby we wouldn't need SMIL
… to do a one to one mapping we would need something more like SMIL, Rendition mapping or region mapping
… there are a lot of organizations that do this with EPUB or PDF. They've invented their own way to do this
… as an extension of the spec to enhance newspapers and magazines as fixed layout epubs

wendyreid: If I understand correctly, you're saying there is a missing thread
… we could continue to let people use fallbacks but we need some way of indicating why they are being used
… we could extend properties or add something new that says the fallback is being used as an alternative
… at large many reading systems may not see the fallback that way and won't provide the necessary UI

Hadrien: fallbacks wouldn't cover the Libby use case
… fallbacks have mostly been used because we don't allow images in the spine
… for what you've described, we do have multiple renditions, though I am not a fan
… I'm not sure it has ever been implemented by anyone other that B&N
… if we want this kind of concept, we could reopen multiple renditions or we could use collection
… I'm worried about introducing something new. We could start with what is in our spec
… because something new may never be implemented

duga: I have a question, this came from the fxl group, but are there other use cases?
… are we trying to fix this in committee without going to the people who are trying this

Hadrien: yes, people who are members of EDRLab are already doing this
… mostly in newspapers, magazines and textbooks

wendyreid: there are tool makers who are also trying to solve this
… and there isn't a lot of clarity for fxl accessibility
… and reading systems aren't jumping on this either
… no one really knows what an accessible fxl book looks like
… there's no reason why this isn't possible, we've seen examples in closed instances
… people aren't doing this on a large scale
… the push for this in 3.4 is that publishing moves slowly and this will be needed

Hadrien: we could invite people building these tools or using this content to the task force
… so they could give us a better understanding and we could identify the needs
… do we just need to map between resources or fragments?
… what are the criteria for need these alternates?
… before we push solutions
… I can try to get this in place before heading to Japan

AvneeshSingh: it would be great to get the use cases in place first
… the main use case in DAISY is braille vs text
… and demand is coming back for this

ivan: let's suppose multiple renditions is still in use. Would we be OK with that

Hadrien: that's a tough question. I don't prefer that. It wouldn't be good enough even if some parts are good enough to sue
… I'm pretty sure major changes would be required if we decided to go to Multiple renditions again

ivan: what I am afraid of is that we are reinventing the wheel, and a wheel we already have
… are we repeating a lot of work others have already done for us

wendyreid: I don't know multiple renditions well, and have never seen one in action
… I understand that multiple versions of the epub are in the same file
… are they completely separate? Can you switch between them? or view them simultaneously?
… in fxl a11y there is a need to see things at the same time
… for instance you can see the full page image but still read the text in a way that can be adjusted for size etc

Hadrien: you can think of multiple renditions as multiple items in the same file
… rendition mapping is used to link resources among different documents
… that's the part I think is not so great right now
… the worst part of multiple renditions is the mapping part

wendyreid: I notice the reading system conformance instruction is that RS must support switching between renditions
… so it would address the use case I mentioned above
… is your problem with CFI?

Hadrien: I don't know why CFI is used so heavily
… I may be able to find my arguments against it

ivan: if you use epub CFI to point to a resource or part of a resource
… we are working on something like this in the annotation task force
… perhaps we could use what we come up with in the annotation TF instead of CFI?

Hadrien: we may not need the complexity that is needed in annotation anchoring

duga: you only need fancy things like CFI if you don't control the publication
… so we could get rid of that
… are we reworking multiple renditions?
… and CFI?

wendyreid: maybe the new way of targeting text fragments is better than CFI

duga: we could talk about CFI all day

wendyreid: I am convinced that some of our ideas that aren't still used were just ahead of their time.
… we will continue talking about this. EPUB 3.4 is going to be the big fxl revision
… it would be helpful to get any feedback you can get

Hadrien: I will go back to people and ask if they are comfortable talking about it publicly

wendyreid: please add any ideas you have for the f2f
… we are trying to schedule a meeting with APA before TPAC

---