EPUB 3 Working Group Telco — Minutes

Date: 2020-10-15

See also the Agenda and the IRC Log

Attendees

Present: Wendy Reid, Toshiaki Koike, Masakazu Kitahara, Matthew Chan, Laura Brady, Zheng Xu (徐征), Teenya Franklin, Brady Duga, Marisa DeMeglio, Yu-Wei Chang (Yanni), Shinya Takami (高見真也), Ben Schroeter, Jun’Ichi Yoshii

Regrets: Daihei Shiohama (塩濱大平)

Guests:

Chair: Wendy Reid, Shinya Takami (高見真也)

Scribe(s): Dave Cramer, Wendy Reid

Content:

Wendy Reid: if you are able to scribe, please let me know.
… we need to equitably share the work
… anyone new this week?

1. media types

Wendy Reid: we’ve talked a lot about media types
… we’ll talk about a few other media types today
… it would be good to have for criteria for adding new media types
… we’ve done this accidentally
… we want broad support across all major browsers
… we want a strong use case from the publishing industry
… we mentioned this in one of Matt’s pull requests

Wendy Reid: https://github.com/w3c/publ-epub-revision/pull/1345

Wendy Reid: what should the criteria be for adding new media types? What are our requirements?

Dave Cramer: It’s straightforward to say a media-type is supported by all major browsers and operating systems
… and the promise of being supported by all major reading systems
… query RS developers from around the world on their thoughts
… universality and support is important

Zheng Xu (徐征): I was going to ask… what is the benefit for a core media type?
… I raised the question in epubcheck
… making it easy to load something in OPF
… what is purpose of core media type?
… if a RS is using a browser engine, the media type is decided by browser.
… browsers don’t define that
… but some reading systems are not based on web browsers
… I don’t quite understand if this is necessary for us to define

Shinya Takami (高見真也): (speaking in Japanese)

Toshiaki Koike: (speaking in Japanese)

Shinya Takami (高見真也): I asked about RS in Japan
… toshiakikoike said, their RS converts EPUB files in advance to deliver browser view
… adding core media types is not a big issue

Brady Duga: Yes

Wendy Reid: as long as we meet the criteria that it is supported (or almost supported) by all major browsers and operating systems
… we’ll talk about WebP, which is supported everywhere but versions of MacOS before the most recent
… they have to be quite well supported at the time
… we will have to test, of course
… reading systems would need to commit to support, and we’d see that in testing
… the two issues… one is logged a couple days ago

1.1. WebP and VTT as media types

Wendy Reid: https://github.com/w3c/publ-epub-revision/issues/1344

Wendy Reid: https://github.com/w3c/publ-epub-revision/issues/1299

Wendy Reid: caniuse looks good for WebP
… supported in Big Sur, which is out soon (?)
… the argument is a more efficient image format
… DeMarque feels it significantly reduces the overall size of their EPUBs
… which is good
… the other possible CMT is VTT,
… used for video captions

Marisa DeMeglio: if we had web vtt as a core type

Wendy Reid: it’s text vtt

Marisa DeMeglio: does it accompany the video?

Wendy Reid: the mystery is how we refer to videos; we don’t have a CMT for video
… it would accompany whatever video format you were using

Shinya Takami (高見真也): (speaks in Japanese)
… I discussed both of these with Mr. Koike… we don’t know what impact they would have on RSs

Brady Duga: Matt seems to think a fallback isn’t needed in this case?
… since VTT is itself a fallback for the track element?
… do we really need to do anything other than clarifying the manifest section

Wendy Reid: that’s a task on it’s own

Brady Duga: that’s why we have matt :)
… you don’t need a fallback for a foreign resource in this case
… so it might make it confusing to have it as a CMT

Dave Cramer: This is the perfect opportunity to mention that CMT doesn’t mean that something can be a spine item
… Content Docs can be spine items, but CMTs mean they don’t need a fallback
… a RS would be assured of finding something to display

Brady Duga: that’s a good point, but you could put vtt in an object tag :)
… the real problem is, if we required a fallback for VTT, there isn’t one.
… so you couldn’t use VTT. There’s not a format that would work instead. You can’t replace it with HTML.
… I’m assuming it has time-based features.
… if it does require a fallback, we should make it a CMT. If it doesn’t require a fallback, there’s no point.
… thumbs up to WebP

Shinya Takami (高見真也): how about adding 2nd-priority CMT
… maybe JPEG/PNG is already popular
… webp and opus are new technologies, maybe there should be fallbacks

Zheng Xu (徐征): If a CMT can be a spine item…
… what is the core media type we wanted to define to have benefit for end user
… we can use it as content doc without fallback
… if CMT does not have this purpose, even some mimetype can be used as CMT but can’t be put in spine item
… how do we use this scope?
… like web browser we have caniuse
… if we have something like caniuse for reading systems
… but if some reading system can’t support webp, it’s a reading system problem
… we need to draw a line for CMT to ask creator to add fallback
… it’s still a question for me

Wendy Reid: it’s a fair question
… having tests will help
… as we discussed earlier, do we throw away the idea of CMT, and the consensus was we didn’t want to do that.
… this puts a lot of pressure on content creators, and leads to interop problems.

Brady Duga: re: fallbacks for webp and opus
… defeats the whole purpose, which is to make your EPUB smaller
… so that’s why you want to extend CMTs
… a size benefit
… we can add to our list of reasons: Is there a benefit you cannot achieve with existing core media types
… the answer for both WebP and Opus is that they are smaller.
… we have opened things up, it was called FXL
… we have insane hacks that downloads Times New Roman so that it can match fruit company’s rendering
… free-form content makes it hard to support lots of things
… we also don’t have enough people to make caniuse for epub work

Zheng Xu (徐征): caniuse for RS… I know it would take a while
… they have more content creators
… we have smaller scope of user
… say user wanted to use some type of… do whatever you want
… use any font, but it might break FXL… sure
… if we can define certain type… with web browsers people only test in 3 browsers
… for reading systems it’s not the same
… we have too many types of reading systems
… as RS creator, if we cannot support it, we can put our support status in caniuse
… it’s kind of more use-case driven
… if we draw a line here,
… how can create a fallback for it?
… this fallback blocks creator from using this feature
… it’s not possible to create fallback
… I think purpose of creator and spec and RS
… expand it, let it be more easy to use

Dave Cramer: I would just remind everyone we tried to do caniuse for EPUB and it failed epically
… there’s a handful of major browsers, and hundreds of reading systems
… which all behave differently on different platforms
… the volunteers could never keep up
… we failed at trying to keep up with it and maintain
… we need more marisas

Marisa DeMeglio: you took the words out of my mouth
… I developed the site

Marisa DeMeglio: https://daisy.github.io/old-epub3-support-grid/features/

Marisa DeMeglio: keeping it up to date was not possible
… we relied on volunteer testers; the tests were not automated
… even though we had some provisions to make it easier
… the rate at which reading systems were changing required too much retesting
… a couple of months ago, BISG asked me to put the static site back
… i’ve put it back
… link ^^^
… this only scratches the surface
… but this is what we tried to do for caniuse for epub

Zheng Xu (徐征): I understand; I respect the amount of work required
… two things
… one, in terms of caniuse or test
… if it needed to be maintained by each RS
… publishers would know how to create content for a RS
… we might have more than a hundred reading systems. No 3rd party can do that.
… webp… based on the current track, it’s hard to add more to CMT
… what is benefit of having this CMT?
… we have spec, we have 3.3 that defines that webp must be CMT
… but we have a RS that does not support this
… that is a problem

Wendy Reid: we have to get back to the core of the core of the talk about core media types
… it sounds like we have consensus on criteria
… they need overwhelming support by browsers and operating systems, with a path to completion
… and they need a direct benefit to content creators and/or reading systems
… based on those criteria, let’s start with WebP
… I’ll put in a proposal

Proposed resolution: Add WebP as a core media type in EPUB 3.3 (Wendy Reid)

Brady Duga: +2 (1 for me, 1 for Garth)

Teenya Franklin: 0

Laura Brady: 0

Shinya Takami (高見真也): +1

Matthew Chan: +1

Marisa DeMeglio: +1

Zheng Xu (徐征): +1

Yu-Wei Chang (Yanni): +1

Ben Schroeter: 0

Wendy Reid: +1

Resolution #1: Add WebP as a core media type in EPUB 3.3

Wendy Reid: I can’t make a strong case for VTT

Dave Cramer: I don’t think we should vote on this right now
… it might not need to be a CMT
… it should be available in EPUB
… let’s figure out how to do that

2. AOB

Wendy Reid: that’s all I have for today
… thanks to everyone who attended the joint meeting with APA/Silver
… next week’s meeting will be our not-face to not-face
… we’ll do two meetings
… both meetings will be 3.5 hours with breaks
… we’re finalizing agendas now
… we’ll talk about testing, fxl a11y, some contentious github issues, etc.
… be prepared to see the agenda early next week
… please volunteer to scribe, we will need multiple scribes per session
… anything else?

Zheng Xu (徐征): the CG will have the first meeting next week
… do we want to try caniuse for ereader again, run by the community group?

Wendy Reid: that’s Wednesday

Marisa DeMeglio: 21st?
… Publishing CG?
… I’ll try to be there.

Wendy Reid: if that’s everything, I’ll let everyone get to their workday, worknight, or whatever.
… see y’all next week at eTPAC.
… stay positive and test negative :)

rrsagent: make logs public

Shinya Takami (高見真也): Funny Japanese :)

Shinya Takami (高見真也): Yes!

Shinya Takami (高見真也): See you next week!

3. Resolutions