- Last update: June 20, 2024
- Author: Hadrien Gardeur
Continuously scrolled comics are often referred to as "Webtoons", due to the popularity of the Webtoon platform owned by Naver in South Korea. Since this is a trademarked term, we'll refer to these publications as "continuously scrolled comics" throughout this document instead.
- Continuously scrolled comics are distributed using a format that's similar to TV shows, where the story is broken down into seasons and episodes.
- Each episode is presented as a single scroll, broken down into "tiles" where each tile is a bitmap image.
- They're primarily read on smartphones, where reading applications display these tiles by filling the entire width of the viewport and lay them without any visible gap between them.
- On larger devices, these tiles may be centered in the viewport using a maximum width instead of filling the viewport.
- Most of them are read by continuously scrolling from the top to the bottom, which means that subsequent tiles are displayed below the current one.
- That said, there are a number of comics that are also read using scrolling in another direction: left to right, right to left or bottom to top. This scrolling direction can affect how reading applications fill the viewport and lay subsequent tiles.
- There's usually a discontinuity in the reading experience when navigating between episodes, which is important to convey in a packaged format which could contain multiple episodes or even entire seasons.
The EPUB specification defines rendition:layout
as a mean of indicating whether a publications is reflowable or pre-paginated using two different values:
- reflowable
- The content is not pre-paginated (i.e., reading systems apply dynamic pagination when rendering). Default value.
- pre-paginated
- The content is pre-paginated (i.e., reading systems produce exactly one page per spine itemref when rendering).
With reflowable publications, the text and layout is entirely controlled by the end user.
While the specification allows EPUB creators to express their preference for pagination or scrolling using rendition:flow
, this is poorly supported in reading systems and feels at odds with the freedom offered by reflowable publications.
With pre-paginated publications, users have less control on the overall reading experience. Each "page" is displayed by fitting both dimensions in the viewport, in some cases side by side with another page (this is called a "spread").
Pre-paginated publications are usually displayed strictly using pagination, although a few reading systems also offer the ability to scroll pages or spreads.
With this document, I would like to propose the addition of a third value for rendition:layout
:
- scrolled
- The content is presented using a single continuous scroll, without any visible gap between between spine items.
The presence of this property will trigger the behaviour described in the introduction of this document:
- Each spine items fills the entire width or height of the viewport, based on the scrolling direction of the publication.
- Overflowing content is scrollable on a single axis.
- Subsequent resources in the spine are laid out without any visible gap between them.
This proposal also introduces a new property to offer additional control over the scroll direction of the entire publication: rendition:scroll-direction
.
This cannot be overriden at a spine level, to avoid inconsistencies in the overall user experience.
EPUB creators must use one of the following values with the rendition:scroll-direction
property:
- btt
- Bottom to top scrolling direction.
- ltr
- Left to right scrolling direction.
- rtl
- Right to left scrolling direction.
- ttb
- Top to bottom scrolling direction. Default value.
Example 1: A scrolled publication read from left to right
<meta property="rendition:layout">scrolled</meta>
<meta property="rendition:scroll-direction">ltr</meta>
When a reading system renders a scrolled publication, the scroll direction defines where subsequent spine items are placed:
- below the current spine item by default or for
ttb
- above the current spine item for
btt
- on the right of the current spine item for
ltr
- or on the left of the current spine item for
rtl
This can also affect how the viewport is filled. On smaller devices, the reading system will:
- fill the entire width of the viewport by default or for
btt
andttb
- or fill the entire height of the viewport for
ltr
andrtl
Images in spine have been a contentious point of discussion in the past. They're technically allowed by the specification through the use of SVG in the spine, but bitmaps cannot be referenced without a fallback or an XHTML/SVG container.
There's usually a heavy dose of hypocrisy whenever this topic is raised, always circling back to the idea that the XHTML/SVG container is necessary in order to ensure their accessibility.
In practice, this means that there are millions of EPUB publications where the primary resources are bitmaps referenced from an XHTML. Sometimes, things get even more convoluted with an XHTML document that contains an <svg>
element which only references a bitmap.
Despite the use of XHTML, none of these publications are accessible. Even if their creators wanted to make these publications accessible, there are currently no documented means of doing so.
I will address this requirement in a separate proposal, but in the meantime, I feel that we need to move beyond this hypocrisy.
The EPUB specification allows EPUB creators to use bitmaps in spine as long as they provide a fallback to an XHTML or SVG document.
Example 2: Bitmap with a fallback
<manifest>
<item id="tile1"
href="1.jpeg"
media-type="image/jpeg"
fallback="unsupported-feature"/>
<item id="unsupported-feature"
href="unsupported-feature.html"
media-type="text/html"/>
</manifest>
This proposal recommends using this fallback mechanism for the time being, in the hope that a future Working Group will revisit that decision and finally allow bitmaps in spine.
In order to override the default behaviour of displaying spine items in a single continuous scroll, this proposal also introduces a new property that EPUB creators may use locally on spine itemref elements:
- rendition:break-scroll-before
- Specifies that the current spine item should break the current continuous scroll and start a new one.
Example 3: Spine item breaking the continuous scroll
<spine>
<itemref idref="episode1-tile1"/>
<itemref idref="episode1-tile2"/>
<itemref idref="episode1-tile3"/>
<itemref idref="episode2-tile1" properties="rendition:break-scroll-before"/>
<itemref idref="episode2-tile2"/>
</spine>
This property is primarily meant for EPUB publications that contain multiple episodes of a series, in order to provide a break between episodes.
Instead of documenting new metadata for continuously scrolled publication, this proposal recommends using the following properties from schema.org :
- https://schema.org/CreativeWorkSeries to document the name of the series
- https://schema.org/CreativeWorkSeason to document the name of a season
- https://schema.org/numberOfSeasons to document the number of seasons in a series
- https://schema.org/numberOfEpisodes to document the number of episodes in a series or in a season
- and https://schema.org/episodeNumber to document specific episode numbers
For the sake of making these examples more readable, I've ommitted the fallbacks currently required by the EPUB specification.
Examples 4: A scrolled publication that contains a single episode.
<metadata>
<dc:title>A cute Maine Coon appears</dc:title>
<dc:language>en</dc:language>
<meta property="schema:CreativeWorkSeries">The Cat Collector</meta>
<meta property="schema:CreativeWorkSeason" id="season-1">Season 1</meta>
<meta property="schema:episodeNumber" refines="season-1">1</meta>
<meta property="rendition:layout">scrolled</meta>
</metadata>
<manifest>
<item id="tile1" href="1.jpeg" media-type="image/jpeg"/>
<item id="tile2" href="2.jpeg" media-type="image/jpeg"/>
<item id="tile3" href="3.jpeg" media-type="image/jpeg"/>
</manifest>
<spine>
<itemref idref="tile1"/>
<itemref idref="tile2"/>
<itemref idref="tile3"/>
</spine>
Examples 5: A scrolled publication that contains an entire season.
<metadata>
<dc:title>The Cat Collector</dc:title>
<dc:language>en</dc:language>
<meta property="schema:CreativeWorkSeason" id="season-1">Season 1</meta>
<meta property="schema:numberOfEpisodes" refines="season-1">2</meta>
<meta property="schema:episodeNumber" refines="season-1">1</meta>
<meta property="schema:episodeNumber" refines="season-1">2</meta>
<meta property="rendition:layout">scrolled</meta>
</metadata>
<manifest>
<item id="episode1-tile1" href="1.jpeg" media-type="image/jpeg"/>
<item id="episode1-tile2" href="2.jpeg" media-type="image/jpeg"/>
<item id="episode1-tile3" href="3.jpeg" media-type="image/jpeg"/>
<item id="episode2-tile1" href="4.jpeg" media-type="image/jpeg"/>
<item id="episode2-tile2" href="5.jpeg" media-type="image/jpeg"/>
</manifest>
<spine>
<itemref idref="episode1-tile1"/>
<itemref idref="episode1-tile2"/>
<itemref idref="episode1-tile3"/>
<itemref idref="episode2-tile1" properties="rendition:break-scroll-before"/>
<itemref idref="episode2-tile2"/>
</spine>
This seems very comprehensive, but if I was to boil it down to just what we need today for webtoons it seems like rendition:layout scrolled is sufficient. It might be interesting to take just that property and incubate some implementations.