Support for roll in layout

[HadrienGardeur]

• Bumped layout and content dimensions out of the FXL section as they're shared across document types
• Introduced the definition of a "scrolled document"
• Added a new value for rendition:layout: roll
• Added a new example for a "scrolled document"
• Re-used illustration that was initially created for Proposed changes to EPUB 3.3 and EPUB RS 3.3 to support Webtoons #2602

---

Preview | Diff

[HadrienGardeur]

I've opened a draft PR for now since this is my first attempt in a long time to work with ReSpec and I'm still missing at least the EPUB RS side of things.

I'm tempted to follow what I've done in this first commit and bring the rendition:layout property out of the FXL section: https://w3c.github.io/epub-specs/epub34/rs/#layout

[sueneu]

Looks good! I am delighted to see item level overrides. They will be useful for front and backmatter. I do have questions about how the item-level overrides will work and what the fall backs could be.

Could this PR be approved and we refined the document as we move forward?

[mattgarrish]

I'm worried about the structure with these edits. If you go directly to the fixed layout section, for example, you'll miss the section about setting the content dimensions, and without a parallel "scrolled layouts" section you seem to have to piece together that you need to set dimensions by reading through the section to check where scrolled documents has been added to the text.

I think pulling the layout property out of FXL is fine, but the section name might be useful to change. When it's not under the property settings heading it loses some context (e.g., maybe change it to "Layout control" or "Layout preferences").

But is a scrolled document even a new thing that needs defining if a scrolled layout is just a different means of reading a set of fixed layout documents? It's not really a new layout of the content but a different type of flow setting for FXLs.

If the only difference is that you can't set some fxl properties when setting scrolled, is there a way of defining scrolled within the existing fxl section, or of having a scrolled layouts section that links across to how to set the dimensions for FXLs while excluding the properties? I expect presenting "scrolled document" as something new when they're just FXLs in a different context is going to be confusing.

[HadrienGardeur]

@mattgarrish

If you go directly to the fixed layout section, for example, you'll miss the section about setting the content dimensions, and without a parallel "scrolled layouts" section you seem to have to piece together that you need to set dimensions by reading through the section to check where scrolled documents has been added to the text.

My goal was to avoid repeating this information by moving it to the top. We could add a section that references this in FXL and add a section for "scrolled publications" as well, but it would end up mostly empty.

I think pulling the layout property out of FXL is fine, but the section name might be useful to change. When it's not under the property settings heading it loses some context (e.g., maybe change it to "Layout control" or "Layout preferences").

I'm fine with any suggesting that you might have for renaming these sections.

But is a scrolled document even a new thing that needs defining if a scrolled layout is just a different means of reading a set of fixed layout documents? It's not really a new layout of the content but a different type of flow setting for FXLs.

It's a new thing with different constraints from Fixed Layout:

• the resource is fitted to the width of the viewport instead of having both dimensions contained in the viewport
• the publication only makes sense if scrolled, which means that pagination isn't an option (the content is divided into arbitrary tiles, not anything meaningful that can be displayed on its own)
• we very much want to advertise to any software processing these files that they're something different from reflowables/fixed layout

If you look at it from another angle:

• reflowable publications are whatever you want them to be
• fixed layout publications are pre-paginated, each resource is a page, these pages are usually fitted to the viewport of your device and can often be presented in a spread (some RS can scroll FXL publications, but it's less common)
• scrolled publications must be scrolled, each resource is a tile in that scroll, where the tile is fitted to the width of your device with no visible gap between tiles

[HadrienGardeur]

@sueneu

Looks good! I am delighted to see item level overrides. They will be useful for front and backmatter. I do have questions about how the item-level overrides will work and what the fall backs could be.

I didn't change anything for item level overrides and I'm not a big fan of them, they're not well-supported in RS and can provide a very inconsistent experience. They're also less useful in the spine than if we could provide the same info in the manifest.

#2749

[mattgarrish]

• fixed layout publications are pre-paginated, each resource is a page, these pages are usually fitted to the viewport of your device and can often be presented in a spread (some RS can scroll FXL publications, but it's less common)
• scrolled publications must be scrolled, each resource is a tile in that scroll, where the tile is fitted to the width of your device with no visible gap between tiles

Sure, the presentation of the fixed dimension documents is different, I'm not arguing that, but you're not defining anything new about the layout of a content document. We have documents with reflowable text and we have documents with fixed dimensions. Those fixed dimension documents in turn are either used within fixed layout displays or scrolled displays. That's the similarity I want to try and capture better if we can.

I see the problem in having fixed layout document be the container for both definitions, but what I was trying to get at is whether there is a way to define a common root for both type of documents. For example, something like:

1. Layout control
2. Fixed-dimension layouts
   1. Introduction
   2. Content document dimensions
   3. Fixed Layouts
   4. Scrolled Layouts
3. Reflowable layouts

Then we don't have the content document dimensions floating at the same level as both fixed and reflowable layouts and we don't have to reference out to apply this info to both.

And the scrolled section might not need a lot of explanation, but I still think it's better to have something than rely solely on a property value to introduce these. Assume readers know nothing and are going to want to understand when and how to apply scrolled layouts.

[HadrienGardeur]

That's the similarity I want to try and capture better if we can.

I see, so it's mostly about the way we organize the spec then.

I'm fine with your suggestion, we could group them under a shared section where they would share the content document dimensions section.

For scrolled layouts, there's something else that I haven't tackled yet: we want to include a paragraph dedicated to backward compatibility with what some of the publishers in Japan are currently doing.

[bduga]

Overall looks good, but +1 to the structure Matt proposed. Ideally the top level would be "Fixed layouts", with "Prepaginated" and "Scrolled" subsections, but fixed layout as a term likely has too much baggage to be used that way.

[mattgarrish]

I see, so it's mostly about the way we organize the spec then.

Right, sorry for confusingly using fixed layouts in my first post. It's the fixed dimension documents that are the commonality between the two and that I think we can leverage to make a section fitting for both.

[HadrienGardeur]

I've re-organized things based on @mattgarrish feedback.

I would personally drop the reflowable layout section entirely (see #2754) and only keep scrolled-continuous for rendition:flow under a section dedicated to legacy support for scrolled comics in Japan, somehow similar to what we currently have in EPUB 3.3 for viewport dimensions: https://www.w3.org/TR/epub-33/#viewport

[iherman]

I must admit I am confused by the terminology. The confusion comes with the term "scrolled". At first read, the way I would understand rendition:layout = scrolled is that the full document is scrolled with an automatic adaptation to the screen size. Essentially, the way a browser would display the whole EPUB content as if the files were, conceptually, concatenated. But this is not what is proposed here, because rendition:layout = scrolled is defined (in the current structure) as a property applicable to fixed dimension documents only, ie, where the dimensions are set and "frozen". But this is not reflected by the property term.

Then comes the confusion: how does this relate to rendition:flow = scrolled-doc? After all, that feature is specified for non-fixed dimension publication; otherwise the behavior is similar.

Actually, it is not clear to me why having scrolled appears as a third value of rendition:layout in the first place. The way I understand the text is that we have two major categories: fixed dimension documents and the ones without this (which we call reflowable although that term is misleading in this respect). Both categories have a "scrolled" version. Wouldn't it be more logical to use rendition:layout as a dividing line between the two major categories (roughly as it is now) and use the rendition:flow property values of scrolled-doc for both, defines as what it means now for reflowables, and the new meaning for fixed dimension ones?

(I understand the current terms are not ideal for this approach, but that is history. We will have to live with that.)

I claim no expertise in this area, so I may miss something essential. But then it must be clear in the spec what I miss, because I find the current proposal confusing...

[HadrienGardeur]

@iherman if we're talking about continuously scrolled comics specifically, the use of HTML as a container and the requirement to set content dimensions in HTML are mostly things that get in the way but that we need to use because EPUB is designed that way.

Ideally, we would:

• skip the HTML container for individual bitmaps
• references images directly in the spine
• and maybe provide the dimension of each images in the manifest

Support for comics is very painful in EPUB because our requirements often get in the way of what authors, publishers and reading systems would really like to do.

Then comes the confusion: how does this relate to rendition:flow = scrolled-doc?

We've already had this discussion a few times now:

• rendition:flow only applies to reflowable documents
• it's a hint and not a widely supported one
• IMO it's also a very misguided thing to have in our spec in the first place because reflowable publications are all about freedom for the user to do whatever they want (I know some people feel differently, but this is has been the reality of the market for the last 18 years)
• for continuously scrolled comics, we need something much stronger than a hint (RS shouldn't paginate this content at all, but it's fine moving one viewport at a time into the content) and we also need a property that indicates that the viewport should be fixed to the width of the resource (unlike pre-paginated where both dimensions are contained in the viewport by default)
• with current RS, using rendition:flow = scrolled-doc together with rendition:layout = pre-paginated (as it's currently done in Japan) we mostly end up with each tile displayed in a spread, where the tile is very difficult to read since it's zoomed out. Only Apple Books is capable of supporting these properties together in a way that works as expected.
• in our previous discussions, we agreed that it's better to have a property that would very clearly identify the distinct behavior that we're looking for (hence a new value for rendition:layout) than fail silently

We can have this whole discussion all over again (we've been going at it for a few years by now), but we had somehow reached consensus that it's better to have continuously scrolled publications as a separate thing from reflowable/pre-paginated and include a note about backward compatibility with what has been used in the past in Japan.

[HadrienGardeur]

As a point of reference, here's what I think would be the ideal solution: https://readium.org/webpub-manifest/profiles/divina#:~:text=Example%201%3A%20A%20scrolled%20publication%20that%20contains%20two%20episodes

We can't reach that point with EPUB because of our restrictions with bitmaps in spine.

FYI, this is what South Korea has adopted as a national (TTA) standard (I can share their spec if needed).

[mattgarrish]

Going somewhat on an aside, but it would help to be clearer that properties apply only to the categories they're listed under. Having two fixed dimension layouts might get people thinking they could set the orientation, for example. (We don't have to fix that all in this PR, though.)

As it is, you can set any rendering property because you can mix layouts in a publication, but only the properties specific to a layout apply to documents in that rendering. That's why the existing flow properties can get confusing.

And can we ban spine overrides for scrolled layouts in the interest of simplicity, or is it necessary to mix layouts?

[HadrienGardeur]

And can we ban spine overrides for scrolled layouts in the interest of simplicity, or is it necessary to mix layouts?

You'll notice that I skipped them in this PR and that's on purpose.

I think that spine overrides for layouts are harmful and should be dropped from the spec completely: #2749

The only use case where they might be useful would be in fallbacks (as we discussed two weeks ago I think), but we can't use them in fallbacks because they're in the spine instead of the manifest.

Having two fixed dimension layouts might get people thinking they could set the orientation, for example.

I don't think that authors should be able to set an orientation at all, it's potentially harmful and goes against EAA requirements: #2751

[mattgarrish]

You'll notice that I skipped them in this PR and that's on purpose.

Yes, I spotted that there wasn't a spine override for scrolled and am happy to live without one, but I believe you can still override a global scrolled setting to put reflowable or pre-paginated documents into a scrolled layout, right? (Or did I miss a restriction?) Seems really messy.

I can see the use for having a few fixed layout documents in a reflowable publication, but I never really understood the need for reflowable in a fixed layout publication. It might be too late to deprecate them, but let's at least avoid proliferating it as a practice.

[HadrienGardeur]

[…] but I believe you can still override a global scrolled setting to put reflowable or pre-paginated documents into a scrolled layout, right? (Or did I miss a restriction?) Seems really messy.

Yeah it's a mess and we really want to avoid that. I wasn't sure how to introduce a restriction since my preference would be to just deprecate the whole thing.

[mattgarrish]

I think this could be done in the layout overrides section. It might be as simple as changing the first sentence to:

Except in scrolled layouts, EPUB creators MAY specify the following properties...

[iherman]

Re bike shedding: I myself love the term "rotulus" (see Wikipedia), it expresses quite well what we are talking about. However, we have to acknowledge that it may create problems insofar as it is a fairly mysterious word for non-English speakers (I must admit I did not remember this word either; my spell checker considers it as an unknown word, too).

I looked for synonyms, the ones I could gather were "scroll", "roll" (sometimes with adjectives like "vertical roll", "document roll", "parchment roll"), "codex", "volumen". Out of these, "roll", or possibly "document roll" may be a good compromise.

[bduga]

I am not sure if this is the best place to list out replacement ideas, but I am not really sure what the best place is. I made a Google Doc with some items that came from the meeting, and I have just added yours. Doc with comments enabled is here <https://docs.google.com/document/d/1FgC98D6O7T_lW_eb541jOKoAxP5XsKLoqtB7eQV6Lfo/edit?usp=sharing>, but I have no idea how long that will survive now that it is a publicly scrapable link.

…

On Sat, Sep 13, 2025 at 12:01 AM Ivan Herman ***@***.***> wrote: *iherman* left a comment (w3c/epub-specs#2788) <#2788 (comment)> Re bike shedding: although I myself love the term "rotulus" (see Wikipedia <https://en.wikipedia.org/wiki/Rotulus>), it expresses quite well what we are talking about. However, we have to acknowledge that it may create problems insofar as it is a fairly unknown word for non-English speakers (I must admit I did not remember this word either; my spell checker considers it as an unknown word). I looked for synonyms, the ones I could gather were "scroll", "roll" (sometimes with adjectives like "vertical roll", "document roll", "parchment roll"), "codex", "volumen". Out of these, "roll", or possibly "document roll" may be a good compromise. — Reply to this email directly, view it on GitHub <#2788 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA246ZHNBRPQYVEYTQ3S4FT3SO6MZAVCNFSM6AAAAACF2YW5QWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEOBXG4YDMNJTGE> . You are receiving this because you commented.Message ID: ***@***.***>

[HadrienGardeur]

I agree we should separate the two questions along the lines you propose. The image in the spine issue would have further consequences which are beyond to a rotulus layout.

I've opened both of these issues. I'll wait until we make progress on them before updating this PR any further.

• Naming our new value for rendition:layout for continuously scrolled comics #2791
• Using images in the spine for comics #2792

[HadrienGardeur]

I've updated the PR based on our resolution for #2791

[HadrienGardeur]

As suggested by @iherman, I'm happy to have this merged after a review from @mattgarrish as long as we keep in mind that our on-going discussion about images in spine (#2792) could heavily impact this PR.

You can look at the examples that I've shared in #2792 (comment) to compare it with this PR.

[mattgarrish]

I haven't had a chance yet to review this again, but I noticed a couple of things while resolving the merge conflicts:

• I wouldn't use the term "rolled document(s)". It sounds like each document is its own rolled up thing (and we could be accused of smoking our own documents 😄). I'd call them "roll document(s)" to emphasize more that they're part of the roll and to avoid people mistaking the layout value for "rolled".
• I noticed pre-paginated and rolled documents were often mentioned together. If it's common to need to talk about these as a pair, it might be helpful to define an umbrella term to reduce the repetition. That's why "epub content documents" exists, so we don't always have to say "XHTML content documents and SVG content documents". A term like "fixed-dimension documents" could cover both. But feel free to ignore if it's less prevalent of a problem than it looked like in the conflicts.

[HadrienGardeur]

I'd call them "roll document(s)" to emphasize more that they're part of the roll and to avoid people mistaking the layout value for "rolled".

Works for me, I'll update the PR accordingly.

I noticed pre-paginated and rolled documents were often mentioned together. If it's common to need to talk about these as a pair, it might be helpful to define an umbrella term to reduce the repetition.

I wouldn't work on that one yet because it might be temporary. If we accept images in spines, I don't think that we'll need to group them at all. Since we're meeting in a month at TPAC and there seems to be no strong objection so far to images in spine, it's worth being patient.

[iherman]

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

View the transcript

PR for Support for roll in layout

<shiestyle> w3c/epub-specs#2788

CharlesL1: One question, we have a new rendition layout role, comics used to be fixed, right?
… what do we now expect with this change?
… what will reading systems do differently?

Hadrien: pre-paginated is the current value, the expectation is you may find one or the other
… in pre-paginated every resource is a page, maybe with layout hints
… similar to print comics
… with roll, you will fit to the width of the viewport, and you can scroll through with no gaps
… looks like a single image to the user
… There are some open issues, like direction
… and direction may change how fit works (e.g. left-to-right might fit height)
… There may be some publications that have multiple rolls (e.g. a collection of web comics)
… this is an open issue
… the idea is instead of rendering controls, we would provide semantics that identify chapters or episodes, then leave it the RS to decide display

shiestyle: Roll will not have spread

LaurentLM: In the PR, it says "fixed dimensions", but in our case it is 1 fixed dimension

Hadrien: But you are confusing viewport and images

LaurentLM: I am not sure if I am speaking about images

Hadrien: Which is why I am not pushing the PR at the moment, since a lot changes with images in spine

LaurentLM: So why is it fixed dimensions?

Hadrien: It doesn't matter, we will probably discard a lot of it
… we originally grouped FL and roll, but we may not need to if we allow images in spine
… I don't think this will get much work or discussion until TPAC where we decide on images in spine

shiestyle: We still have time before TPAC, we should finalize there
… but we can still discuss now

Hadrien: Looks like we only have the week before TPAC given schedules, do you really want to discuss images in spine then?

shiestyle: we will have another meeting before tpac

Hadrien: So you want to discuss images in spine during that call? It will take the entire call

shiestyle: We can arrange it

---

[iherman]

This was discussed during the pmwg meeting on 10 November 2025.

View the transcript

Images in spine

<shiestyle> #2792 #2825 w3c/epub-specs#2788

shiestyle: The first topic is images in spine

Hadrien: I think this has been contentious, we've discussed for a long time, it came up when we first discussed FXL
… we know that images in spine are used, we also know that people have issues with them, mainly for accessibility, I kind of feel that we're stuck in the same discussion loop
… we have the same arguments for or against
… we never manage to move forward
… we're stuck as a result with the status quo, my questions I hope can move us towards a solution for this
… we have some options within the spec, other options might require changes to the spec
… we should avoid the status quo, I don't think it's good to have a difference between the spec and the industry

duga: So you often point out that there aren't really accessible comics, or they are hard to do
… I agree for comics, it doesn't make sense for XHTML, but for FXL we do have accessible content
… in that perspective, it is an accessibility issue for FXL, this subset of content is huge, comics is a big industry
… for children's books, it's good that that content is accessible today
… people are making use of these features
… it's not fair to disregard the accessibility aspect
… but if we do something for comics, that is weird, but we have rolled content, not sure if we should forget about HTML in this respect either
… the other question, you listed two options, image in spine or image in spine with fallback HTML
… would HTML in spine be illegal for roll comics?

Hadrien: Not saying it should be illegal, it would be disappointing to those producing that content
… we shouldn't force people to put images in spine, but shouldn't force HTML either
… would negatively impact adoption

LaurentLM: In every specification, certain things are triggered by certain metadata, roll comics are triggered by specific metadata
… we could say accessibility of scrolled comics is different, if we say we want to do the same for paginated comics, or do something different
… we could extend the time of solving the accessibility problem
… we don't have that content on the market, we don't know what an accessible comic needs to look like
… more research needs to be done

Hadrien: There is a difference between partially accessible comics vs fully accessible comics, we don't know what makes a fully accessible comic

LaurentLM: Just adding HTML to comics doesn't make it accessible

rdeltour: I have a simple question, does it have to be EPUB
… images in spine, it creates hurdles in interoperability, could it be a separate standard, a profile, something that is different?
… another question about CBZ, basically a list of images in a zip, could be we somehow have a hybrid CBZepub?
… could an epub be a CBZ or vice versa

Hadrien: First question is good, we see some places saying EPUB is not the solution. But one option to discuss, do we do something more like web publications, SK is doing JSON with metadata and some controls
… it goes to Ivan's question, has the boat sailed
… but for some markets, EPUB is huge, like Japan, we can't pretend people don't use it
… for CBZ, the order of images matter, the .epub may not be recognized by CBZ readers
… you could name images in a way that works for CBZ
… you could make something that works for both
… or a packaged web publication that could also be an EPUB at the same time
… maybe a little too creative there

wendyreid: I think I share Romain's question, does this have to be EPUB?

wendyreid: One of the underlying parts of this discussion is, philosophically, what we think EPUB is?

wendyreid: Do we think that, as the group that maintains EPUB, who do we serve and who do we follow?

wendyreid: We try to strike balance between what industry wants and what readers need

wendyreid: And lately also government regulations

wendyreid: On the surface, about images in spine, questions what do we want EPUB to be

wendyreid: Many of us fought for EPUB to be the accessible standard, accessible by default.

wendyreid: Images in spine is where we need to make decision, in order of priority, where do we put things?

wendyreid: Does accessibility trump everything?

wendyreid: Disappointing that some markets didn't choose EPUB as the standard, for variety of reasons

wendyreid: But companies releasing apps with PDF or CBZ are not thinking about accessibility

wendyreid: in their application or business model

wendyreid: That's a choice that they made in their business

wendyreid: But do we want to make that choice for EPUB

wendyreid: We know there are many inaccessible EPUBs out there, because businesses made that decision. But for EPUB, you have to make a *choice* to make inaccessible. We give all the tools, they choose not use.

wendyreid: But here we would give them a tool to make inaccessible content.

wendyreid: Make that possible.

fantasai: What are the implementation challenges with having images in spine vs in HTML

Hadrien: Apps that implement this, they don't use webviews, they use platform APIs, with HTML they need to find ways to render those images, if its SVG they need to rasterize the images
… not saying they should do that, but that is what they do

fantasai: Is there or has their been an effort to create a profile for HTML that prioritizes images?

Hadrien: Japan has it, it's not used by everyone even in Japan, it's something you know if you're in industry, but it has no official status
… the closest would be the EBPAJ profile

fantasai: Would it make sense to standardize on that?

Hadrien: Possibly, it falls on the line of having an alternate profile or best practices document

fantasai: The HTML file would need to conform in a spec, it would validate, for reading systems would know to parse as an image, but we have the additional structure, the framework for creating accessible content is still there

Hadrien: The reality would be it might be fragmented, but would move people in the right direction possibly

ivan: To put things in perspective, the approach Romain suggested is how we published the audiobook standard
… it follows the rules of Publication Manifest, it's an analogy
… a very different point, at some point in your slides, image in the spine fallback to HTML as a solution, there were two other approaches discussed, one was suggested by Matt
… referring to the fact you could put the alt into the package, it's legal in the spec,
… other possibility was to include the accessibility info in the image itself through metadata

Hadrien: The first is to use meta:refines, refine the image using it's id to provide description
… one way to do it
… those have been discussed before

gpellegrino: We can have images in spine with fallbacks, I suggest we leave the spec as is, we advise on how to make comics

rdeltour: For the sake of completeness, in one of the slides you mention was the objective was to link a page to an image, maybe it's also possible to use the nav doc, may also be used to link the pages to the document
… not sure if that works, maybe worth looking into

seth: I have missed some of the previous meetings, we've heard a lot from reading systems people, I never hear from publishers
… I want to know what the issues are with tooling to add the necessary accessibility info to documents
… it can't just be there's no interest
… there must be challenges
… is there a gap in the EPUB production process that blocks this being possible

Hadrien: A page in a comic can have a lot of information, you'd need to describe each panel, and even within panels
… comics are visual by nature, for screen readers, you'd need to produce text in the right order
… almost a transformation of the content, like a novelization
… there's a huge complexity in how to produce the thing
… do you need to get the author involved, are you following the author's intent?
… lots of open questions and cost associated
… if the resulting text is just a huge block of text, it's not functional either, it would need to be a full HTML document with everything you'd need

Hadrien: Some of it is cost, some of it is technical, there's needs beyond just screenreader users
… one panel at a time plus text to speech, not only do you need equivalent text for a given fragment, then we have tactile images
… we can do some of that today, we can't do what say EAA expects

ivan: I want to come back to what Gregorio said, and the spec of today allows what you need as allowing an HTML file as fallback, I may have misunderstood the second part, this may only be valid for roll comics
… I would be uneasy to add something to the spec for just one type of content

<fantasai> +1 ivan

ivan: it relates to what Hadrien said, falling back to an HTML file, seems to be only a rudimentary way to handle accessibility for an image
… not sure we can handle it today

<rdeltour> +1

gpellegrino: Ivan, my proposal was not to allow this way only for roll content, since it's already allowed for any content in the spine
… my proposal was to have guidelines for producing comics

<ivan> +1

fantasai: I wanted to scope the question down to sighted users who need accessibility support?
… to make that work, you need to have a format to support that additional content, you need a reader to support that, and you need tools to produce that content
… does any of that exist?

Laurent: No

fantasai: If we want EPUB to be able to do this, is images in spine getting us closer or further to that?

Hadrien: We're years away from being able to do what you describe, its too early to say, I don't think it would be a step in the wrong direction to add images in spine
… if we really want to achieve comics accessibility we can say its someone else's problem, or we can work towards it

wendyreid: Discussed in fixed layout accessibility task force about that. How do we make this possible?

wendyreid: We have some proposals, to solve what Elika described

wendyreid: Discussing side-by-side content

wendyreid: parallel content that's related to each other

wendyreid: I don't think we're as far away from this as we think we are

wendyreid: There are reading systems already that do side-by-side content (forgot name)

wendyreid: One that allows fixed layout and relayout together

wendyreid: A lot of it, unfortunately, it's about tooling.

wendyreid: Lack of will to make this happen

wendyreid: Especially nowadays, with AI, offers us a lot of ways to automate this that previously would have been fully manual

wendyreid: Only a few years ago, alt text for comics would have been fully manual, now can automate much of it

wendyreid: Image detection of panels

wendyreid: Etc.

wendyreid: I'm reluctant to say that it's not possible. It's increasingly possible.

wendyreid: Alternate format providers are already doing this work, just mainstream publishers are not

wendyreid: So I'm reluctant to give in on this.

wendyreid: We have the technology. Some of the tools already exist.

wendyreid: A lot more publishers can do in content development that they're not doing.

wendyreid: And more on reading system side that could make it possible

wendyreid: I've seen scrolled fixed layout content in EPUB readers. It's not impossible.

wendyreid: Doesn't mean we should make provisions in the spec to sacrifice our principles

shiestyle: We have 10 minutes left, we want to conclude this topic in TPAC, maybe gpellegrino's proposal, using the spec as is
… we will not make consensus to make images in spine without fallbacks
… should we vote on this?

Hadrien: I think some people don't like image in spine with HTML fallback but its the current spec, having a best practice document that describes how to do this, that is doable
… it solves what I was mentioning, that helps to drive things toward clearer guidance

[Seth asks question about tooling and alternate text in Japanese]

seth: Can someone from the Japanese publishing community share why they don't produce accessible content, is it tooling or something else?

toshiakikoike: When preparing alt text for manga, just the speech bubble text is not sufficient, but people make prepare the description of the story, we can't prepare that content without the author
… it's difficult to prepare that content

ここには日本の出版社の人がいると思うので、聞きたい。漫画はなぜアクセシビリティをサポートしないのか。どういう理由があるのか？

Ito-san: Japanese publishers don't have the right to produce that type of content, only authors can

shiestyle: I'll explain this a bit more tomorrow, manga content is generally out of scope

漫画のアクセシビリティというのは、何を情報として含めるのかが難しい。ただセリフをテキストに変えさえすれば、漫画のコマに含まれている情報を正確に伝えることができたというのかというと、そうではないとも思っていまる。

Hadrien: Just wanted to reply to Wendy's comment, and it leads into the next discussion
… there's a number of documents that can't be made fully accessible, we have children's books, textbooks, comics, the solutions for all those can be slightly different
… there's options for magazines, newspapers, there's content out there where you can view articles
… we don't have a way to support those in EPUB
… I've talked to many people, but they are missing the format, they don't know how to distribute it
… I don't think comics fall into that, comics is a lot about storytelling, comics have more in comics with media overlays or SMIL than textbooks or newspapers
… there's AI solutions out there, but they haven't been tested, and they don't have a way to represent that
… there's prototypes, but it's still early
… we don't have an easy way out of the hole we've dug ourselves into, is it now or in the future? Up to us

ivan: The way I read the standard now, for each image you'd have an HTML fallback, ideally one HTML with the alt text, making the publisher's lives easier, but you can't refer to a fragment in a fallback
… if this is our solution, we force the author to produce one HTML per image

Tomikura-san: What accessibility features do people want?

Hadrien: We hear from people that there is interest, people want access to what their friends are reading
… also with EAA, in theory, most books on the market will be natively accessible, orgs will re-orient to focus on different types of content, usually education or comics
… orgs want to produce the content
… maybe publishers won't do it, but alternate format providers will
… with Marrakesh treaty, people can do this, we might be in a world where speciality providers can do this work
… it doesn't put burden on publishers, but it does create challenges for the providers

---

[iherman]

This was discussed during the pmwg meeting on 10 November 2025.

View the transcript

Image in Spine (cont.)

<shiestyle> #2792 #2825 w3c/epub-specs#2788

fantasai: Did we conclude on the images-in-spine issue? Should there be a resolution?

ivan: Agree that having a resolution is what we need
… but I wonder whether we can make the formal references to fallbacks a bit more flexible than they are today, to make it easier to collect all the hypertext into one file instead of one per image for 200 images
… Might require adjusting how fallback is identified in the package document
… Maybe an additional entry which would allow referencing a fragment in the fallback file
… Because right now we don't have that

Hadrien: So, saying you'd have a single HTML with all the text, and you'd have the fallback point to a fragmentID

ivan: Yes

Hadrien: If we do that, that opens a lot of other questions

duga: That fundamentally changes fallbacks and the spine and how this works.
… Maybe a great change, but much bigger change.
… Fallback in the spine is meant to be, this is the content document you can use instead of this other document.
… You can just swap the files out
… But we don't have fragments of documents in the spine. In fact we have specific restriction on re-using a document in the spine.
… Avoids complications with navigation and paging etc.
… So this is a giant can of worms.
… If we do fallbacks, we should do fallbacks as we do now

ivan: Ok, but we have a problem.
… image in the spine with HTML fallback is technically true, but very impractical

Hadrien: Yes, it is impractical

wendyreid: I would agree it was impractical if 1) it wasn't already how things happen and 2) if person who is making epub had to hand-write every HTML document
… but this is automated. It's not difficult to produce the files.
… The tooling is already there to do it, workflow is there to do it.
… If there was a size concern here (and the size here comes from the images, realistically speaking), maybe
… It does seem a bit silly to have 100 HTML files that aren't used, but in terms of effort it's not a big deal.

Hadrien: My suggestion comes from pragmatic viewpoint which is what's out there
… I see 2 things
… Images in spine with HTML fallback, and HTML with image fallback.
… We should recognize these as valid ways to deal with this problem.
… not have it be word-of-mouth
… So we need to acknowledge what's out there.
… Secondly, one of those two should be how we recommend authoring content.
… "this is the way you should do it"
… Not necessarily in the spec, but that could cover other comic-related issues
… We can also recommend other things like metadata, semantics etc
… With that approach, we won't break anything, won't ask anything new, would just say "this is what is used, and this is what should be used"

rdeltour: If we knew how well fallbacks are supported in reading systems
… we do have some tests for manifest fallbacks
… but those are about one single document having a fallback
… but I wonder if someone has tested when all the documents have fallbacks, how does that work, how to transition from one document to another
… whether this is sufficiently tested to be a viable solution

gpellegrino: I think the time is not right for thinking about solutions for comics etc. So opening the possibility to just images in spine maybe problematic. So suggest we continue as we have now, postponing the discussion, and we can open a task force thinking about a11y and comics

gpellegrino: Maybe inside the a11y task force we already have

gpellegrino: but I wouldn't take it up right now

ivan: I agree

ivan: Laurent, is it possible for you to take a typical example which has fallbacks with HTML and has a relatively large number of images, and turn it into a test case for our test suite?

LaurentLM: Yes

ivan: It would be a valuable addition to our test suite. Romain is right, we have a basic test, but we don't have a good stress test.

ivan: With that, I think repeating what Elika said, I think we should have a vote and have a resolution on what we put for advice for this type of documents

LaurentLM: I totally agree, and disagree with Gregorio

LaurentLM: We don't validate 3.4 today. So we have time to make a pre-recommendation, and ask reading systems to support what's in the spec

<gpellegrino> +1 to Laurent

LaurentLM: We can easily make the evolution to support fallbacks if we know this is the right direction.

LaurentLM: So let's make a pre-recommendation that is a resolution of this

LaurentLM: And then when we make 3.4 we will be ready, and reading systems will be ready

ACTION: LaurentLM to add a images-with-fallbacks stress test to test suite

wendyreid: Something to consider is images with XHTML fallbacks, those happen to have alt text which is great, how do I signal to reading system that I want the fallback instead of the images?
… Most reading systems don't open the OPF file to see what's there.
… Maybe we now need to make fallbacks more obvious to users?

LaurentLM: There's a simple way. If there is a version of a comic with some accessibility description, then the publisher should put it as the first choice. Image as a fallback.

LaurentLM: Favorite of the publisher should be first.

Hadrien: That doesn't work. Many have put HTML first and images as fallback because it works in more systems, e.g. Apple Books can't work with images in spine.
… So I don't think HTML in spine signals an intent from the producer
… It has more to do with the state of the industry than anything else
… There's no easy way to signal this preference.
… We have a problem in general with fallback. We use spine to convey information instead of using manifest.
… If we go in that direction, we're uncover a number of problems with how we do information in spine

duga: Would go a step farther and say, if you have an accessible HTML document, you've made an accessible comic, don't put an image in the spine
… Might not work in some crummy reader, they should update.

<Hadrien> +1 for what brady just said

duga: You spent a lot of effort making that.
… So should only do this for comics that are otherwise inaccessible.
… If there is useful HTML accessibility info, put it in the spine, don't put images there.
… Similarly, for childrens books. Put the HTML in the spine. And that can be covered in the note.

wendyreid: So maybe better resolution is, we're keeping the spec as-is, but we are in agreement that comics deserves better guidance, so we want to write that guidance.

Hadrien: And want to acknowledge what has been done for last 10 years, in millions of files.

fantasai: Brady covered what I wanted to say, if we are writing best practices, if you do it clearly enough, but if its clear enough readers that use images can extract them, enabling that functionality
… while making the content more accessible for readers with better capabilities

PROPOSED: Write a best practices document for comics content as a separate working group note. No change to the specification for images in spine.

<fantasai> +1

<Hadrien> +1

<duga> +1

<shiestyle> +1

<ivan> +1

<wendyreid> +1

<rdeltour> +1

<ikkwong> +1

<toshiakikoike> +1

<gpellegrino> +1

<MasakazuKitahara> +1

<LaurentLM> +1

RESOLUTION: Write a best practices document for comics content as a separate working group note. No change to the specification for images in spine.

ivan: Should I close the issue? discussion?

Hadrien: Connected to this resolution is roll documents.
… I was blocked for this PR because unsure about direction
… But we need to decide more wrt roll documents
… We had some remaining complexity with how to describe them in the specification, that is resolved with this, we can have an example with image with HTML fallback
… We can get rid of many complexities.

ivan: I will mark the issue as needing to be closed, and chairs can figure it out

[discussion of what to discuss]

---

[HadrienGardeur]

@mattgarrish I know that you wanted to merge that PR to avoid further conflicts.

Based on our discussions in Kobe, I moved back to a draft where FXL and roll documents are not covered under the same section ("Fixed dimension documents") anymore.

I can add an example in that section as a placeholder or we can merge things as-is and work in a new PR, whatever works best for you. Since we'd like to deprecate a number of rendition:* properties, it's best to get this out of the way first.

[mattgarrish]

Ya, if you want to merge this that's fine with me. I don't have an issue with keeping the layouts separate, but I still find that section (not specifically what you've done) kind of scattershot so I'd like to propose some more changes to it, too (like we have an intro that doesn't mention any of the layouts, and then an intro to fixed layouts but not one for reflowable; the content dimensions might fit under the layout property definition; etc.). I'll make a branch off this and see what I can do to make it read better. Shouldn't take me long and I wouldn't expect it would make major merge conflicts for any properties you want to deprecate.

[HadrienGardeur]

I've extended the example a bit more (to illustrate the typical use case for roll documents) and fixed a typo identified by @sueneu.

There's a conflict with the main branch though, would you mind taking a look before we merge @mattgarrish ?

Once merged, I'll create a separate PR to tackle back compatibility with what some Japanese publishers are currently doing.