Reorganized layout section and properties

[mattgarrish]

This pull request is a continuation of #2842 but rebased on the current draft to avoid merge conflicts.

A brief recap from #2842:

• moved the layout section up ahead of content documents
• added a layout types section to explain each of three main layout types
• moved all the property definition text back into appendix D.5
• kept synthetic spreads as a separate subsection
• moved the section on fixed layout documents and setting their dimensions into the content documents section.
• dropped the "roll document"

New to this pull request:

• I've integrated the changes to remove rendition:orientation and its spine overrides from deprecated the rendition:orientation property #2831 (adding it as obsolete but conforming and leaving rendition:viewport as deprecated)
• I've added a layout section to the reading systems specification and put the requirements I could find for each layout type together
• I added a couple of requirements for rolls based off the existing authoring spec prose and our discussions about no layout control properties applying to it

A bit more controversially, perhaps, I've noted that images in spine are a type of fixed-layout document even if they require fallbacks, and added additional caveats about vendor acceptance and accessibility in the existing note about fxl support. I also added a section to the authoring spec that the icb dimensions will be obtained from the image metadata and to refer to the image format definition for how that's done. I similarly stated for reading systems that if they opt to support image formats in the spine that's where the dimensions are obtained. That should be all we need to say so that we don't have to classify images in spine as separate from fxl documents for either pre-paginated or roll layouts.

Still to do before we look to merge is to resolve on the other properties and overrides we're deprecating so I can take them out without worrying that they'll have to be re-added. This will not only affect the vocabulary, but could mean making spread placement specific to pre-paginated layouts if we decide they aren't useful for reflowable documents.

Fixes #2841
Fixes #2754
Fixes #2753
Fixes #2751
Fixes #2750
Fixes #2749

See:

• For EPUB 3.4:
  • Preview
  • Diff
• For EPUB 3.4 Reading Systems:
  • Preview
  • Diff

(Added preview links for RS, too, IH)

---

Preview | Diff

[HadrienGardeur]

As I've already said in #2842, this is a good step forward to make the spec easier to read, nice work @mattgarrish !

Looking at this PR, section "6.3 Synthetic spreads" remains somehow problematic for me:

• I think that this should be under "6.2.2 Pre-paginated layout" since the concept of spreads only makes any sense for FXL (cf Reorganized layout section #2842 (comment))
• while in Kobe, we voted on a resolution to: "Adapt spec language in Core and Reading Systems to say that if no information about placement in spreads, the first resource should be a page on its own."

This second item was an action item for me but since we're re-working the whole section right now, I think we could tackle it in this PR as well.

[sueneu]

since the concept of spreads only makes any sense for FXL

Is there a current use case for spreads in reflowable?

If we limit spreads to FXL are we limiting future uses of something like Regions that allows for both fixed and reflowable elements? (and is that a problem we want to worry about right now?)

[mattgarrish]

Don't we have spread placement for reflowable to handle the case of mixing pre-paginated documents or having "reflowable" SVGs in the spine? (what is a reflowable svg?)

The reading system won't know if you have a pre-paginated two-page layout in the middle of a chapter, so you need to hint whether to keep flowing the next document after the spread into the left-hand slot or add a blank page so that a new chapter, for example, starts in the right-hand slot.

The same is likely true when reflowable documents are added to pre-paginated layouts, even though support for this is poor.

[HadrienGardeur]

Don't we have spread placement for reflowable to handle the case of mixing pre-paginated documents or having "reflowable" SVGs in the spine? (what is a reflowable svg?)

If you mix pre-paginated and reflow together, they won't be displayed side by side in a spread since the concept of synthetic spread is completely foreign to reflowable documents.

I think that there's confusion about two separate concepts:

• when a reflowable document is paginated, this is usually done with columns where the RS treats each reflowable resource as a long horizontal roll where we move the viewport to view one or two columns at a time
• whereas a synthetic spread is usually handled using two webviews or iframes side by side in a container

[…] even though support for this is poor.

This is poorly supported for several reasons:

• Use cases are poorly documented, if documented at all (full-bleed images in the middle of a reflowable document seems to be the most common one).
• Reading systems often treat reflowable and FXL EPUB as two completely different formats, with different affordances and UX. Mixing them up in a single publication adds a lot of confusion (for example: should I allow the user to change the font size if this feature only works for a single ressource in a FXL publications with hundreds of resources?).

[HadrienGardeur]

To double down on why the concept of synthetic spread is foreign to reflowable documents:

• when the user or the RS decides to display more than a single column of text at a time, the number of columns displayed is tied to the user settings and the viewport (screen size and/or window size, even on mobile we can have windows now)
• this means that we never know if the last screen/viewport will display one, two or even more than two columns
• reading systems often end up filling the rest of the screen with empty columns to deal with this use case

Let's say that we have a reflowable publication with full bleed images in the middle of the spine (which seems to be the main use case): some of them are displayed on their own, some of them are displayed in a spread.

The spine looks something like this:

• chapter 1
• full bleed image placed in the "left" of a synthetic spread
• chapter 2
• two full bleed images placed in the "left" and the "right" of a synthetic spread

The user doesn't like using columns when reading reflowable documents so they've disabled them:

• The reading system will use the entire viewport for chapter 1 until the viewport has been moved to the end of it
• Then it will draw the first full bleed image either on the left or in the center (based on user preferences, screen size and/or device orientation)
• Then it will use the entire viewport for chapter 2 until the viewport has been moved to the end of it
• Finally it will either draw the two full bleed images together in a spread or each of them separately fullscreen (based on user preferences, screen size and/or device orientation)

Any spread placement for these reflowable resources (chapter 1 and chapter 2) would be ignored, since there's nothing that the RS can do with them.

From a design/product perspective, I can also tell you that this is a bit of a nightmare.
Most RS will usually let the user decides whether they want columns or spreads as two separate options that can be set globally or per publication (this depends on the RS). Displaying these two settings side by side or changing the display options in the middle of the publication would be really bad in terms of UX. My best guess is that most RS will look at the rendition:layout value specified in metadata and won't adapt their user settings for these spine overrides at all.

[mattgarrish]

If you mix pre-paginated and reflow together, they won't be displayed side by side in a spread since the concept of synthetic spread is completely foreign to reflowable documents.

Ya, that's true. We do say the properties are only for synthetic spread placement, not simulated two-page reading. But we still have to allow for synthetic spread placement in reflowable layouts because of overrides to contain the documents in the spread.

So, yes, spreads may only be created for pre-paginated documents, but they aren't exclusive to a global pre-paginated layout. We can, of course, define them under pre-paginated layouts and then have the reflowable refer back to the section for embedded spreads.

It just seems like a missed opportunity that you couldn't have a fxl document in one slot and a reflowable in another, but perhaps there's no practical use for it, and it undoubtedly would complicate rendering. But think of an art book, for example, where you could have a painting continuously in view in one slot with a scrolling reflowable document describing it in the other.

[iherman]

Suggested change

	<p>All other properties in the Package rendering vocabulary are ignored for reflowable spine
	items.</p>
	<p>All other properties in the Package rendering vocabulary are ignored for reflowable spine
	items.</p>

Shouldn't we use a more normative language for this type of statement (it is repeated in the other layout subsection). Something like "Other properties in the Package rendering vocabulary MUST NOT be used in spine items". If we are afraid of making some valid documents suddenly invalid, we could used SHOULD NOT.

[mattgarrish]

Those lists are a placeholder for now until we figure out what properties are even surviving this revision. I had all the other properties listed but then took them out to match what looks like will be left after we cull the vocabulary.

But going back to when the list had global properties in it, not just the remaining spine overrides, the problem is that you can mix layouts using spine overrides. So say I want to globally set a value for all the pre-paginated overrides I've added to my globally reflowable layout. A restriction that you must not or should not set pre-paginated properties in reflowable layouts would make it invalid and you'd have to repeat spine overrides everywhere. They're fine to set but they're ignored for reflowable documents by reading systems... hence the statement.

There's also the problem that warnings are as bad as errors for vendor ingestion, so it's probably better to leave the requirement to ignore other properties on reading systems than restrict their presence.

[HadrienGardeur]

It just seems like a missed opportunity that you couldn't have a fxl document in one slot and a reflowable in another, but perhaps there's no practical use for it, and it undoubtedly would complicate rendering. But think of an art book, for example, where you could have a painting continuously in view in one slot with a scrolling reflowable document describing it in the other.

This would create its own set of problems related to reading progression.

What would happen if I swipe or tap to go forward/backward? Would it provide progression within the spread like you're suggesting, or would I move to the next synthetic spread?

This would be even worse if chapter 1 is displayed in a synthetic spread on the left while chapter 2 is displayed on the right. I'm not sure how you would handle progression at all in this case, it would be extremely confusing.

So, yes, spreads may only be created for pre-paginated documents, but they aren't exclusive to a global pre-paginated layout. We can, of course, define them under pre-paginated layouts and then have the reflowable refer back to the section for embedded spreads.

For layout overrides, we define rendition:layout-reflowable under "6.2.1 Reflowable layouts" and rendition:layout-pre-paginated under "6.2.2 Pre-paginated layouts".

We don't refer to rendition:layout-pre-paginated in "6.2.1 Reflowable layouts". Why should we treat spread placements differently and refer them in "6.2.1 Reflowable layouts" ?

[iherman]

For someone not well versed in FXL (sorry, pre-paginated or roll), the section on spreads is really difficult to read. I wonder whether it is possible to reuse, or at least refer to, some of the diagrams we created in 3.3. I realize they are present in the vocabulary definition, but they should, somehow, be present in this section as well. Or, if necessary, create some versions of the diagrams.

(Yes, this could be done in a later PR, once this one is finalized.)

[mattgarrish]

We don't refer to rendition:layout-pre-paginated in "6.2.1 Reflowable layouts".

Right, I'm forgetting where I wrote things. I was thinking that I mentioned pre-paginated overrides under reflowable, but I mention the overrides within their respective layout sections.

The tpac discussions were too late at night for me, but if you're both confident that the group meant to resolve to remove all these properties and limit spreads to fxl, I can go ahead and make more changes now. I have a commit history I can backtrack to now, at least.

[sueneu]

For someone not well versed in FXL (sorry, pre-paginated or roll), the section on spreads is really difficult to read. I wonder whether it is possible to reuse, or at least refer to, some of the diagrams we created in 3.3. I realize they are present in the vocabulary definition, but they should, somehow, be present in this section as well. Or, if necessary, create some versions of the diagrams.

(Yes, this could be done in a later PR, once this one is finalized.)

Readability is a worthwhile goal but maybe too many edits for this PR. Would it be worth making a new issue about this so we can bring it up after this PR is merged?

[iherman]

Readability is a worthwhile goal but maybe too many edits for this PR. Would it be worth making a new issue about this so we can bring it up after this PR is merged?

Yes but, at this moment, that issue would not make sense, it is related to this PR. Once the PR is merged, I am happy to turn that into an issue.

[HadrienGardeur]

The tpac discussions were too late at night for me, but if you're both confident that the group meant to resolve to remove all these properties and limit spreads to fxl, I can go ahead and make more changes now. I have a commit history I can backtrack to now, at least.

We didn't discuss this at TPAC, I'm bringing it up because the reorg moves "Synthetic spreads" to a higher level section of its own: "6.3 Synthetic spreads".

In our current draft, it's under "8.2 Fixed layouts > 8.2.2 Fixed-layout package settings > 8.2.2.4 Spread placement".

[bduga]

Wow, it is hard to keep up with this conversation! Just a few points:

1. I disagree with @HadrienGardeur's reasoning for why spreads shouldn't be allowed in mixed reflow/fixed content as multi col is an implementation detail and isn't used universally. I know Play Books doesn't, I don't think Apple does and I am pretty sure Amazon doesn't (but they have so many products I may well be both right and wrong).

2. I agree with @HadrienGardeur that this is likely too complicated to really worry about now. In fact, I expect if we attempt to find 2 implementations of synthetic spread properties working in an epub with flowing text, we would fail. Given that, it is probably prudent to accept reality and limit these to fixed layout, though I would be pleased to learn I am wrong.

3. @mattgarrish's idea for spreads is interesting (cool even!), but also not how I would expect that to work, and feels like a misuse of these properties. I would expect the first chapter to display, then the pre-paginated content to display. Say I want a chapter to display as paginated text, followed by the fixed layout pages - e.g. a forward to a comic, followed by the comic itself, but I need it to start in the correct page slot. I would be surprised if a RS placed the forward in a single scrollable page, with the first comic page facing it, and since we just removed the last signal for publishers to tell us if a reflow document should scroll there is no way for the publisher to specify the treatment they want. I expect this feature would require more spec work, plus some industry backing. I would also be pleased if that happened, but I am not holding be breath.

[iherman]

The tpac discussions were too late at night for me, but if you're both confident that the group meant to resolve to remove all these properties and limit spreads to fxl, I can go ahead and make more changes now. I have a commit history I can backtrack to now, at least.

The issue of @HadrienGardeur (#2841) does list those properties that we have talked about at TPAC. As we have discussed elsewhere, it would formally be cleaner if we had a formal resolution for the proposal in that issue (which replaces a number of other issues). @sueneu @shiestyle @reidmore-online let us put that on the agenda for this week.

However, I do not see any resolution in the minutes of tpac on restricting the spread properties to pre-paginated layout. This should be discussed and decided upon, hopefully this week again. There is enough arguments around in this discussion, but to have a separate issue raised for that purpose may make it cleaner. Pinging again @sueneu @shiestyle @reidmore-online

[HadrienGardeur]

@mattgarrish I tweaked some of the language related to spread placement in a previous commit but I can see that you're still adjusting that section so I'll comment instead.

When a reading system renders a synthetic spread, the default behavior is to populate the spread by rendering the next EPUB content document in the next available unpopulated viewport, where the next available viewport is determined by the given page progression direction or by local declarations within EPUB content documents.

This might be a good place to also indicate that without spread placement information, there's an expectation that the first resource should be displayed on its own.

We have a resolution on day 1 of TPAC specifically about that:

RESOLUTION: Adapt spec language in Core and Reading Systems to say that if no information about placement in spreads, the first resource should be a page on its own.

This was also an action item for me to open a PR to cover this change, let me know if you'd prefer that.

Although it is common practice to specify the use of a spread in certain device orientations, the content itself does not represent a true spread — two consecutive pages that have to be rendered side-by-side for readability, such as a two-page map.

Since we're making rendition:spread obsolete, talking about a "common practice to specify the use of a spread in certain device orientations" feels weird.

To indicate that two consecutive pages represent a true spread, the rendition:page-spread-left and rendition:page-spread-right properties SHOULD be set on the spine items for the two adjacent EPUB content documents, and the properties omitted on spine items where one-up or two-up presentation is equally acceptable.

We've agreed to drop that concept from the specification at TPAC, there was a resolution for this on day 1:

RESOLUTION: Remove text saying that presence of spread information implies that the pages SHOULD be laid out as a spread, clarify that either presentation equally acceptable.

[mattgarrish]

Sorry, ya, I had a few things from this afternoon that I wanted to finish up but I'm done now, at least until after we discuss this Thursday if you want to take over and make more edits.

It looks like we both tried to write out that bit about spreads applying to reflowable docs, but I made a bit more extensive changes there to mention spreads in reflowable layouts. See if it still makes sense to you. I'm not wedded to anything I've written at this point.

The other changes I made were pretty straightforward removals (which can be undone if necessary), but I also added a section to the reading system spec about handling obsolete but conforming features as we were only talking about deprecated ones. It's basically the same option to support these features but the difference for obsolete but conforming is that the legacy features must be ignored.

[HadrienGardeur]

@mattgarrish your changes look good and I'm happy that you updated these examples that relied on rendition:spread before.

To comply with the resolutions that I referenced above, I would personally:

• drop this entire paragraph
• and add something related to the first resource of a publication being displayed on its own (the equivalent of rendition:page-spread-center) when there's no spread placement information in the first paragraph of that section

We might also need to add this behavior in the RS document, which would require a test as well.

[mattgarrish]

I've made some additional fixes now, including removing that paragraph. I did some rewriting to the first few paragraphs of the section, too. The reading system spec still had some mixing of requirements for reflowable documents in spreads, and I noticed we said nothing at all about how to handle rendition:page-spread-center, so I tried to clean it up as best I could, as well. Again, feel free to directly edit anything if you think it can stand for improvement.

[iherman]

This was discussed during the pmwg meeting on 11 December 2025.

View the transcript

Reorganized Layout Section - w3c/epub-specs#2844

wendyreid: In working on the reorg PR, some questions have come up about moving some things to the fxl section
… like synthetic spreads
… mgarrish are there others?

mgarrish: The biggest one is the one we just resolved
… our previous big problem was it being spread over two specs, 3.3 glommed them together
… I cleaned that up a lot
… and Hadrien's roll is in it, a few other things
… some issues like where are spine overrides allowed
… not sure if we want to get into that now

ivan: The big question does spreads ever apply to flowing?
… strictly speaking today it is allowed, but the should we continue with that? Or reorg the doc to make that better

mgarrish: I introduced images in spine simply to acknowledge that they are fxl
… just to make it clear
… if those are ok, and if we are ok with spreads and reflow not going together?

SueNeu: I haven't seen a used case where it makes sense for spreads in reflow
… but there is a need for mixed documents that have reflow and hybrid
… I just want to make sure if we disallow spreads we aren't taking options away from some creators?

DaleRogers: I want to agree with SueNeu. In the epubs I create, I have mixed fxl/reflow
… I am learning that sometimes documents are treated as reflow or fxl as an entire epub
… it would be nice to have that capability

Hadrien: I don't think there is any impact
… the other thing is, no one knows how to implement this
… or how we would even test this
… and it is unused
… and it is hinted that it is for fxl
… this just makes sense for clarity
… as a top level section I think it causes confusion

wendyreid: If we move spread placement to fxl, it will be clearer since in practice it only works for fxl
… You could use it on a reflow, but it doesn't really make sense

<shiestyle> +1 to Wendy

wendyreid: so we should say spread placement is only for fxl documents, whether they are complete epubs or hybrid

SueNeu: Thanks, that is helpful.
… I agree now, it is better to focus on fxl

DaleRogers: For me it is more semantics. Does document mean an xhtml page or the epub?

wendyreid: We mean content document

rdeltour: Just checking that the PR stays open for a few days, I have some comments
… one is about identifying fxl documents
… we have some statements that are hard to test
… so we say when the creator has this intent, but we can't test intent
… if instead, we say a document is fxl BECAUSE it has a viewport (e.g.) then we can test

mgarrish: It will definitely be open for a while
… I need to do a proper clean up
… so please comment on the PR

ivan: we should do a proper resolution before we move on

<wendyreid> PROPOSED: Move the spread placement section into the pre-paginated section of the specification.

<mgarrish> +1

<wendyreid> +1

<shiestyle> +1

<toshiakikoike> +1

<ivan> +1

<rdeltour> +1

<duga> +1

<SueNeu> +1

<DaleRogers> +1

<MasakazuKitahara> +1

<Hadrien> +1

<kersc> +1

<CharlesL1> +1

RESOLUTION: Move the spread placement section into the pre-paginated section of the specification.

---

[sueneu]

“outdated” is much simpler and works well here. Is there a place where our use of it is defined for people who might want that?

Maybe in Authoring Shorthands?
obsolete: features or attributes that are no longer in common use but are still considered conforming for backwards compatibility

We should probably make it clear in the RS spec that obsolete features should still be supported.

[iherman]

I am late to the party, and maybe what I hit was a RS error. But I have just had a problem with an fxl file that did not display properly without the <meta property="rendition:spread">none</meta>.

I have indeed prepared an EPUB with a bunch of images in the spine (all images are of the same dimension), each having a fallback to an html file, so the EPUB itself is 100% ok per epubcheck. If I display the book in Thorium, it only displays every second image, as if it tried to put each image on top of one another. If I set the meta above, it works just fine.

Is it a Thorium bug, or are we maybe to hasty obsoleting that particular value for that property?

(My experience of fxl is close to nil, so it may well be on me.)

@HadrienGardeur

[HadrienGardeur]

Is it a Thorium bug, or are we maybe to hasty obsoleting that particular value for that property?

This is probably a Thorium Desktop bug for publications with images in spine.

@iherman could you share this EPUB with me by email? I can open up an issue for Thorium Desktop and we'll test it out with Thorium Mobile as well.

[iherman]

The book is at https://e.pcloud.link/publink/show?code=XZC0oAZ5CFtwfY4i9QFPeQTu0EL4Fq2zH87, if it helps (with the meta added).

[mattgarrish]

“outdated” is much simpler and works well here. Is there a place where our use of it is defined for people who might want that?

Yes, we have an appendix that explains the meanings and validation expectations for both outdated and deprecated. If you're reading the github diff and see the syntax [= ... =] around words that's a respec shorthand for linking terms to their definitions, so every instance of deprecated and outdated will get turned into hyperlinks in the rendered document.

We should probably make it clear in the RS spec that obsolete features should still be supported.

I'm updating the reading system appendix in this PR, as well. We used to only say that they may support deprecated features, but I've added separate subsections for each category. The outdated features still have that subset of EPUB 2 legacy features that reading systems must not support that needs to be called out.

[iherman]

Apart from #2844 (comment) (which may become irrelevant) I believe our best way forward is to merge this asap. There may be some details here and there, but we all seem to agree about the broad change, and it may become more efficient to discuss the details through dedicated issues.

Huge thanks to @mattgarrish

[iherman]

Re #2844 (comment) @HadrienGardeur, it works with setting the rendition:page-spread-center on each spine item. But it is much more convenient to have to set it at one place.

Where is it specified in the specification that, for images in the spine, the spread should be none by default. Because if it is not specified, then it is not, strictly speaking, a bug of Thorium...

[HadrienGardeur]

But it is much more convenient to have to set it at one place.

… and much more dangerous as well. I've seen many publications that set this property to none for no good reason, which negatively impacts the UX.

Where is it specified in the specification that, for images in the spine, the spread should be none by default. Because if it is not specified, then it is not, strictly speaking, a bug of Thorium...

That's not the problem IMO.

Thorium Desktop most likely defaults to "auto" but I suspect a bug when laying out spreads with images in spine.

[mattgarrish]

Here's a side-effect of removing the flow property that's not as easy as deleting the reading system requirement:

Reading systems SHOULD support spine-level scripting in reflowable EPUB content documents that use the "scrolled-doc" or "scrolled-continuous" [epub-34] presentation modes defined by the rendition:flow property. Similarly, if it supports spine-level scripting in reflowable EPUB content documents, it MUST implement the "scrolled-doc" presentation mode and SHOULD implement the "scrolled-continuous" presentation mode.

Replacing the flow values with their old rendering requirements, I'm going to change this to:

Reading systems SHOULD support spine-level scripting in reflowable EPUB content documents when rendering the content such that users can scroll overflow content. Similarly, if a reading system supports spine-level scripting in reflowable EPUB content documents, it MUST provide users the option to scroll overflow content in reflowable EPUB content documents and SHOULD provide the option to present the publication as one continuous scroll from spine item to spine item (except where locally overridden).

But let me know if anyone has a problem with this. I'd forgotten we enforced support for the flow types for scripting.

(Edit: removing the parenthetical about overriding values, since that can't be done anymore.)

[mattgarrish]

I believe our best way forward is to merge this asap

I'm getting down to minor cleanup stuff, but I still want to make sure everything is reasonably consistent. I'm hopping between documents today but I'll definitely flip this out of draft status before the end of the weekend and see if there's any final feedback.

[mattgarrish]

Opening this for review now as there's not much left I can do.

I do have one last question about rendition:align-x-center, though. From the reading system processing section, it sounds like applies to both reflowable and pre-paginated content, since it has separate requirements for positioning in the viewport or spread and positioning in virtual pages.

Going back to 3.0.1 it was classified as a general property, meaning it was intended for both layouts, but somewhere along the line it got reclassified as a reflowable property.

@toshiakikoike @shiestyle if you can confirm what it applies to, I'll do a last bit of editing to fix either the authoring or rs specs.

[iherman]

(Editorial: I believe the comment at #2844 (comment) and the resulting thread, should be discussed as part of #2844, and not here. It was my mistake, apologies.

See #2841 (comment)

[iherman]

Reading systems SHOULD support spine-level scripting in reflowable EPUB content documents when rendering the content such that users can scroll overflow content. Similarly, if a reading system supports spine-level scripting in reflowable EPUB content documents, it MUST provide users the option to scroll overflow content in reflowable EPUB content documents and SHOULD provide the option to present the publication as one continuous scroll from spine item to spine item (except where locally overridden).

But let me know if anyone has a problem with this. I'd forgotten we enforced support for the flow types for scripting.

I have no problem with the technical change.

However, I had some difficulties parsing the new text, so I tried to make it a bit more concise. Here is my take:

Reading systems SHOULD support spine-level scripting in reflowable EPUB content documents when rendered with scrollable overflow content. Similarly, if a reading system supports spine-level scripting in reflowable EPUB content documents, it MUST provide users the option to scroll overflow content and SHOULD provide the option to present the publication as one continuous scroll from spine item to spine item.

But I may have missed some nuances...

[sueneu]

Reading systems SHOULD support spine-level scripting in reflowable EPUB content documents when rendered with scrollable overflow content. Similarly, if a reading system supports spine-level scripting in reflowable EPUB content documents, it MUST provide users the option to scroll overflow content and SHOULD provide the option to present the publication as one continuous scroll from spine item to spine item.

This is wonderful. I spot two places where we might use a simpler word, and its missing the caveat about local overrides.

In both versions, I am confused by the first sentence. Is spine-level scripting in the “EPUB content documents”? Wouldn’t spine-level scripting be in the spine but affect the content documents?
It is possible I don’t understand this correctly, I don’t add scripting.

Reading systems SHOULD support spine-level scripting in reflowable EPUBs where content is rendered with scrollable overflow. Similarly, if a reading system supports spine-level scripting in reflowable EPUBs, it MUST give users the option to scroll overflow content and SHOULD provide the option to view the publication as one continuous scroll from spine item to spine item. Local overrides are permitted.

[mattgarrish]

The edits look fine to me. It was getting late so I just spliced in the text that was in the processing instructions for scrolled-doc and scrolled-continuous.

I've deleted the local overrides part, though. As I mentioned in my edit to the comment above, when I copied the text I noticed that the hyperlink went to the flow property spine overrides in the authoring spec which are now gone. Support for overrides is only a thing if the reading system developer chooses to support the flow property, but in that case they will already know they have to account for the local overrides.