Meeting minutes
Day 1 overview
Wendy Reid: I want to do a quick overview of day one in case there are people who missed or refresh their memory or if things came up overnight that they had thoughts on
Wendy Reid: yesterday we spent the bulk of the day on annotations, fixed layout, comics
Wendy Reid: there's been huge progress in annotations, the beginnings of what the format will look like, more work to be done but exciting, keep an eye on it
Wendy Reid: afternoon spent mostly on fixed layout, comics with progress and decisions on rendition properties
… what to do with images in spine, deciding on best practices on comics
… also talked about ISO and what to do about the progress, good news: since that discussion I talked to three people who can help so positive movement there. Upside of conversations at TPAC you can find someone who is relevant
… for today, is there anything people want to ask about yesterday / comment on?
… for today we have a couple of topics, grab bag day of random things
… starting with discussions about the update to the Japanese publishing guidelines, then in the afternoon updates to publication manifest and possibly HTML in epub, survey results
… remainder of afternoon "general time" to do issue cleanup
… we started the rendition properties discussion but maybe focus on the rest of the rendition stuff to get it finished
… if there are other issues you want to discuss we have time so let us know
… anything we missed or burning topics you want to discuss while we are all available?
… good start, ahead of schedule. Shinya, would you tell us about the japanese publishing guidelines?
Japanese Publishing Guidelines Update
<Shinya Takami> See my slides
Shinya Takami: this TPAC was held in Japan so we prepared a special session for introducing Japanese status for some kinds of guidelines update
… EBPAJ as some may know created the EPUB3 file creation guidelines over ten years ago, and maybe these bring a big impact of the Japanese epub market to expand and grow steadily but
… this moved to DPFJ 3 years ago, this new organization combined with the Digital Comics organization
… DPFJ today has some people in this room
<Wendy Reid> See DPFJ Homepage
Shinya Takami: has over 50 publishers and some major reading system developers in japan so we can discuss the consensus of the japanese market of Ebook area,
… I am in charge of the area of Comic related commitee chair, also liason with W3C liason with PMWG
… for 10 years this old EBPAJ guide was not updated but this year actually last month we updated the guideline in 10 years because we released EPUB 3.3 two years ago and we wanted to update the guide
<Wendy Reid> See DPFJ Guidelines
Shinya Takami: to the latest EPUB version. There's a Japanese and english version also
… the characteristics or features of the DPFJ guide is used by many publishers in japan and referred to by many reading systems developers for Japanese market including global companies like Amazon Google Apple Kobo, etc
… includes a lot of guidelines for Japanese text expression rendering layout because they are so different between reading systems in japan, because not only browser based but also
… some reading systems have original rendering systems
… because maybe before EPUB3 in japan we have some traditional domestic formats used in the EPUB market in Japan that still are in use
… DPFJ guide also provides best practices for MANGA contents but its based on Sony's best practices guide from 10 years ago. so...
… maybe not the best but in use for 10 years so it is easy to extract images from manga for many reading systems
… in Japan dedicated manga reading systems are easily developed
… In Japan Fixed Layout means Image based content
… HTML and fixed layout with CSS is very hard to create
… DPFJ guide provides feature of standardized EPUB contents in Japan
… and the feature of DPFJ guide is CSS files
… we provide some sample files with these guidelines, it includes the CSS file
… this CSS file contains many many preset classes for Japanese text layout so publishers can use these CSS files and select the class presets already so it is easy to use Japanese expressions, vertical layout, tateyoko
… some reading systems have their own original renderer as already explained, as we used to have some domestic formats like Voyager-made `.book`
… as example this is a CSS example describing Tatechuyoko (horizontal layout in vertical layout text)
… the image shown means 30'th anniversary, and is prepared using the `.tcy` class and we said some features of properties in this class
… so 10 years ago we said these CSS samples and we can maintain these EPUB3 files as is for now
… we updated the guidelines for 10 years. What is different or what's new
… we want to adopt EPUB 3.3 spec but it is not so big a change as we concentrated on compatibility of existing files
… we updated some kinds of references from IDPF -> W3G, EPUBCheck URLs, but the main difference for Japanese market is we deleted some features from sample files
… but not such a big change from international formats, and we added WebP as an image market but for now
… many Japanese market reading systems don't support WebP so we want to encourage this WebP or AVIF format so we put these new formats in the guidelines
… next actions: we didn't include A11y conformance in the guide yet
… Will discuss the reason afterwards
… if we release EPUB 3.4 we will put scrolled comics features in the guidelines in the future
… let me introduce the A11y situation in Japan
… these guidelines have not included A11y guidelines because and most EBOOKS in Japan are NOT accessible
… last year regulations were updated, but many publishers are not sure how to make books accessible in Japan
… also there are no standardized practices or guidelines for making Manga accessible in the world or Japan at all so we have to make
… but many publishers hesitate to create such content as it is quite hard to prepare
… as discussed yesterday it is not the publisher's right so they have to confirm the copyright
… we provide the paper book and ebook simultaneously so if the A11y support is too much we cannot provide both simultaneously so in Japan we don't know how to make the Manga accessible but we want to know the situation of accessible manga outside Japan
… another approach for the A11y guidelines: METI, one of the Japanese government ministry
… started to prepare a guidebook for EBOOK accessibility, I'm a member of this working group
… but this guideline excludes fixed layout and complicated layout books like education or specialized books so it is aimed for the very popular novels or easy to read contents
… and unfortunately these Japanese guidelines will not request for the EPUB A11y conformance totally because many members of this working group think
… it is too hard for the Japanese publishers to meet even the single conformance
… so many think we should exclude manga / fixed layout contents from these guidelines so we didn't discuss accessible manga yet
… maybe in America or Europe regulations they discuss these but the Japanese regulation doesn't cover manga yet
… so we have to define the reasonable accommodation for the Japanese market but this will not be in conformance to EPUB
… so this is a different requirement from the EU or US market
… currently the Japanese market will go in such direction
… so after this government guideline is released we will update the guidelines next year but we need more discussions, as I said the Japanese / US / EU conformance are very different so it will be a big issue eventually
Wendy Reid: what has the working group with METI defined what the gaps are? it would be helpful to understand speaking as someone who worked on EPUB A11y and worked on WCAG standards as well to understand the perceived gaps in Japanese content
… it helps to be specific where are the gaps in reflowable novels, education, manga vs the current standards? understanding those gaps helps us understand how to address them and maybe even requires we change the standards
Shinya Takami: many Japanese publishers or working group members think we have to focus on the mandatory criteria as necessary for the beginning of the Japanese adoption of A11y
Shinya Takami: we are just focusing on TTS features as necessary for A11y as recognized in Japan, I don't know why but many people focus on TTS.
Shinya Takami: specialized books or educational ones have special requirements for pronunciation. we focus at first on the lazy conformance
Junko Kamata: before EPUB3 we had the word of publishing basically E-comic with various proprietary formats, then after that EPUB3 changed the market to a new world
Junko Kamata: at that time generally incorporated association named DPFJ, sometimes you see the DPFJ on that slide, I think would like you to say the DPFJ is the base of the publishing company team, concerned about EPUB3, and the member of them contribute the guideline, so from the birthdate the DPFJ has a mind to contribute to spread knowledge of EPUB3
… or reading system or how to sell
… national diet library has now a Ebook repository officially and now we have some copyright law and law against discrimination against disabilities / barrier free reading content. The market for ebooks is small compared to the english market but the teamwork is good so
… the ebook stores, publishers, developers of reading systems all would like to contribute to build the ebook market in Japan, the key person is [...]? also I would like to introduce the DPFJ executive director Motoi Suzuki ?
Bobby Tung: we use the same guideline as Taiwan (?) and use the same platform as publishers used in Japan for ten years that has some restrictions for what HTML tags you can / cannot use
<Bobby Tung> https://
Bobby Tung: it happened earlier in Taiwan people were encouraged to use the latest CSS tags and got in trouble as
… they used text decoration underline + offset to create a highlight effect to emphasize a word, working in Chrome but not well in Webkit and Safari so people in Japan want to do this effect want help to use the correct syntax for vertical writing
… it is a good chance, if you can open this in Chrome and Safari you can see things different but we should test different browsers.
… I translated EPUB Accessibility 1.1 to traditional chinese but
… they send the book to the library for the visually impaired, they see no problem with ASE and the epub accessibility standard but there is a problem with the TTS system because one character can have 6 different pronunciations and even AI can't get it right so we want some better way to do TTS
Charles LaPierre: I just want to remind everyone that EPUB A11y 1.1 we watered that down slightly with an exception with the WCAG 1.1 for text alternatives for images and complex images that we thought would be too much a burden to make publishers make complex image descriptions also for things like comics
Charles LaPierre: that exception was removed in EPUB A11y 1.2, because 1. its a WCAG requirement, but also in US and EU publishers were starting to embrace Alt text and complex image descriptions especially in STEM educational materials
… starting to push that effort to the author and demand that the author provide alt text descriptions, you know what you meant so you provide the alt text and complex alt description so the japanese market should take a hard look at
Matt Garrish: To clarify 1.0 had the exception, 1.1 removed it
Matt Garrish: as an editor had to point that out
Laurent Le Meur: a comment, Bobby Tung, you said that pronunciation, TTS is a big deal we totally agree, we have a problem because we try to have TTS but when we try to make a better pronunciation because browsers follow the rules or don't differently,
… perhaps the browser vendors in different rooms are discussing this but we should push them to treat this better because otherwise even if we improve it won't matter
Bobby Tung: we use in chinese BOPOMOFO which can be used to produce Han character pronunciations, and ruby to show how to pronounce,
Bobby Tung: but it will pronounce the ruby once and the base as well, so we need attributes or selectors to decide how to pronounce Ruby
Hadrien Gardeur: just wanted to add to what Laurent said, there's a breakout session with WCAG tomorrow but mostly about speach recognition instead of TTS, also last year the same as there was interest in chat bots
… dissapointing because the current state of TTS is broken for some years and there's always some browser broken in some way but inconsistently and even with the same browser in different situations may crash or get it wrong
… decent VO in some browsers but even if you install better voices you can't use them,
… we know it is possible to get high quality TTS voices but Microsoft Edge browser is the only one doing it
… TTS is possible but sad and broken, even boundaries between words, where to pause, all broken, but worse there seems to be little interest at W3C
… maybe included in media or audio but an afterthought and we might be the community that cares the most
… browsers are avoiding this issue, maybe they have a reader mode but it is walled off away from reading system publishers, so they sidestep the issue, would love to find the right contact to push for TTS mattering on the web
Laurent Le Meur: we always speak about a11y but we are totally blocked on the web for one of the most important ways to get a11y
Wendy Reid: so I think what we are all discussing here is these are all incredibly important things and we need to take advantage of where we are, we are IN W3C, we have access to some of these groups we need to ask questions of and we need the support of CSS, what wig like the way we get that support is by putting together clear requests and
… reaching out to those groups
… and saying we need this, what do you know about it?
Laurent Le Meur: we tried with CSS regions to support [...] well they said you should spend 3 years in the CSS group and you might get a solution, so asking is not sometimes enough
Wendy Reid: fair point but we have to at least document our requests
Matt Garrish: minor point, I didn't hear it mentioned but ACE has been translated into Japanese and the knowledge base is also translated so there are resources to help with making content accessible
Wendy Reid: that's huge, didn't know about that, but the flip side about us needing to reach out and be clear is that we have a lot to offer to other groups, as an example: I have been struggling with working on how to write requirements for Text a11y for different languages, different typographical requirements for line spacing, character spacing,
… and there's no resource online but we happen to know many publishers in a lot of countries that have done research into best practices for or know people who konw
… it goes both ways, as an example for Japan if there are WCAG a11y guidelines that don't work for Japan we should know so we can improve that and keep it bidirectional
Shinya Takami: maybe matt said ACE was already translated to Japanese, maybe interfaces but only ACE cannot be evaluated for conformance to WCAG single A
… so we have to check by human for the conformance to WCAG so its hard for japanese publishers to check conformance
Matt Garrish: just pointing out it is a means of automating the checking so a person doesn't have to check everything, certainly there's more you have to do if you want to claim conformance
Tzviya Siegman: can you explain why it is WCAG A and not double A?
Shinya Takami: because the WCAG A11Y spec at least ... double A is more difficult to adopt in Japan
Charles LaPierre: I assume you mean for the WCAG Double A because reflowable vs Manga, manga is the main issue with meeting WCAG AA?
Shinya Takami: yes it is about Manga
Charles LaPierre: was Smart also translated into Japanese because that will also help with conformance checking because ACE shows the visual confirmation of the alt text being good or not
… so you need to have those humans
Matt Garrish: the project was only for converting ACE but not SMART because it is more complicated. we did french but it didn't happen, it takes a lot more work and time
Shinya Takami: let me correct the previous questions: we are not talking about Manga for WCAG adoption
… for Japanese reflowable contents Double A is too hard to adopt, many publishers thought
Wendy Reid: we are talking about standard novel reflowable content
Shinya Takami: yes
Motoi Suzuki: I'm Suzuki from DPFJ, Japanese sorry, relating to a11y regarding Japan compared to north american a11y government ...
… clearly what is happening is there are clear differences between EU / North America / Japan regarding regulations and what the authority is
Motoi Suzuki: currently in Japan the A11y guideline is still under development
… until that is finished Japan with regard to EAA can't
… it is difficult to look forward to working on a11y compliance in Japan with each publisher as we have to have some collective guideline to comply with the international requirements
Motoi Suzuki: regarding manga, a11y is quite difficult, but including that, DPFJ position is that we want to work with the various Japanese publishers to comply with international a11y standards,
… with the complications of Manga content to comply with a11y requirements, it won't be an easy step but DPFJ will work with the publishers to make it possible
… at this group PMWG and also w3C and other publishing groups the DPFJ together with you guys would like to find a way to step forward with the a11y requirements
Wendy Reid: I think there's I understand that there's different challenges with a11y particularly is there are different legal standards
… WCAG is not a law, but there are countries like the US that have made the WCAG into their law
… but the idea with WCAG was always that if you conformed then it would benefit the most people as possible, the same position with EPUB was to help as many people as possible
… to give an example of a country with no legal requirement but that has major strides is Canada
… however the government has spent a lot of money to help publishers to convert content so that they can sell better on the international market even a small 2 person publishing house can then be successful in europe in education
… because the government saw that it was worth putting energy into making the content available
… and maybe that's the way to pitch this to publishers in Japan now, that if you get ready now even if the law changes later to require it then you would be in a good place because the content would already be ready
… but if there are places the standards don't provide what Japanese content needs please let us know so we can fight to improve the standards
Laurent Le Meur: you said what I wanted to say, we are in an assembly to collaborate
… so for reflowable content, we can infer shared experience and fill the gaps between what can be done today and what WCAG a11y requries
… as we said Manga doesn't work today but we can share what we want to do for the future
Wendy Reid: this conversation has proved fruitful to see what areas this working group can take on work in the future, a lot of these issues are mirrored not just in Japan, but Taiwan, europe, elsewhere. TTS pronunciation even affects english
… it would be helpful in a future meeting to dedicate to proposals we should take to other groups. TTS particularly has come up as there is not standard clarity around how it is supposed to work, I don't know if it is our problem to solve but we need to figure out who we need to work with to solve it and we have more discussions to have
Hadrien Gardeur: we know that the TTS issue is bigger than reading systems so the way we at EDR lab and Readium to help is to work on this as a separete project I documented all the TTS voices across browsers a year ago and there were about 600 voices at diffrerent qualiities, genders,
… in use on some projects today
… now we are working on readium speach that is useful for people who want TTS on the web generally to try to work around the edges of different browsers and OSs, to eventually potentially connect this whatever you want, even with your own models or proxy services, potentially used anywhere
… we hope this project will make things easier but also that we can make things better by working with others and working beyond publishing as this has more potential than that
<Ivan Herman> s/thepublisher/the publisher/
Updating Publication Manifest
<Ivan Herman> Presentation slides
Wendy Reid: let's talk about Web Publication Manifests.
… there is a W3C version and a Readium version. There are subtle differences. More implementations on the Readium side. Time for us to bring them closer together, and make sure that the spec is in good shape.
Hadrien Gardeur: presentation of how Readium Web Publications are actually used.
… History: starts with the AHL WG in 2012. Objective = do renditions differently.
… Then for EPUB 3.1, Browser Friendly Format (BFF). Two different approaches: HTML (Dave), JSON (Hadrien). There were prototypes.
… in 2017, the Readium people defined the Readium Web Publication Manifest. It was for a SDK we called Readium 2 at the time, which became later Readium Mobile. Objective: hiding differences between different types of publications (EPUB 2, 3 ...)
… in 2018, profiles of Web Publications for audiobooks and comics (Divina, Digital Visual Narrative).
… Same JSON base structure used for catalogs of publications = OPDS 2.
… 1) RWPM as an internal format for Readium toolkits (Mobile on iOS and Android; Web; and Desktop). Conversion to RWPM (Readium Web Publication Manifest) in the reading app. Parsing (from interchange formats implemented in Swift, Kotlin, Go, Ts).
… More than 200 mobile apps are using Readium Mobile -> RWPM.
… 2) Gained adoption as a distribution format -> audiobooks (stream or download) with a package format and LCP support.
… Also used for protecting PDF with LCP.
… Recently, interest in its generic profile, in the education world, by Brazil and UNICEF, due to limitations of interactivity in EPUB (due to other expectations like pagination and user control).
… 3) As an archival format, by the Korean government, for archiving webtoons, along with a new identifier to avoid using a large number of ISBN. Felt that EPUB was too complex for their need. Turned RWPM in its Divina flavour as a national standard (TTA). Now testing the water as an ISO standard.
… 4) As a pivot format. Presentation made this year by Hachette at the Digital Publishing Summit (EDRLab, Dublin). They want to create a digital-first workflow, using RWPM as a pivot format before sending to print and EPUB production.
… The print version of reflow publication can be automatic. FXL publications can be done via import of the RWPM in InDesign.
… 5) As a workflow format. As an easy way to support extraction information from EPUB files. Now in Readium CLI (Command Line Interface), which can generate a Manifest on the fly, and can be used as a publication server.
… As a serve, it can stream an EPUB file from an Object Storage and server Web Publications for feeding the Readium Web reader.
Wendy Reid: the W3C Audiobook format is also used as a pivot format by some organizations.
… the question is now, how do we align the specs?
Hadrien Gardeur: however, the primary use case for RWPM is delivering audiobooks to users. Sometime hidden by an app or an OPDS feed.
Ivan Herman: there was an influence coming from Readium, it is a pity that the 2 things diverged.
… The main differences between the two seem to be. The HTML TOC (and the primary page).
… The other differencies are unfortunate.
<Wendy Reid> See W3C Publication Manifest:
<Wendy Reid> See Readium WPM:
Ivan Herman: if the goal is to merge, i.e. make a new standard, two questions: is it in the interest of Readium to make in a W3C standard? And a new version that in backward compatible (1.1) seems impossible; so it would be a 2.0.
Shinya Takami: Can the RWPM replace the OPF file?
Hadrien Gardeur: it was mainly designed as an internal format.
Matt Garrish: the W3C spec was generic and has flexible constraints (TOC...). The RWPM seems more specific.
Hadrien Gardeur: yes, some of the goals were different. We wanted to hide the complexity of formats to RS developers. However the W3C focus was dealing with publication that "live on the web". But the web is probably good enough without it.
… People have found new use of RWPM over the years.
… There are some differences. The W3C spec does not require a media type, some in naming, dealing with languages, duration format ...
… Korea has made it a standard. The Readium community does not see a problem with it.
… NISO is interested to use it and push is to ISO.
Wendy Reid: There are sutble differences between the specs. If there are no breaking changes, or a way to break them gracefully, because W3C WPM are really flexible, we can study if we can make a profile of W3C WPM.
Ivan Herman: looking at the large adoption of the RWPM, any breaking change to it will not be unacceptable. If we create a W3C version, we'll have to adopt the syntax of the RWPM where it is different.
… we will create a different version, not an incremental change.
… We also have to check if the charter allows for a major version.
… We cannot decide right now if we start this work.
Hadrien Gardeur: the RWPM can use an HTML TOC, but nobody is using it, as there is the JSON TOC in the manifest.
… some features like string direction, have been also challenging in EPUB.
Wendy Reid: next step is to study the differences between the 2 specs.
Ivan Herman: I'm happy to work with Laurent for updating the tables he initially wrote.
HTML in EPUB
Wendy Reid: Welcome TAG! There has been a long standing question in epub whether we should add the HTML serialization to epub in addition to XML
… this year we sent a survey to see what people think
… we got a very interesting set of responses
… [presenting doc with results summary]
… 4 questions, first was who you are
… we got very broad results, creators or epub, open source devs, conversion providers, some users, some for-profit vendors/publishers which was very different from open source
… some edu, some RS, some XML experts
… Then question 2 was benefits and challenges, if we were to do this what are the pros and cons
… we got a lot of interop feedback, one of the most important things
… we got feedback about from different angles. Some people gave some features as a pro, others gave the same html feature as a con
… we also had wild conjectures
… a lot about the level of change (epub4 or a different profile)
… a lot of responses about cost
… question 3 was what steps should we take to make it easy
… this had a lot of feedback about epub4 or some sort of a flag
Wendy Reid: I tracked positive/neutral/negative sentiment
… there were a lot of comments about providing documentation about what is available in practice
… some people that responded didn't know about existing features (e.g. please provide a validator)
… some people skipped the intro and thought we were getting rid of xhtml
… then the final question was open form
… a lot of people asking for best practices
… even asking for a permitted subset of properties/elements
… basically asking for advice on how to make books
… that was the messy version, here is the cleaned up one
… in terms of points in favor, things like longevity since it would ensure epub would continue on
… also like tooling, integration, getting closer to web platform, even new features, new workflows, new types of content
… there was also comments about bringing in new people
… and integrating more modern a11y, design, etc that has appeared on the web in the last few years
… against was complexity, more content errors, current tooling would need updates, not fully supported on all RSes, old books may not work on new readers
… don't want to change tooling
… Some people from watermarking claim it will destroy their business
… a11y was a pro and a con, might be better, might be worse
… Request for feature coverage, update epub check
… suggest to do it in Pub Manifest, or a new profile
… Help with tooling, maybe native epub support
… could new epub reading systems be html only
… maybe watermarking won't work
… there is slow adoption, epub 3 barely passed epub2
… but that is why we are discussing this now
… Older RSes may not support this content
… we got some responses from XML people asking us to push XML forward in the html community
… These are the results, all very interesting
Magnus Rudolfsen: What was it used for?
Wendy Reid: DRM
Magnus Rudolfsen: I created watermarking for a company, it would break in html, but it could be fixed
Wendy Reid: This was about breaking workflows
Magnus Rudolfsen: They are probably right, it would break it
Ivan Herman: One interesting thing in the comments, there were several responses that showed the community believes we are still using xhtml 1.1
… so people were upset about the new features of html 5 appearing in content
… they didn't realize that epub 3.0 already made that change 15 years ago
… which casts a very strange light on the responses
Hadley Beeman: I am glad you did this research
… what can we do to help? We get involved when there are issues that impact web, or big picture interop
… or if a group wants a particular question answered
Wendy Reid: I think it is the latter, this is a big architectural change
… we would like an outside perspective, are we missing something, has anyone else ever done something like this?
Laurent Le Meur: from the results of the survey, etc, the issue come from both extremities. Producion and end user display
… everyone in the middle seems fine. Distributors, aggregators, etc are happy with html
… on production side there is a hope that there may be something more shiny
… on RS side, people are worried about breakage
… they are both wrong. On prod side, If you want to use html, there are plenty of ways to transform it
… on RS side, you can just use XSLT to convert
… so is there a need in the future to support html
<Gregorio Pellegrino> +1 to Laurent
Laurent Le Meur: I think we shouldn't touch epub, and examine the extremities
Hadrien Gardeur: I have a different take. for instance in Brazil they have decided to not use epub. Why?
… a lot was UX. They felt epub was giving away control as the producers and giving it to end users
… they wanted more complex or responsive layout, or interativity
… the only thing they like about epub is packaging
… they like that part, not the rest. They don't like pagination code
Hadrien Gardeur: I know it is different, but it is interesting to see why people have changed
Hadley Beeman: I was in govt for a while, we tried to move them from PDF to html
… they wanted to control it all, and look like essentially print
… we had to explain that they were making it harder for people to use
… in that context, they were articulating as benefitting themselves, not their users
… is that what these people were saying?
Hadrien Gardeur: Not really. They felt they had more control with html, since it avoids the RS from messing with things
… they actually prefer web pages better, the only issue for them is packaging
… so it is kind of different
Jeffrey Yasskin: I don't think we have an answer
… it seems the main benefit is that it becomes easier to create epubs in the first place
… That is an uncertain benefit. The main downside is making implementation harder
… So which dominates?
Brady Duga: There is a different, there are some libraries that don't work, no new features are going into the XML serialization, but don't know what is going to HTML though
Gregorio Pellegrino: ShadowDOM
Jeffrey Yasskin: another question is is there something you can do in html but not xhtml? [this goes earluer]
Gregorio Pellegrino: it is an issue more with format than serialization
<Hadrien Gardeur> +1 to what gpellegrino just said, it's about UX/features/expectations tied to formats
Ivan Herman: what jyasskin said, I would turn it back to the TAG
… how serious is the concern that if we do not make this move, that we fall behind because the html world leaves us behind?
… there is a negative feeling in whatwg to xhtml
… this evolution was a main trigger
… ifs the fear is overrated?
… I am not sure about jsdom and such. I don't think parsing is the main issue.
… I think in the xhtml community, new apis are made by explicitly ignoring the xml versions
Jeffrey Yasskin: I doubt browsers will remove xhtml serialization
… but if there are new features they will only be in html, so new features in parsing won't be in xhtml
Wendy Reid: I think the slowness is why we are discussing it now
… there was some worry that we would switch, not add
… some tangible complaints are technical quirks like entities
… common validator error is incorrect entity usage
… the other area is around scripting
… the current rec is don't script, but people really want to
Dan Brickley: I want to ask what this means for embedding things like SVG and mathml.
Wendy Reid: We don't really say much about that. Things have gotten better recently
Dan Brickley: and html method would be ok?
Wendy Reid: yes
<Gregorio Pellegrino> +1 to Hadrien Gardeur
Hadrien Gardeur: What people want from html is often different from what you would get from epub
… so two formats can actually help make that clear
… what is important is making clear what to expect
… switching to html won't make scripting better in epub
… I know this is a big sidestep, but I don't think mixing the two will work
<Jeffrey Yasskin> https://
Jeffrey Yasskin: I did remember one feature where they decided not to add a feature to xhtml. It was about `defer`, but that probably doesn't apply to epub
… but browsers likely won't support them in xml
Brady Duga: Wanted to add one quick thing, many of the reading systems don't actually display XHTML, they display HTML, XHTML as though it is HTML, the stuff inbetween is a lot of XML parsers
… new features would probably still work, some people have their own engines, but it may not be that big a deal
Wendy Reid: we have discussed this a lot over the years
… I went into this thinking we should add html. After looking at the results I have changed that opinion
… I think we should do that elsewhere. Not that we are discussing pub manifest, maybe it is time to introduce a more modern web adjacent format
… pub manifest is probably the place to do it, and html is probably the tech to use
… at the same time keep epub stable
… I think it is time to go on a different pathway
Hadley Beeman: Do you imagine the use cases evolving?
Wendy Reid:
yes
Wendy Reid: yes
Hadley Beeman: how?
Wendy Reid: There is a desire for more interactive content, linked content, offlineable
… so there is a lot of good things in epub, but there have been a lot of huge changes that we don't take advantage of given the older constraints
… it is time to revisit the use cases
Hadley Beeman: does that mean the dev base will grow?
Wendy Reid: yes
Hadley Beeman: So the people you talked to may not include them? That is important to remember
Wendy Reid: yes there would be new devs
Hadley Beeman: You need to keep that in mind, you can grow the dev base
Jeffrey Yasskin: There is a bigger problem around scripting. Are you all talking about what scripts work?
Wendy Reid: No. People want that, though
… we need to be clearer, but we will never get to defining scripting
Jeffrey Yasskin: I don't mean specific libraries, but rather what generally works
Ivan Herman: we have to make a decision.
<Jeffrey Yasskin> "Yes" or "maybe later"
Ivan Herman: and we are running out of time (looking at the clock)
… I agree with Wendy Reid, I don't think we should change. It is futile to do it
… the discsussion about the web manifest recalls web manifest, which was a disaster
… looking back, one of the errors was to consider that the big publishers would jump on it
… that was a naive assumption
… if we create a new version, the goal has to be different
… big publishers are happy with epub, we maintain it and keep them happy, then find a new community that wants html
Matt Garrish: If we do go to something else, and don't abandon epub 3, then we end up duplicating everything
… The easiest way is probably to fiddle with the version numbers, but then we pull a lot of baggage forwar
… at some point we have to make a decision. Otherwise we just spin in circles
… If we stay with xhtml we lose the html people
Brady Duga: I don't like the idea of messing with version numbers, if we have an EPUB4 "that is the future", that doesn't have XHTML, people will be mad
<Ivan Herman> +1 to Brady Duga
Brady Duga: if we want to do something new or different, it should be a new spec, it shouldn't be EPUB4, I think we need to find an audience first
Jeffrey Yasskin: there is some interest in packaging from browsers
… chrome has isolated web apps
… that could be use for other things, but I don't know what the appetitie is
Hadley Beeman: If you put the html in a different spec, then you are clearly fragmenting
… then you add a lot of complexity
… if you plan to do it, then do it at one go and don't have multiple specs
Jeffrey Yasskin: I would say don't do that, don't have a new format
Wendy Reid: I think the decision is we won't do html in epub 3.4
PROPOSED: We will not add HTML serialization to EPUB 3.4
<Brady Duga> +1
<Gregorio Pellegrino> +1
<Ivan Herman> +1
<Charles LaPierre> +1
<Shinya Takami> +1
<Laurent Le Meur> +1
<Wendy Reid> +1
<Hadrien Gardeur> +1
<Masakazu Kitahara> +1
<Romain Deltour> +1
<Toshiaki Koike> +1
<Ivan Wong> +1
RESOLUTION: We will not add HTML serialization to EPUB 3.4
Ivan Herman: we should communicate this somehow
… including the rationale for the decision
Wendy Reid: Yes, we will blog post
… and thanks to the TAG for proposing some questions
Issue Clean-up
https://
Wendy Reid: However long we last we can review the issues
… just do some general cleanup since we have discussed a lot of these issues
… Success would be covering all the rendition properties
Hadrien Gardeur: I also think the whole FXL with a reflowable alternative is worth discussing
Wendy Reid: Where to start?
Hadrien Gardeur: I have a bunch of open issues
Wendy Reid: Do we want to start with layout overrides?
Hadrien Gardeur: That might be a hard one
… I would start with the flow one.
… maybe #2754 or #2750
rendition:flow issues #2750 and #2754
https://
Hadrien Gardeur: One thing we have now (for rendition flow) is to provide a hint how reflowable resources should be presented
… you can say auto, paginated, or scroll
… this is problematic because authors shouldn't have control over it. And it shouldn't switch mid book. Also, no one does 2 types of scrolling
… since these have been used in Japan, we have to be clear that the current undefined use should be documented as equivalent to roll.
… but otherwise we should drop them
… So once again this mean moving to deprecated, etc
Ivan Herman: I did the a different PR, the question of tests came up. Do we need deprecated tests, or just remove them?
Wendy Reid: I would say for the tests it might be appropriate to have a deprecated test suite as examples or demos
… so RSes can use those tests
Ivan Herman: We would need to figure out how to do that, but that is for later
Hadrien Gardeur: I don't think this breaks any reading system, since it is so poorly implemented
Wendy Reid: We actually had passing tests
… looks like it was for ignoring the property
… scrolled doc and continuous both have passing tests
… on collibrio, thorium etc
Hadrien Gardeur: I am surprised since thorium has no scrolled mode
Ivan Herman: I remember reading some books that did scrolling per chapter
… I remember having read it in Thorium, no idea how it was marked up
… but at least one example where scrolled-doc was used
Hadrien Gardeur: Most reading systems let users paginate or scroll. Scroll is either per doc or continuous. So Ivan had a book that forced scrolled behavior even though he didn't set it
Ivan Herman: Correct
laurent and Hadrien Gardeur: [Arguing over scrolling]
Ivan Herman: Looking back it included a lot of code, which is often bad with pagination. So not wanting to paginate is better
Wendy Reid: Thorium 3 it no longer works, but it did in 2.2
… the core question is do we deprecate the rendition flow at meta and item levels?
Hadrien Gardeur: That is my opinion
Ivan Herman: The reason we propose it, is it because it is wrong to do it, or because it is unused
Hadrien Gardeur: It is both
… If respected it can be harmful
… forcing scrolling or paginated is not put at the top. It is bad on multiple levels.
… it is bad for UX and accessibility. And it is bad to have something we don't use
Brady Duga: I remember when we added this, some people liked it, the point was to tell the user what the original thing was, this is the Torah, it was originally scrolled
… a hint to the user
… I think we have now confused what it means to what it should switch to, this is how this content must be displayed, and that was not the intention
… add to the reasons to deprecate, confusion over what these properties mean
… at least, it is under specified
Wendy Reid: I think, to duga4 when we added the renditions properties, was to allow the publishers to give hints to the RS
… the problem being we never specified what that hint was supposed to look like
… So RSes displayed it one way, then users wanted it different
… We now have hindsight and user information. Readers will tell us what they want, and how they want to read something
… if we want to allow publishers to provide these hints we need to explain to RSes what that means
Ivan Herman: It seems we have a more general thing than these properties. Personally I am more in favor making it clearer in the spec
… Make it clear this is a hint
… just removing it is pretty heavy handed
… which brings into question our decision from yesterday
Shinya Takami: I don't know the use case for scrolled doc, but in ancient time in Asia we had the rolled document
… we don't have those now, but we use scrolled continuous for webtoons
… the current spec must ignore the scrolled continuous in fixed layout
… I don't know what the use cases are for such scrolled properties in Japan
Hadrien Gardeur: So as ivan says, for consistency we should treat this the same way
… Even if we clarify it, there isn't really a way to properly support it
… so no one will support both types of scrolled
… As to a hint, I think it is better to just write it in the book
… that way there is no annoying UI
… One example is manga in the west, where it explains to read right to left
Gregorio Pellegrino: To what Ivan said, orientation in FXL, most reading system doesn't allow the user to unlock, if its set, it can't be changed. With scrolled it is up to the user to change in the settings
Wendy Reid: to your point, in my experience, we would do the thing where we showed it initially, but if you turned the phone we would switch to portrait
Hadrien Gardeur: and some RSes have one type of scroll, others have only the other type
Laurent Le Meur: only looking at w3c rules, it shouldn't be in the spec since it is under implemented
… if it is not implemented by now, then it should go
… and if it is a hint, then it really shouldn't be allowed as a spine override
Wendy Reid: I think we set precedent with the orientation thing. Maybe we should decide what our philosophy is
… is it the user and their on device prefs, or do we want to empower the publisher to provide their own guidance
Ivan Herman: As co-editor, anything that makes the spec simpler is good for me
<Shinya Takami> +1 to Ivan Herman
Ivan Herman: I don't know how many properties that is
… so it means deprecating quite a number of properties
… so smaller is better for me (simpler)
… As far as removing we have to leave them for backwards compat
Hadrien Gardeur: That's fine
Ivan Herman: A book with these should still be conformant
POLL: Do we think that EPUB should 1) Prioritize user reading preferences for content appearance and reading experience; OR 2) Continue to provide publishers with the rendition properties to declare initial rendering characteristics for books
<Wendy Reid> 1
<Brady Duga> 1
<Hadrien Gardeur> 1
<Shinya Takami> 1
<Masakazu Kitahara> 1
<Toshiaki Koike> 1
<Ivan Herman> 1
<Marisa DeMeglio> 1
<Romain Deltour> 1
RESOLUTION: EPUB should prioritize user reading preferences for content appearance and reading experience
Hadrien Gardeur: this will affect some other properties
Ivan Herman: Instead of going through one at a time, can we have a list or such properties
Hadrien Gardeur: Yeah, I would spreads in but not layout
Ivan Herman: Just put in a separate all the items that should be closed from this decision?
Hadrien Gardeur: Yes, I will take that as an action item
ACTION: Hadrien to open issue outlining which rendition properties need to be changed
Ivan Herman: There is a pr I made yesterday. Maybe I should expand it or do a new big one
Wendy Reid: Expanding makes the most sense to me
Ivan Herman: ok
Layout Overrides - w3c/epub-specs#2749
Wendy Reid: Next is layout override
… this is how we can have mixed reflow and prepaginated
… this is a tricky one, because we have a solid set of use cases and idea
… There are reading systems that support it
… there are a lot of RSes that can't/don't implement it
… there are probably better solutions
Hadrien Gardeur: I think layout override is problematic as it can create complex UX problems, and it doesn't solve all the problems
… I would keep this at the resource level, but not in the spine, and I would limit it to things outside of the spine
… so I could have a link to a reflowable from fixed or vice versa
… I don't think we need mixed fixed and reflowable when going cover to cover
… this is what we need for magazines and textbooks
… what we have no is problematic and we should explore other options
Shinya Takami: We use this feature in e.g. light novels
… There are often some pages that need to be fixed for precise layout
… at least kadokawa uses this feature
Ivan Herman: shiestyle gave an example that I was thinking about. So something complex in the book that needs to be specified exactly
Laurent Le Meur: I wonder in this case how RS ui can be consistent, particularly if the first part is paginated
… so you will have one pagination, then you have something that is fixed, do you have to invent blank pages? How do you get a consistent reading experience?
Shinya Takami: When the spread mode happens, we don't expect the reflow pages to be on the screen at the same time
Laurent Le Meur: So you have to finish one, then show the fixed page, then switch back
Wendy Reid: The question points to something interesting, and maybe we don't need to get rid of this entirely
… maybe they work better in one layout than the other
… so going from fixed to reflow is hard, but going from reflow to fixed may be easier
… so can you go the other way?
Shinya Takami: Yes, sometimes
… sometimes split view is required
Laurent Le Meur: It would be interesting to see a sample, and it would be great to have a test donated to the w3c
Hadrien Gardeur: So LaurentLM thinks it is hard one way, but I think it is hard the other way. So say you have it set to scrolled, then you hit a fixed page, what do you do?
… the only use case so far is full bleed images
… is this the only way to do it? Or can we do it another way?
… and finally we should do this at the manifest level, not spine
… so I am very interested in exploring the move from spine to manifest
Wendy Reid: There is a test, mixed results
… not sure if we can decide today
Brady Duga: I agree
Hadrien Gardeur: I did warn in advance
… maybe a resolution would be better spec language?
Ivan Herman: Yeah that is one way, another is more detail about moving to the manifest level
… so maybe deprecate this and move, though that may be a problem if it is currently in use
… maybe put in a proposal to move this to manifest
ACTION: Hadrien to make a proposal about manifest level properties
Hadrien Gardeur: So an action item to me?
Hadrien Gardeur: So move to manifest?
Wendy Reid: Yes, and maybe perceived benefits
Hadrien Gardeur: Looking at the remaining things we are mostly done
… we could move to alternatives, or maybe to how to idenitify AI generated content
Ivan Herman: Hadrien what is the status of roll? It is a pr? Pending on images in spine which is now resolved
Hadrien Gardeur: roll document was blocked, but now that we have an answer I can rework it to adopt the decision
… so there is still work, but we are no longer blocked
… give me some time, as I am travelling for a few weeks
AI contributions to ebooks
Wendy Reid: Since it is pertinent, let's talk AI
Wendy Reid: ONIX has AI contributor, you can say which parts are AI generated
… so for us we are talking epub metadata, we don't have to follow ONIX, but we can copy a bit
Hadrien Gardeur: A lot of this is opf metadata, so we could just refine everywhare
… I don't think would work for alt text, though
… we might need something in the markup
… I don't know if we can just use OPF info. An image could be listed once in the OPF but appear multiple times with different alt text
Ivan Herman: Speaking about markup, I would be very hesitant for us to do that
… we need someone else to do it, then we just use it. We can ask for it, but we shouldn't do it ourselves
… I don't want to repeat epub:type
… for the metadata, yes of course
… do we want to replicated, or just directly refer to onix?
… why reinvent the wheel
Wendy Reid: I agree. if we think this is important enough, then we should discuss with AGWG
… I don't want to have it repeated that AI generated this all the time?
Hadrien Gardeur: Could just be a one time warning
Wendy Reid: Who is the intended audience?
Hadrien Gardeur: I think it is interesting for both. For production it can helpful to know if the desc was authored or generated
… so good to know if a particular entry was authored or generated, and whether it was checked
… I think a lot of the publishing community is shooting itself in the foot
… For instance, in the future it might be better to ignore the AI generated text as on-device becomes better
… and for users it is very important. This could impact my purchasing decision. I may not like AI voices, or I may just not like AI in general
Laurent Le Meur: About the production use case, for small publishers they don't have a big database, they just send it to a service. If it doesn't get saved in markup it will be lost
Wendy Reid: We could make a proposal, then share it around and see if people agree
… we can address the reader metadata, but for the other side we need broader concensus
Ivan Herman: In a broader level you might want to talk to Dom or Roy as they are involved in AI
Wendy Reid: on the reader side, I might want to know when things are AI generated. For instance, some books have AI generated images that may be wrong.
Laurent Le Meur: Human generated content can also be wrong
Hadrien Gardeur: The people who are doing that probably won't label it correctly
Gregorio Pellegrino: Just to say there is a movement in Europe to explicitly say when AI was used to generate content
… this may appear in 2026
Ivan Herman: What is the status of this onix? Is it exploratory?
Hadrien Gardeur: It is definitely used now in onix
… and several orgs recommend using those codes
Ivan Herman: Maybe we can informally reference this spec
https://
Wendy Reid: There is a list of unnamed persons that includes AI
Hadrien Gardeur: The concept of unnamed is interesting.
… but I always worry about pointing at onix since it is very foreign. It is very at odds with epub metadata
Ivan Herman: Yeah, but we already do that
Hadrien Gardeur: Yes, but that is our least used metadata
Ivan Herman: The only other option is to come up with our own vocab
Hadrien Gardeur: Yes, that is also a problem
Wendy Reid: We should open an issue for this
… and then we can see if people want onix, or something custom, or something else
Hadrien Gardeur: There have been synthesized voice issues
… we probably need to look back and create an umbrella issue
Wendy Reid: Ok, we will open an issue and go from there
… Thanks everyone for a very productive few days
… we will follow up with our TODO items. No meeting next week, reconvene in two weeks