EPUB 3 Working Group Telco — Minutes

Date: 2020-12-04

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Juliette McShane, Tzviya Siegman, George Kerscher, Zheng Xu (徐征), Wendy Reid, Toshiaki Koike, Matthew Chan, Masakazu Kitahara, Ken Jones, Gregorio Pellegrino, Brady Duga, Bill Kasdorf, charles, Charles LaPierre, Avneesh Singh, Garth Conboy, Hadrien Gardeur

Regrets:

Guests: Dave Cramer

Chair: Wendy Reid

Scribe(s): Matthew Chan

Content:

1. Core Media Types

See github issue #1344, #1299, #645.

Wendy Reid: we had discussed this back in sep. that we would vet them one at a time
… we’ve tried to add some ones
… but run into issues with things that are implemented, but not standardized

Dave Cramer: the general question here: We have 2 competing principles. 1 is supporting what the web supports, and we hope that epub will maintain compatibility with the web.
… 2. but epubs also must work. e.g. someone who buys a book should be able to read it on their device
… an issue esp. because older RSes are still out there
… e.g. I made a little test of webp inside an epub, and it only worked on 50% of the RSes it was tested on
… we could give up on the idea of core media types and just leave the decision to content authors, but that could result in a bad experience

Ivan Herman: we have already made the similar decision in terms of css
… e.g. whatever css can do, it is fair game for authors

Dave Cramer: i think css is different. CSS has very well defined fallback behaviour. Not true with, e.g., new media type in epub

Tzviya Siegman: +1 to dauwhe about fallbacks

Dave Cramer: with CSS, the reading experience may be degraded, but not entirely lost
… there’s also lots of experience out there about writing CSS that works even if certain features aren’t supported
… not exactly the same with EPUB

Ivan Herman: +1 to dave’s response

Brady Duga: agreed
… in terms of modelling epub after CSS, 90% of the issues I fix are to do with CSS not working. So not enthused about using the same model for media types

George Kerscher: where are we in terms of video formats?

Wendy Reid: with video, we’ve also taken an “open approach” i.e. just use what the RS accepts
… h264 encoded is probably the standard?

George Kerscher: i think the lack of clarity around the video is holding us back. People would love to see video in epubs

Dave Cramer: video is tricky because there are even brand new devices that won’t support video - eInk!

Wendy Reid: also, some platforms have upload sizes that make video incompatible

Avneesh Singh: this is a problem i see with both video and audio in epub. The larger the file size of the zipped file, the greater the chances of corruption after download
… going back, we said that epub 3.3 would not be a major revision. And we only have 1 year to finish the spec.
… recall our experience with epub 3.1. The publishing industry, unlike the web, is slow to move to new standards

Dave Cramer: a lot of the trouble with epub 3.1 was with epubcheck not being available (although the spec also had its own issues)
… i think we should keep core media types
… and maybe periodically consider new media types as the underlying technology evolves
… and i think this discussion shows that that decision comes down to the specific media type under consideration

Ivan Herman: i’m okay with what Dave said, but what are the criteria when we decide that something becomes a core media type?
… earlier there was a request that webp to become a core media type, which we accepted without lots of discussion, but now (I believe) there’s still an open PR about it

Bill Kasdorf: when we originally created core media types, we still allowed the use of other media types, just with the caveat that the author must provide a fallback, true?
… yes, okay

Hadrien Gardeur: but we shouldn’t always assume that there will be a working group to oversee the question of core media types, especially with newer media like video/audio
… perhaps we can have a normative document where we would retain the capability to update it when we need to (i.e. between working groups)

Garth Conboy: we currently have a list of types for image, a list for audio, and a vague suggestion for video
… but I don’t think the current state of support for video is broken right now
… about what Hadrien said, maybe it could be an external vocabulary document?

Garth Conboy: See the relevant section in the 3.2 spec

Ivan Herman: about Hadrien’s point, 1. The new process at W3C will make these types of updates much much easier. Under the new process we can update the spec if there is committee agreement.
… 2. But we also have the option to separate the media type into a separate registry. The W3C will have a more formal way to update registries in the future.

Brady Duga: I like the idea of pulling out the media types to a separate location rather than having them buried inside the main spec
… re. Bill’s Q about fallbacks. The specific issue with webp is that webp makes images smaller. If authors had to provide fallbacks when using webp, that would kind of defeat the point (by expanding the epub size)
… there seems to be some disagreement about how to add new core media types

Avneesh Singh: we already tried what Hadrien suggested in epub 3.1, but then with epub 3.2, we put it back in
… externally incorporated documents created additional issues when it came time to take 3.2 to ISO
… maybe we could ask Makoto whether whatever we decide here will create an issue for ISO

Dave Cramer: yes, external registries have definitely been an issue for specs in the past
… and audio and video formats are more amenable to being remediated by fallbacks than images (the fallback can even just be text)

Ivan Herman: to wrap up, we seem to be converging towards the point of not changing anything for now
… we keep core media types as they are today and move on (and perhaps changes in the W3C processes will make these easier to maintain going forward)

Wendy Reid: yes, we want to keep core media types, and we will wait and see about the idea of using external registries
… esp. given that how registries will work in the future is still being sorted out
… and the Process 2020 will allow us to make piecemeal modifications to the spec without revisiting everything
… we’re still in favor of adding webp, we just need to work out the implementation issues around webp

Proposed resolution: EPUB 3.3 will keep the concept of core media types as it is today. (Ivan Herman)

Ivan Herman: i think webp is a separate discussion

Tzviya Siegman: +1

Ivan Herman: +1

Matthew Chan: +1

Brady Duga: +1

Hadrien Gardeur: 0

Wendy Reid: +1

Garth Conboy: +1

Charles LaPierre: +1

Juliette McShane: +1

Avneesh Singh: +1

Toshiaki Koike: +1

Bill Kasdorf: +1

Masakazu Kitahara: +1

Garth Conboy: and for video, we’re going to keep it as it is for now - i.e. no specific type, just a suggestion

Hadrien Gardeur: isn’t that an inconsistency? There’s core media types for some types of content, but not for video?

Dave Cramer: In the past that was because video types were evolving so quickly

Hadrien Gardeur: Images seem to be evolving quickly today

Dave Cramer: In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

Resolution #1: EPUB 3.3 will keep the concept of core media types as it is today.

George Kerscher: +1

Wendy Reid: Well with image elements, there are a robust assortment of image fallbacks

Gregorio Pellegrino: +1

Brady Duga: Let’s please try to keep substantive discussion out of the irc chat. Let’s keep the irc chat just for metadata about the meeting only please!
… everyone may not be closely watching the chat log

2. Removing multiple rendition from core spec

See github issue #1436.

See github pull request #1438.

Wendy Reid: multiple rendition is not widely implemented, and people have mentioned that references to it complicate understanding of the core spec
… we can remove references to it from the core spec, and have it live as a satellite document outside the spec

Dave Cramer: I think of multiple rendition as an extension of epub only. The way we’ve had to write the spec because of this remote possibility has degraded the readability of the spec
… and multiple renditions have always been optional
… therefore multiple renditions should be epub adjacent, but not a core aspect

Ivan Herman: Referring everyone to the discussion in the PR
… some Japanese RS and content does use it
… Matt’s PR: Took the core spec and removed references to multiple rendition from the text. Not removing the technical possibility of having multiple renditions.
… it may not have been clear from the PR that the intention was to have guidance about multiple renditions exist in a separate document
… we are not removing anything that was previously possible under the spec, just editing the spec to make it more readable

Garth Conboy: i support getting language about multiple renditions out of the core spec, while still allowing the possibility of multiple renditions

Gregorio Pellegrino: from an a11y point of view and a EU a11y act point of view, multiple renditions could be a way to meet requirements. Therefore multiple renditions make take on a greater importance in future.

George Kerscher: I do a11y test for RS and I can see testing multiple renditions being a nightmare
… could we somehow indicate to ebook buyers that an alternative reflow version of a given fxl ebook is available, and meet the EU a11y requirement that way?

Dave Cramer: we don’t want to deprecate anything
… also what is in the core spec about multiple rendition right now, alone, is not sufficient to implement multiple renditions
… because the spec is silent on rendition selection
… moving all the language about multiple rendition into a satellite wouldn’t negatively impact compatibility with EU a11y
… having a satellite spec might even draw more attention multiple renditions (people who are interested in using it can just go to that separate document)

Avneesh Singh: I’ve definitely seen multiple rendition in action. e.g. with Readium
… re. the EU a11y act, the act doesn’t require guidance about multiple renditions to be in any specific document
… we would be okay even if the EU mandates multiple renditions

Hadrien Gardeur: although multiple renditions have been supported by Readium for a long time, we haven’t actively worked on it for a long time. Its more a proof of concept
… since it seems like the only thing we have at our disposal to address the EU directive is multiple renditions, we’ve been focusing on it. But it might not be the only way. Maybe there is another way to address the requirements of the EU directive
… maybe there could be a less involved, more streamlined way to meet the EU directive requirements

Tzviya Siegman: +1 to looking for better solution than MR for EUAA

Wendy Reid: +1

Dave Cramer: See reference of a standalone IDPF document

Zheng Xu (徐征): as long as we don’t have a new OPF or anything that require us to implement a new parser, RS implementers should be satisfied
… nor would publishers want to implement new packages that may or may not be backwards compatible

Garth Conboy: for right now we can go with Matt’s PR, and 6 months form now, if the EU directive requires us to bring it back in, then we can consider that step

Ivan Herman: I propose not to come to any resolution at this point. We should wait until next week where the Japanese contingent will be in attendance, esp. as a lot of the comments on the issue were regarding Japanese RS, content

Avneesh Singh: +1 to Ivan, we need to listen to Japanese community

Garth Conboy: maybe we can come to an interim resolution now, and then revisit it next week with our Japanese members

Avneesh Singh: agree that we can still alter course after we receive more clarification about how the EU directive impacts us
… in June 2021

Proposed resolution: Close issue #1436 and merge PR #1438 to remove mentions of multiple renditions in the core specification (Wendy Reid)

Tzviya Siegman: Tzviya: One of the goals of this group is to make FXL accessible, in which case we won’t need Multiple Renditions for a11y

Garth Conboy: +1

Tzviya Siegman: +1

Zheng Xu (徐征): +1

Matthew Chan: +1

George Kerscher: +1

Charles LaPierre: +1

Brady Duga: +1

Wendy Reid: +1

Ivan Herman: +1

Avneesh Singh: +1 in principles, but better to do editorial improvements

Juliette McShane: +1

Hadrien Gardeur: +1

Wendy Reid: we’re just collecting votes in the record this week
… we’re not resolving this week. We’ll wait for additional discussion next week with our Japanese members.

3. Resolutions