W3C

Publishing Maintenance Working Group Telco

11 December 2025

Attendees

Present
Avneesh Singh, Brady Brady Duga, Charles LaPierre, Dale Rogers, duga, George Kerscher, Gregorio Pellegrino, Hadrien Gardeur, Ivan Herman, Masakazu Kitahara, Matt Garrish, Romain Deltour, Shinya Takami, Susan Neuhaus, Toshiaki Koike, Wendy Reid
Regrets
Gautier Chomel, Laurent Le Meur
Chair
Wendy Reid
Scribe
Brady Duga

Meeting minutes

Deprecate properties - w3c/epub-specs#2841

Wendy Reid: This is to deprecate rendition orientation and the spine overrides, flow, and spread
… in the case of spread there is some concern for the spine level overrides

Ivan Herman: let us be precise - we would declare these as obsolete but not conformant, not deprecated.
… this will reduce the message level from epubcheck
… we have heard from toshiakikoike that this is used widely in Japan and deprecating would be bad
… so we should just say that these won't be used

Shinya Takami: yes, if these are marked as errors it will be a big problem in Japan
… so if we deprecate we have to consider epubcheck behavior

Romain Deltour: If we want epubcheck to be more aggressive, then we deprecate some values but make the others obsolete

Matt Garrish: The whole point of obsolete is to mark things as not used or supported, but we don't want to generate errors
… The rendition viewport one should be deprecated, [deprecated???]

Susan Neuhaus: I have been doing fxl for a long time, some are other 10 years old
… this will be a nightmare for them
… I would vote for obsolete over deprecated

Ivan Herman: I think we should make it clear that we meant obsolete
… we just should not discuss deprecation
… are we ok putting all these in that category?

Matt Garrish: It is actually obsolete but conforming, not "not conforming"

ivan + Matt Garrish: some discussion around language for obsolete

Wendy Reid: I do agree with Susan Neuhaus, we cannot deprecate since we will suddenly get a lot of errors
… so we should obsolete these
… we did discuss obsolete with a path to deprecate
… we are in consensus with orientation and flow
… spread still has some nuance
… package level makes sense to remove, but there is some question around spine level

Hadrien Gardeur: spread settings are harmful, auto is only default, none is problematic
… landscape, like portrait makes no sense
… that leaves 'both' which is highly misused
… If you build a RS that follows this behavior you get very bad experience
… All we need is "this should be side by side" or "this shouldn't be side by side"
… we are sending the wrong message by combining all this information one big property
… So something like 'center' is better
… We obviously don't want to break everything, but addressing these separately is confusing

Wendy Reid: even I was incorrectly conflating placement, so we should clarify that section

Susan Neuhaus: I am glad placement will still be there
… I hope we test epubcheck with different types of fxl

Shinya Takami: Regarding spread: none, we do use it in some cases, but it is the same as 'center'
… in some cases we say spine spread-none, so it would be bad for these to be errors

Wendy Reid: If we make it obsolete, epubcheck will only use INFO, so it won't be an error
… at the very least this will be obsolete for now
… so there will be a lot more INFO messages, but it shouldn't break toolchains

<Wendy Reid> PROPOSED: rendition:spread, rendition:flow, and rendition:orientation will be made obsolete in EPUB 3.4 at the package and spine level, in EPUBCheck they will use INFO messages.

<Susan Neuhaus> +1

<Hadrien Gardeur> +1

<Ivan Herman> +1

<Wendy Reid> +1

<Shinya Takami> +1

<Toshiaki Koike> +1

<Matt Garrish> +1

<Romain Deltour> +1

<Brady Duga> +1

<Gregorio Pellegrino> +1

<Masakazu Kitahara> +1

<Charles LaPierre> +1

<Dale Rogers> +1

RESOLUTION: rendition:spread, rendition:flow, and rendition:orientation will be made obsolete in EPUB 3.4 at the package and spine level, in EPUBCheck they will use INFO messages.

Reorganized Layout Section - w3c/epub-specs#2844

Wendy Reid: 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?

Matt Garrish: 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 Herman: 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

Matt Garrish: 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?

Susan Neuhaus: 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?

Dale Rogers: 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 Gardeur: 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

Wendy Reid: 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

<Shinya Takami> +1 to Wendy Reid

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

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

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

Wendy Reid: We mean content document

Romain Deltour: 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

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

Ivan Herman: we should do a proper resolution before we move on

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

<Matt Garrish> +1

<Wendy Reid> +1

<Shinya Takami> +1

<Toshiaki Koike> +1

<Ivan Herman> +1

<Romain Deltour> +1

<Brady Duga> +1

<Susan Neuhaus> +1

<Dale Rogers> +1

<Masakazu Kitahara> +1

<Hadrien Gardeur> +1

<George Kerscher> +1

<Charles LaPierre> +1

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

Naming

Wendy Reid: Hadrien started this as a side comment, but it is worth discussing
… we have always called it pre-paginated, but everyone calls it fixed layout
… Fortunately I have never seen that in the property itself
… should we clarify in the spec that we are discussing fixed layout when we mention pre-paginated

Ivan Herman: Is 'roll' fixed layout or not?

Matt Garrish: This came up in the PR
… fixed-layout is the document, pre-paginated is the layout
… that is why I split out fixed layout, so fixed layout can apply to pre-paginated and roll
… just from a spec perspective the presentation should be split from the property

Shinya Takami: 'roll' is for scrolled comics, which will be images, which will be fixed layout

Susan Neuhaus: fixed layout is clearer than pre-paginated
… all it meant to me was that pre-paginated meant all the page breaks were pre calculated, perhaps with hard page breaks

Wendy Reid: the way I look at it, we have reflow and fixed, and within fixed we have pre-paginated and roll
… they are both fxl, with the same restrictions (e.g. no font changes)
… I don't think we should remove pre-paginated, and it actually makes more sense now
… I wonder if we frame it that way

<Susan Neuhaus> wendyreid +1

Wendy Reid: so people know at it's core it is fxl with a different presentation

<Ivan Herman> +1 to wendy's view of terms

Dale Rogers: There is a difference in the way that book makers and technical people discuss things
… in html there is the pre tag, which means this is already formatted don't touch it
… is there a way to make technical specs more human centered so we don't have to translate things?

Matt Garrish: So we could make a new fixed layout section with pre-paginated and roll together underneath

<Susan Neuhaus> mgarrish +1

Wendy Reid: Yes, that is exactly what I am thinking, and it makes things clearer

Hadrien Gardeur: To go back to the previous resolution, we need to make sure syntehtic spreads are for pre-paginated only
… not for roll docs

Ivan Herman: We have to careful about [something] being applied to both types of fxl documents

<Shinya Takami> Reflow or Fixed: font size changeable or not, Pre-paginated or Roll: spread usable or not

Matt Garrish: Yes, so images in spine will go in the higher level fixed layout section

Hadrien Gardeur: Images in spine for fxl will be very common
… for roll it may be the only thing that is used

Wendy Reid: Homework - think about a better name for obsolete, and think about using the transcript for scribing

Matt Garrish: We can just use outdated for obsolete
… which seems just as good

<Romain Deltour> HTML uses 'obsolete' for both, specifying whether it is conforming or non-conforming

Summary of resolutions

  1. rendition:spread, rendition:flow, and rendition:orientation will be made obsolete in EPUB 3.4 at the package and spine level, in EPUBCheck they will use INFO messages.
  2. Move the spread placement section into the pre-paginated section of the specification.
Minutes manually created (not a transcript), formatted by scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).