Meeting minutes
shiestyle: overview presentation. Agenda.
… Shinya and Hadrien chairing
… scrolled comics (webtoons) and Spread Comics for discussion today along with F2F kickoff
Discussion for scrolled comics
Hadrien: Started from scrolled-continuous discussion.. Things can be improved which is part of scope.
shiestyle: In Japan - rendition:layout-pre-paginated and rendition:flow-scrolled-continuous in use.
… Hadrien's proposal rendition:layout-flow (new)
Hadrien: To be clear, not requesting a new property, but a new value for rendition:layout
… extracted an example of how current books achieve
… should be interesting to see how things are produced today in more detail
… should highlight other points for us to discuss in the future
… for example namespaces used, etc.
… amazon requirement to indicate comics, viewport declarations present, etc
… should be interesting and useful to help give us direction
… sent on mailing list, links coming
Shinya: we can also discuss as part of our next topic
<Hadrien> Examples: https://
<Hadrien> Proposal: https://
Shinya: this has a very large influence in Japan for existing epubs
… have to change the behavior, need reading systems to support
… issue for publishers until we have support across reading systems
Hadrien: What is interesting in the example for Japan is that this example can be tested in reading systems. Currently only Apple Books can currently handle rendition:flow-scrolled-continuous
… Not convinced about argument of compatibility as only Apple RS supports.
… behavior observed is consistent with what you would expect
… in most RS, fixed layout mode does not offer a way for the user to choose continuous scrolling
… when we talk about compatibility, in Japan, the epub are used as an interchange format not as an end spec use
… mostly flow through Apple, and maybe Amazon
Shinya: On RS side, come concerns. From the content / publishers side, also a concern
duga: didn't like flow-continuous, also changes the rules for fixed layout content (fit width)
… difference between being able to set in UI for continuous scroll - could read manga - but want to get rid of the concept of pages
… curious about why this is considered difficult.
… Once change is made in RS, don't understand why this is considered complex
… it doesn't sound difficult.
LaurentLM: In Japan, assertion was used which wasn't standard. See no harm in Japan keeping current solution and adding new solution.
… current metadata being used and new metadata would have advantage of additional RS support, thus it would be good
<Delackner> My apologies, my zoom completely froze for several minutes right after I asked for clarification re: why Shinya Takami was conerned about adding the new value
shiestyle: agree to add new feature for web-toons. concerns of adding new value - value property would be fine
Hadrien: You kind of have to have a new value for layout is that the expectation that come with fixed layout do not work with continuous scroll - expectation to fit both dimensions in the viewport.
… unavoidable as this is about fit width and continuously displaying it in that way
… also making sure this is not just a user preference
… layout is a natural fit for that since the current values don't fit
… makes sense to introduce a new one.
… in terms of implementation for Apple - current values could be aliased
… for others, it is all new work regardless.
shiestyle: in Japan is currently epubs
wendyreid: We've had this discussion multiple times. Problem with adding property - need to handle reading systems that don't support. Need a fallback in the specification.
… no fallback mechanism - if you see something, do X
… worry is that many RS when presented with confusing information default to reflow as it is a safe place. This is not a good experience for a comic.
… presents a backwards compatibility challenge. The other concern is that some of the arguments about fit width / display, this is how we are displaying fixed layout anyhow
… existing RS are already fitting to width as it is the only thing that makes sense. Think this is a technical challenge can be solved without rendition:layout
duga: if you provide to a RS that doesn't support its going to look terrible. Fixed layout today is fit-all and mandates that all of the content is visible in the viewport.
… would require modifying... at the end of the day need something to spec it's fit width.
… if we create a 3rd kind of book is a questions, and appreciate concerns about the difficulty of this
… webtoons do share a lot of qualities of fixed layout, can possibly piggy-back.
… just need to add the change in rendering behavior
… does feel like it would be cleaner to add 3rd type, but understand 3rd type
… probably more correct to add 3rd type, but aware of issues
Hadrien: Agree with Brady - going to be wonky anyhow. About the benefit of using fixed layout, think there are not so many
… don't care about spreads. Doesn't make sense in the context of a webtoon. Flow in general is a bad thing that we have in the spec.
… the idea that an author can decide if the document is paginated or scrolled is really a user choice
… property -flow- is at odd with design goal of reflow able epub
… the idea of extending something that is useless or harmful is a bad idea
… the right way is to acknowledge the fact that these are different publications
shiestyle: would consider depreciating existing, but need to keep for compatibility, but acknowledge it's a workaround currently.
CharlesL: Vote is to add a new value/property of fixed width - like the idea. If done correctly, not trying to fit the entire image. If user wants to flip pages, but had property, and the image is long you have to scroll
… when you get to the end of it, you have to change pages.
… at the end the user swipes to the next page
… or the user goes into the RS and you now get continuous scrolling
… having one new value may get us what we want.
… perhaps defaults to scrolling-continuous
shiestyle: In Japan, we don't use long images, we cut to small pieces currently so they have the same height
<sdelackner> My apologies, new to this discussion format but how do I join the speaker queue?
wendyreid: agree with Hadrien about the point of rendition-flow:scrolled, but this alludes to a philosophical point - the decision to give content creators to the control.
… we have seen RS give the user the ability to adjust content to preferences
… publisher author value becomes more of a hint about how it was authored
… RS provide the capability. We should see the same thing for webtoons... we still have a tension. agree flow setting should not have been provided.
… it probably should have been for fixed layout to begin with.
… there may be a case for using flow... to the point of current usage need to be careful to not break existing systems.
dale: Wondering - author vs user. are approaches valid? in CSS can say important for example. Wondering about user vs. author
<wendyreid> ack +
dale: are there situations where it can't be both ways - author intent should win?
… seems we are trying to have both worlds.
dhall: My question is best answered once we ge tinto more detail
… epub is basically just xhtml documents, didn't we once have the idea to have images in the spine instead?
Hadrien: There was a proposal to have images in spine, but Apple was against it
<CharlesL> Just images means no accessibility no where to hang the alt text etc.
Hadrien: So orgs thought it was a good idea, but we couldn't get to consensus
dhall: Where are at, we want better ways to do author suggested layout with user abiliy to override
… Need to have enough info for RS to be consistent
Hadrien: To go back to Charles / Wendy - default behavior is fit width and continuous scrolling
… usually one long image and break it down with some rules. Not talking about paginated media
… we should still be able to give users options - for example keyboard nav - spacebar can move one full screen at a time (accessibility support for example)
… very important to make content understandable
… don't want to be confusing to users
… want to be able to move one screen at a time is the user desire
… about affordances for progressing
sdelackner: A while ago discussing about a negative that the spec allows authors to specify. Fixed layout books in the wild that define no spine. Its not like we leave this up to the user, we preserve the spine.
… this seems analogous to webtoons. author has decided that this is the goal - continuous flow thank you.
… to Shinya - concern about new value can possibly force systems would need to assume that they might consider a fixed layout non-web-toon could find this and how to support
… from a production pipeline, need to consider
… speaking to idea about adding a value possibly adding, systems might say... yeah we don't do that...
CharlesL: Agree with the idea that some RS guidelines are necessary - can scroll by one 'screen' using keyboard is good. Get point that author may not have the idea of page - could be in the middle of some text.
… wouldn't want content split if paginated.
… we don't want just images in the spine as there is no AX support
… for Kindle and others - it's going to be an issue for RS side..
… If you have to start swiping and see broken content, this is gong to be an issue.
… will be disruptive. we have to set expectations that there will be RS work.
… having Fixed-Width and Continuous scroll is what this means.
Hadrien: Don't think this is about the moral / author intent. if RS respected flow you could have some that are chapters that are paginated and some that are scrolling - creates a funky UX experience for the user.
… this ability should be depreciated.
duga: RE Seth. True that this is a property... in practice two kind of books. flowing text and fixed layout
… new property really introduces a new kind of book for publishers.
… more than just a property - it really is a new kind of book, even though it's kinda already there in the book.
… question is around if this what we want to tackle.
<sdelackner> My mind is not giving me the name, but there's properties today that really only make sense per-book but are indeed yes per-document
LaurentLM: Currently JPN implementation. has been implemented by some publishers, RS amazon, apple support.
… is the intent to get this adopted by RS?
shiestyle: all of JPN support - apple, amazon, webtoon RS
LaurentLM: Good to get a list and see the impact
shiestyle: Amazon, Apple, maybe Google, JPN webtoons supported. Maybe not so few in JPN.
… will discuss about F2f next month.
… two slots for each day. One for WT, one for Comics Spec.
… Want 2 or more meetings before F2f
Agenda for F2F kick off meeting in April 2025
shiestyle: Continue to discuss, want a vote at the F2F if possible.
shiestyle: Close meeting for today. See you at next WG call!