14:08:31 <RRSAgent> RRSAgent has joined #epub
14:08:31 <RRSAgent> logging to https://www.w3.org/2020/12/04-epub-irc
14:08:33 <Zakim> RRSAgent, make logs Public
14:08:34 <ivan> Chair: wendy
14:08:34 <ivan> Date: 2020-12-04
14:08:34 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2020Dec/0000.html
14:08:34 <ivan> Meeting: EPUB 3 Working Group Telco
14:08:35 <Zakim> please title this meeting ("meeting: ..."), ivan
14:08:54 <ivan> Chair: wendy
14:08:54 <ivan> Date: 2020-12-04
14:08:54 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2020Dec/0000.html
14:08:54 <ivan> Meeting: EPUB 3 Working Group Telco
14:25:47 <dauwhe> dauwhe has joined #epub
14:38:41 <zhengxu> zhengxu has joined #epub
14:47:44 <Karen> Karen has joined #epub
14:56:32 <ivan> present+
14:57:05 <juliette_mcshane> juliette_mcshane has joined #epub
14:57:11 <MattChan> MattChan has joined #epub
14:57:15 <juliette_mcshane> present+
14:58:01 <dauwhe> present+
14:58:17 <tzviya> present+
14:58:22 <ivan> present+ george
14:58:25 <zhengxu> present+
14:58:36 <zhengxu> will join video in a few mins
14:58:38 <toshiakikoike> toshiakikoike has joined #epub
14:58:40 <MasakazuKitahara> MasakazuKitahara has joined #epub
14:58:45 <wendyreid> present+
14:58:56 <toshiakikoike> present+
14:59:03 <MattChan> present+
14:59:35 <MasakazuKitahara> present+
15:00:22 <ivan> present+ ken
15:00:33 <George> George has joined #epub
15:00:51 <George> present+
15:01:25 <gpellegrino> gpellegrino has joined #epub
15:01:46 <gpellegrino> gpellegrino has joined #epub
15:01:53 <MattChan> scribe+
15:01:59 <gpellegrino> present+
15:02:01 <ivan> present+ brady
15:02:13 <duga> duga has joined #epub
15:02:26 <duga> present+
15:03:02 <ivan> present+ billk
15:03:25 <ivan> present+ charles
15:03:28 <CharlesL> CharlesL has joined #epub
15:03:39 <MattChan> Topic: Core Media Types
15:03:44 <CharlesL> present+
15:03:53 <MattChan> wendyreid: we had discussed this back in sep. that we would vet them one at a time
15:04:01 <ivan> sjs, issue 1344, 1299, 645
15:04:09 <MattChan> ... we've tried to add some ones
15:04:26 <MattChan> ... but run into issues with things that are implemented, but not standardized
15:04:28 <dauwhe> q+
15:04:34 <wendyreid> ack dauwhe
15:04:58 <Avneesh> Avneesh has joined #epub
15:05:02 <Avneesh> present+
15:05:23 <MattChan> dauwhe: 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.
15:05:44 <ivan> present+ gpellegrino
15:05:48 <MattChan> ... 2. but epubs also must work. e.g. someone who buys a book should be able to read it on their device
15:05:57 <Bill_Kasdorf_> Bill_Kasdorf_ has joined #epub
15:06:03 <MattChan> ... an issue esp. because older RSes are still out there
15:06:05 <Bill_Kasdorf_> present+
15:06:35 <ivan> q+
15:06:44 <MattChan> ... 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
15:07:10 <wendyreid> ack ivan
15:07:19 <MattChan> ... 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
15:07:33 <dauwhe> q+
15:07:36 <MattChan> ivan: we have already made the similar decision in terms of css
15:07:41 <Garth> Garth has joined #epub
15:07:46 <duga> q+
15:07:54 <MattChan> ... e.g. whatever css can do, it is fair game for authors
15:08:00 <wendyreid> ack dauwhe
15:08:13 <George> q+
15:08:32 <MattChan> dauwhe: i think css is different. CSS has very well defined fallback behaviour. Not true with, e.g., new media type in epub
15:08:34 <tzviya> +1 to dauwhe about fallbacks
15:08:49 <MattChan> ... with CSS, the reading experience may be _degraded_, but not entirely lost
15:09:09 <Hadrien> Hadrien has joined #epub
15:09:21 <MattChan> ... there's also lots of experience out there about writing CSS that works even if certain features aren't supported
15:09:21 <wendyreid> ack duga
15:09:26 <ivan> +1 to dave's response
15:09:28 <MattChan> ... not exactly the same with EPUB
15:09:32 <ivan> present+ garth
15:09:36 <ivan> present+ hadrien
15:09:37 <MattChan> duga: agreed
15:10:09 <wendyreid> ack George
15:10:19 <MattChan> ... 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
15:10:34 <MattChan> George: where are we in terms of video formats?
15:10:54 <MattChan> wendyreid: with video, we've also taken an "open approach" i.e. just use what the RS accepts
15:11:12 <dauwhe> q+
15:11:15 <MattChan> ... h256 encoded is probably the standard?
15:11:33 <MattChan> George: i think the lack of clarity around the video is holding us back. People would love to see video in epubs
15:12:07 <MattChan> s/h256/h264
15:12:10 <dauwhe> s/h256/h264
15:12:27 <Avneesh> q+
15:12:27 <wendyreid> ack dauwhe
15:12:45 <MattChan> dauwhe: video is tricky because there are even brand new devices that won't support video - eInk!
15:12:57 <wendyreid> ack Avneesh
15:13:01 <MattChan> wendyreid: also, some platforms have upload sizes that make video incompatible
15:13:48 <MattChan> Avneesh: 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
15:14:19 <MattChan> ... going back, we said that epub 3.3 would not be a major revision. And we only have 1 year to finish the spec.
15:14:44 <MattChan> ... recall our experience with epub 3.1. The publishing industry, unlike the web, is slow to move to new standards
15:14:47 <dauwhe> q+
15:14:50 <wendyreid> ack dauwhe
15:15:22 <MattChan> dauwhe: a lot of the trouble with epub 3.1 was with epubcheck not being available (although the spec also had its own issues)
15:15:22 <dauwhe> q+
15:15:26 <ivan> q+
15:15:26 <wendyreid> ack dauwhe
15:15:43 <MattChan> ... i think we should keep core media types
15:16:08 <MattChan> ... and maybe periodically consider new media types as the underlying technology evolves
15:16:13 <Bill_Kasdorf_> q+
15:16:21 <Hadrien> q+
15:16:37 <MattChan> ... and i think this discussion shows that that decision comes down to the specific media type under consideration
15:16:41 <wendyreid> ack ivan
15:16:42 <Garth> q+
15:17:11 <MattChan> ivan: i'm okay with what Dave said, but what are the criteria when we decide that something becomes a core media type
15:17:58 <MattChan> ... 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
15:18:06 <wendyreid> ack Bill_Kasdorf_
15:18:36 <wendyreid> ack Hadrien
15:18:39 <MattChan> 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?
15:18:47 <MattChan> ... yes, okay
15:19:02 <ivan> q+
15:19:36 <MattChan> Hadrien: 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
15:20:10 <wendyreid> ack Garth
15:20:18 <duga> q+
15:20:19 <Avneesh> q+
15:20:19 <MattChan> ... 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)
15:20:25 <Garth> https://www.w3.org/publishing/epub3/epub-spec.html#sec-epub-rs-conf
15:21:07 <MattChan> Garth: we currently have a list of types for image, a list for audio, and a vague suggestion for video
15:21:27 <MattChan> ... but I don't think the current state of support for video is broken right now
15:22:02 <wendyreid> ack ivan
15:22:03 <MattChan> ... about what Hadrian said, maybe it could be an external vocabulary document?
15:23:14 <MattChan> ivan: about Hadrian'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.
15:23:47 <dauwhe> q+ to rant about registries
15:23:50 <MattChan> ... 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.
15:23:55 <wendyreid> ack duga
15:24:21 <MattChan> duga: I like the idea of pulling out the media types to a separate location rather than having them buried inside the main spec
15:25:21 <MattChan> ... 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)
15:25:54 <wendyreid> ack Avneesh
15:25:59 <MattChan> ... there seems to be some disagreement about _how_ to add new core media types
15:26:39 <MattChan> Avneesh: we already tried what Hadrian suggested in epub 3.1, but then with epub 3.2, we put it back in
15:26:57 <MattChan> ... externally incorporated documents created additional issues when it came time to take 3.2 to ISO
15:27:24 <wendyreid> ack dauwhe
15:27:24 <Zakim> dauwhe, you wanted to rant about registries
15:27:45 <MattChan> ... maybe we could ask Mokoto whether whatever we decide here will create an issue for ISO
15:28:06 <wendyreid> s/Hadrian/Hadrien/
15:28:12 <wendyreid> s/Mokoto/Makoto/
15:28:17 <MattChan> dauwhe: yes, external registries have definitely been an issue for specs in the past
15:28:59 <Bill_Kasdorf_> q+
15:29:11 <wendyreid> ack Bill_Kasdorf_
15:29:12 <MattChan> ... and audio and video formats are more amenable to being remediated by fallbacks than images (the fallback can even just be text)
15:29:30 <gpellegrino> * Previewer what? :) *
15:29:52 <ivan> q+
15:30:08 <wendyreid> ack ivan
15:30:34 <MattChan> ivan: to wrap up, we seem to be converging towards the point of not changing anything for now
15:31:10 <MattChan> ... 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)
15:31:26 <Garth> me Fixed: Is there a "stay the course" proposal?  Add Webp?  Perhaps move all media type discussion to an external registry (but have Matt decide later).
15:31:36 <MattChan> wendyreid: yes, we want to keep core media types, and we will wait and see about the idea of using external registries
15:31:53 <MattChan> ... esp. given that how registries will work in the future is still being sorted out
15:32:22 <MattChan> ... and the Process 2020 will allow us to make piecemeal modifications to the spec without revisiting everything
15:33:02 <MattChan> ... we're still in favor of adding webp, we just need to work out the implementation issues around webp
15:33:26 <ivan> proposal: EPUB 3.3 will keep the concept of core media types as it is today
15:33:46 <MattChan> ivan: i think webp is a separate discussion
15:33:52 <tzviya> +1
15:33:54 <ivan> +1
15:33:55 <MattChan> +1
15:33:56 <duga> +1
15:33:57 <Hadrien> 0
15:33:58 <wendyreid> +1
15:33:58 <Garth> +1
15:34:00 <CharlesL> +1
15:34:01 <juliette_mcshane> +1
15:34:04 <Avneesh> +1
15:34:06 <toshiakikoike> +1
15:34:06 <Bill_Kasdorf_> +1
15:34:10 <MasakazuKitahara> +1
15:35:13 <MattChan> Garth: and for video, we're going to keep it as it is for now - i.e. no specific type, just a suggestion
15:35:44 <MattChan> Hadrien: isn't that an inconsistency? There's core media types for some types of content, but not for video?
15:36:04 <tzviya> q+
15:36:07 <MattChan> dauwhe: In the past that was because video types were evolving so quickly
15:36:22 <MattChan> Hadrien: Images seem to be evolving quickly today
15:36:36 <dauwhe> In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
15:37:37 <ivan> resolved: i think webp is a separate discussion
15:37:40 <George> +1
15:37:41 <tzviya> q-
15:37:59 <MattChan> wendyreid: Well with image elements, there are a robust assortment of image fallbacks
15:38:04 <gpellegrino> +1
15:38:28 <MattChan> 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!
15:39:01 <MattChan> ... everyone may not be closely watching the chat log
15:39:17 <dauwhe> q+
15:39:30 <MattChan> Topic: Removing multiple rendition from core spec
15:39:34 <ivan> sjs, issue 1436
15:39:40 <tzviya> https://github.com/w3c/epub-specs/issues/1436
15:39:42 <ivan> sjs, pr 1438
15:40:14 <MattChan> wendyreid: multiple rendition is not widely implemented, and people have mentioned that references to it complicate understanding of the core spec
15:40:14 <Garth> q+
15:40:19 <wendyreid> ack dauwhe
15:40:29 <Garth> q-
15:40:44 <MattChan> ... we can remove references to it from the core spec, and have it live as a satellite document outside the spec
15:41:04 <ivan> q+
15:41:27 <MattChan> dauwhe: 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
15:41:36 <Garth> q+
15:41:40 <MattChan> ... and multiple renditions have always been _optional_
15:41:47 <wendyreid> ack ivan
15:41:54 <MattChan> ... therefore multiple renditions should be epub adjacent, but not a core aspect
15:42:01 <gpellegrino> q+
15:42:10 <MattChan> ivan: Referring everyone to the discussion in the PR
15:42:20 <MattChan> ... some Japanese RS and content does use it
15:42:51 <George> q+
15:43:04 <MattChan> ... 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.
15:43:56 <MattChan> ... it may not have been clear from the PR that the intention was to have guidance about multiple renditions exist in a separate document
15:44:05 <dauwhe> q+ to mention that multiple renditions don't work without the satellite spec
15:44:19 <wendyreid> ack Garth
15:44:30 <MattChan> ... we are not removing anything that was previously possible under the spec, just editing the spec to make it more readable
15:44:59 <wendyreid> ack gpellegrino
15:45:04 <MattChan> Garth: i support getting language about multiple renditions out of the core spec, while still allowing the possibility of multiple renditions
15:45:27 <Avneesh> q+
15:45:41 <wendyreid> ack George
15:45:52 <MattChan> gpellegrino: 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.
15:46:18 <MattChan> George: I do a11y test for RS and I can see testing multiple renditions being a nightmare
15:46:54 <Hadrien> q+
15:47:18 <MattChan> ... 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?
15:47:23 <wendyreid> ack dauwhe
15:47:23 <Zakim> dauwhe, you wanted to mention that multiple renditions don't work without the satellite spec
15:47:54 <MattChan> dauwhe: we don't want to deprecate anything
15:48:16 <MattChan> ... also what is in the core spec about multiple rendition right now, alone, is not sufficient to implement multiple renditions
15:48:24 <MattChan> ... because the spec is silent on rendition selection
15:48:58 <MattChan> ... moving all the language about multiple rendition into a satellite wouldn't negatively impact compatibility with EU a11y
15:49:46 <wendyreid> ack Avneesh
15:49:49 <MattChan> ... 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)
15:50:13 <MattChan> Avneesh: I've definitely seen multiple rendition in action. e.g. with Readium
15:51:32 <MattChan> ... re. the EU a11y act, the act doesn't require guidance about multiple renditions to be in any specific document
15:51:52 <zhengxu> q+
15:52:00 <wendyreid> ack Hadrien
15:52:06 <MattChan> ... we would be okay even if the EU mandates multiple renditions
15:52:42 <MattChan> Hadrien: 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
15:53:34 <Garth> q?
15:53:37 <Garth> q+
15:53:42 <MattChan> ... 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
15:54:02 <wendyreid> ack zhengxu
15:54:12 <MattChan> ... maybe there could be a less involved, more streamlined way to meet the EU directive requirements
15:54:36 <tzviya> +1 to looking for better solution than MR for EUAA
15:54:48 <wendyreid> +1
15:55:09 <dauwhe> for reference: http://idpf.org/epub/renditions/multiple/
15:55:26 <ivan> q+
15:55:29 <MattChan> zhengxu: 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
15:56:23 <wendyreid> ack Garth
15:56:43 <MattChan> ... nor would publishers want to implement new packages that may or may not be backwards compatible
15:57:36 <wendyreid> ack ivan
15:57:49 <MattChan> Garth: 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
15:58:31 <Avneesh> +1 to Ivan, we need to listen to Japanese community
15:58:35 <tzviya> q+
15:58:47 <wendyreid> ack tzviya
15:59:05 <MattChan> ivan: 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
15:59:11 <Avneesh> q+
15:59:23 <wendyreid> ack Avneesh
15:59:47 <MattChan> Garth: maybe we can come to some conclusion now, and then revisit it next week with our Japanese members
16:00:15 <MattChan> Avneesh: agree that we can still alter course after we receive more clarification about how the EU directive impacts us
16:00:25 <MattChan> ... in June 2021
16:00:43 <wendyreid> Proposal: Close issue #1436 and merge PR #1438 to remove mentions of multiple renditions in the core specification
16:00:59 <MattChan> s/some conclusion/an interim resolution
16:01:06 <tzviya> Tzviya: One of the goals of this group is to make FXL accessible, in which case we won't need Multiple Renditions for a11y
16:01:12 <Garth> +1
16:01:17 <tzviya> +1
16:01:18 <zhengxu> +1
16:01:20 <MattChan> +1
16:01:21 <George> +1
16:01:21 <CharlesL> +1
16:01:24 <duga> +1
16:01:25 <wendyreid> +1
16:01:26 <ivan> +1
16:01:28 <Avneesh> +1 in principles, but better to do editorial improvements
16:01:34 <juliette_mcshane> +1
16:01:40 <Hadrien> +1
16:01:44 <MattChan> wendyreid: we're just collecting votes in the record this week
16:02:04 <CharlesL> CharlesL has left #epub
16:02:10 <MattChan> ... we're not resolving this week. We'll wait for additional discussion next week with our Japanese members
16:02:12 <dkaplan3> dkaplan3 has joined #epub
16:02:54 <MattChan> Zakim, end meeting
16:02:54 <Zakim> As of this point the attendees have been ivan, juliette_mcshane, dauwhe, tzviya, george, zhengxu, wendyreid, toshiakikoike, MattChan, MasakazuKitahara, ken, gpellegrino, brady,
16:02:55 <ivan> rrsagent, draft minutes
16:02:55 <RRSAgent> I have made the request to generate https://www.w3.org/2020/12/04-epub-minutes.html ivan
16:02:58 <Zakim> ... duga, billk, charles, CharlesL, Avneesh, Bill_Kasdorf_, garth, hadrien
16:02:58 <Zakim> RRSAgent, please draft minutes
16:02:58 <RRSAgent> I have made the request to generate https://www.w3.org/2020/12/04-epub-minutes.html Zakim
16:03:00 <Zakim> I am happy to have been of service, MattChan; please remember to excuse RRSAgent.  Goodbye
16:03:01 <ivan> zakim, end meeting
16:03:03 <Zakim> As of this point the attendees have been ivan, juliette_mcshane, dauwhe, tzviya, george, zhengxu, wendyreid, toshiakikoike, MattChan, MasakazuKitahara, ken, gpellegrino, brady,
16:03:03 <Zakim> ... duga, billk, charles, CharlesL, Avneesh, Bill_Kasdorf_, garth, hadrien
16:03:03 <Zakim> RRSAgent, please draft minutes
16:03:03 <RRSAgent> I have made the request to generate https://www.w3.org/2020/12/04-epub-minutes.html Zakim
16:03:04 <Zakim> Zakim has left #epub
16:03:06 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:04:54 <ivan> rrsagent, bye
16:04:54 <RRSAgent> I see no action items