W3C

Publishing Maintenance Working Group Telco

11 September 2025

Attendees

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

Meeting minutes

PR 2788 - w3c/epub-specs#2788

Wendy Reid: Discussing scrolled in rendition:layout
… over to Hadrien Gardeur

Hadrien Gardeur: This is a followup to continuous scrolled comics
… we had an agreement that a new value was a good idea, and we would add a note to explain what has happened to date
… Working on it, there was a lot in fixed layout that aren't really fixed layout
… for instance, the property for layout was a subsection, even though it can specify flowing
… so i bumped it up a level, and then after some more feedback from mgarrish I reorganized again
… I also added an example from a previous doc
… this is really a draft, since I have yet to add the RS side, and I still don't have the note
… I am a bit concerned about revisiting again
… since we already have agreement

Brady Duga: I was reading the comments this morning
… I understand not wanting to re litigate this, it works, I'm not interested in revisiting this
… we shouldn't discount the fact that ivan is confused, so I'm certain others are also
… I'm concerned we haven't made this clear enough
… perhaps it is because we are missing the reading system piece
… perhaps "scrolled" is the wrong word, it is a behavior, not a format
… and we have used it somewhere else for something different
… perhaps we should find a name that expressed the format and not the reading system behavior
… like contiguous vertical

Ivan Herman: Forget about my comment about alternatives
… I officially revoke that comment

Ivan Herman: but the term itself is what I find confusing, since it is already used
… so if we find another term I am happy

Charles LaPierre: Are there horizontal scroll comics
… ?

Hadrien Gardeur: That is a thing, but uncommon
… We did cover a possible direction field

Susan Neuhaus: Do we feel that horizontal scroll can be specified with FL?

Hadrien Gardeur: Not really, same problem as vertical

Matt Garrish: Are comics the sole use case here?
… Rather than scrolled

<Laurent Le Meur> comics is a US term

Brady Duga: I did consider that, but it seems that is also a layout term
… what if someone wants to use if for something else
… I don't like the term vertical that I suggested,
… because then we can't pivot to a horizontal format

Hadrien Gardeur: I do think the only real use case are comics
… having an html container is less than ideal for this use
… Industry would prefer a list of images

Susan Neuhaus: Amazon calls everything comics, even children's books
… I have a lot of questions what the document would look like

Hadrien Gardeur: What do you mean?

Susan Neuhaus: Is it one html with multiple images? Can this apply for panel by panel navigation?

Hadrien Gardeur: for this content, there is no concept of a page. Think of the files as if they were tiles
… the comics themselves are designed to be read in a continuous scroll

Dale Rogers: I wonder if this is the way it is, because people approach epubs coming from the web, and that is the convention there
… Do we want to lock people into a convention or do we want people to have a chance to experiment?

Laurent Le Meur: Today there is no question, the webtoon is tiled vertically, period. If there is one case where the RS must follow the author intent, this is it
… We have seen some horizontal, but they did not have much success
… If scrolled is not a layout, how about pageless? It is very literal

Charles LaPierre: According to some LLM, I got 'axis' or 'single axis', or 'ribbon'.
… also continuous

Wendy Reid: To Dale Rogers, the reason these exist is due to mobile phones
… It is the most natural way to read comics on the phone
… traditional omics are not as good on the phone (zoom, etc)
… the challenge is more and more RSes support scrolled for flowing as well
… we do need to be clear that we are discussing fixed width image format and not other content

Shinya Takami: I just proposed unpaginated or pagefree

<Toshiaki Koike> +1

Shinya Takami: we can define vertical is the default

Brady Duga: I'm enjoying the "pageless" and "page-free" we could add "contiguous"
… I don't like "unpaginated" since it is negative
… we could take this offline and find a way for ranked choice voting
… we could talk about this name for the rest of the meeting

Wendy Reid: That makes sense, let's go back to content

Susan Neuhaus: Hadrien mentioned tiles, what are the tiles, are they svg, jpeg, etc?

Laurent Le Meur: Currently they are jpeg pictures

Hadrien Gardeur: It is still common to send a single file, and let the publisher cut it down to size
… but the reality is no one in this industry cares about html
… the industry today is just bitmaps
… and html isn't really helping, even for a11y

Ivan Herman: I think we said we should look at the a11y issues again, with fallbacks for images
… and maybe this is something we should address in the WG, but not today

Wendy Reid: Aside from the name and a11y, what else is there?

Ivan Herman: I am in favor with going forward, and the new structure works for me
… for the RS, you have a sentence that characterizes what you expect will happen
… the one thing missing is the log entry, that we need
… Big question: will we have enough implementations?

Susan Neuhaus: I was also thinking that scrolling was an option for flowing, but wasn't supported by RSes

Wendy Reid: Totally different question, probably for authoring spec:
… we do have to tell authors how to construct a scrolled document, and we need that to be consistent enough that implementers can do stuff with it
… traditionally, these are released as chapters, but you may also get a season, is it one html file with a single chapter, or do we have something to tell us where the boundaries are? How do we address that?
… One hack might be a single file per chapter

Hadrien Gardeur: There is a technical reason for multi files, mainly performance
… ideally we would have a bunch of images, and then something else that would define a structure
… I think it will have to be one html per tile, and structure can be in the nav document
… I do agree that full seasons make sense for some retailers who can't handle a subscription

Matt Garrish: The whole 1to1 html to image is an old topic, but you can add images directly to the spine, with a fallback to a single html document
… So there are workarounds to the spine level image documents

Wendy Reid: On the html file per tile question, we used to require this for performance, but do we really still need this? Performance is now much better
… And does having a local file change anything, since you don't have to stream?

Hadrien Gardeur: For a good RS, they usually have a few files in memory and discard the ones that won't be needed soon
… Usually this is done with images directly
… on the web, I have seen canvas, iframe, etc
… but you always have this caching to make it work

Brady Duga: both of these work, you could put all your content into a single HTML and then put images in the spine
… or you could split up your images to individual HTML files
… the industry will decide which one
… if the giant HTML causes performance issues people will stop
… if publishers don't like making one HTML per panel they will not do that

Hadrien Gardeur: I think what mgarrish suggested was that we can do images in spine, we can just point at a "this is broken" html
… which is different from what you said
… if people are comfortable with that then it is fine
… so I very much agree with Matt Garrish

Dale Rogers: as a web designer, I was taught that as I develop a design, I am always in the viewport
… so I am always in the browser, and I adjust what I am doing to the browser
… and I am learning not all RSes handle content in the same way
… so I am wondering, as we discuss the spec, how much does the spec say this is how it should be and the RS must adjust, vs how much are we explaining to authors what will work

Brady Duga: I understand we can have a single file that says "this is broken"
… or we can have a single HTML file that contains all images with single line of CSS to make width 100%
… and you don't get that the book is broken
… it might not be ideal, but it could be a fall back
… it would retain the content for RS that require HTML
… then it is up to the reading system to choose to use the HTML or the image isn the spine
… this is consistent with the current spec

Shinya Takami: In Japan we had many comic epubs, we had one image in one html in the spine
… and we use the same for scrolled
… we have many RSes that support that, and they also support vertical scroll
… even for traditional comics
… So in Japan, the only difference is RS behavior. EPUB behavior is the same
… with just the metadata on the EPUB
… we don't need the additional metadata for episodes, etc

Ivan Herman: The approach from duga is fine, with the minimal html file
… But images in the spite with fallback to single html doesn't work because the image size isn't available from just the image

Hadrien Gardeur: The PR is designed this way due to the spec. If we want to do images in spine, then we need different requirements
… on a spec level I think it is hard to say what to put in these documents (can't require images, vs broken comment)
… The benefit to images in spine is it removes the guesswork
… but if we do it here, we should also consider it for comics

Hadrien Gardeur: the ability to know vs guess is a huge benefit

Charles LaPierre: I would be uncomfortable if it cannot be made accessible
… we would need an image in the spine with some way to specify alt text

Matt Garrish: if you do all the images in a single html document, you would need to only reference it once, then add blank documents

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).