13:28:05 RRSAgent has joined #epub 13:28:05 logging to https://www.w3.org/2020/10/09-epub-irc 13:28:07 RRSAgent, make logs Public 13:28:08 please title this meeting ("meeting: ..."), ivan 13:28:19 ivan has changed the topic to: Meeting Agenda 2020-10-09: https://lists.w3.org/Archives/Public/public-epub-wg/2020Oct/0004.html 13:28:20 Chair: wendy 13:28:20 Date: 2020-10-09 13:28:20 Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2020Oct/0004.html 13:28:20 Meeting: EPUB 3 Working Group Telco 13:28:20 Regrets+ zheng, daihei, yoshii, toshiakikoike 13:40:17 LauraB__ has joined #epub 13:48:40 mgarrish has joined #epub 13:57:13 present+ 13:57:51 Will has joined #epub 13:58:17 MasakazuKitahara has joined #epub 13:58:35 gpellegrino has joined #epub 13:58:41 present+ 13:59:08 tzviya has joined #epub 13:59:11 Avneesh has joined #epub 13:59:22 present+ 13:59:41 present+ 13:59:59 present+ 14:00:28 MattChan has joined #epub 14:00:41 present+ MattChan 14:00:47 present+ 14:00:53 present+ 14:00:56 present+ 14:00:58 present+ 14:01:00 BenSchroeter has joined #epub 14:01:09 present+ 14:01:13 present+ MasakazuKitahara 14:01:27 George has joined #epub 14:01:28 present+ laurent 14:01:33 CharlesL has joined #epub 14:01:41 present+ brady 14:01:49 Karen has joined #epub 14:01:51 present+ 14:01:54 present+ 14:01:58 Will_ has joined #epub 14:02:02 present+ 14:02:20 present+ mgarrish 14:02:23 present+ 14:02:25 laurent_ has joined #epub 14:02:29 present+ billk 14:02:29 scribe+ dauwhe 14:02:35 present+ 14:02:36 wendyreid: let's get started 14:02:37 Yanni has joined #epub 14:02:47 ... welcome to this week's episode of EPUB 3 WG 14:02:49 Bill_Kasdorf has joined #epub 14:02:53 ... we have a couple of new members 14:03:03 Topic: introduction of new members 14:03:15 present+ hadrien 14:03:15 can someone share the zoom link please 14:03:17 laura: Laura Brady from House of Anansi 14:03:19 present+ 14:03:30 ... I want to work on FXL a11y 14:03:38 ... I've been working on EPUB forever 14:03:44 ... I organized ebookcraft 14:03:59 Bill_Kasdorf: You just got GCA certification from Benetech! 14:04:25 Hadrien has joined #epub 14:04:32 laurent_: this is my first WG meeting 14:04:38 present+ 14:04:40 ... I'm CTO of EDRLab 14:04:49 ... we are implementing EPUB everywhere 14:05:01 wendyreid: we're gonna deal with some open issues today 14:05:31 https://github.com/w3c/publ-epub-revision/issues/645 14:05:31 ... we'll talk about a few media types issues 14:05:34 Garth has joined #epub 14:05:43 Topic: Opus as media tupe 14:05:46 Topic: #645, adding OPUS as core media type 14:05:55 ... this is related to Ogg and Vorbis 14:06:00 present+ Garth 14:06:04 ... it's supported in browsers 14:06:14 ... so we hope adding it for reading systems is not difficult 14:06:31 ... but we do want to get feedback from implementors 14:06:36 q+ 14:06:37 q+ 14:06:40 q+ 14:06:42 ack George 14:06:55 George: Any issues with seeking in opus? going to a particular place? 14:06:58 wendyreid: a good question 14:07:07 Hadrien: not that i'm aware of. We use it for streaming 14:07:19 George: that's been one of the difficult problems with other codecs 14:07:23 ack Garth 14:07:41 Garth: as long as we're not on a slippery slope of adding core media types... this one is really useful for a11y community 14:07:46 ack duga 14:07:50 present+ Hadrien 14:08:02 duga: 14:08:04 ... 14:08:45 wendyreid: any other comments? Experience with opus? 14:09:21 duga: what is the actual proposal? A general OPUS proposal? or specifically OGG? 14:09:26 wendyreid: looking... 14:09:31 q+ 14:09:48 duga: opus is the codec, ogg is the container 14:10:03 ... my recollection is that ogg is not supported on iOS 14:10:11 ack Hadrien 14:10:20 Hadrien: you are asking for feedback about opus in general 14:10:33 ... we've been using it as our default codec, with ogg, for streaming 14:10:37 ... it works well 14:10:44 ... you can target file size and bitrate 14:10:45 ... it 14:11:01 ... but we have to fallback to AAC or MP3 for iOS 14:11:04 ... which is a shame 14:11:17 ... they fixed webp in iOS14, but not OGG 14:11:20 q+ 14:11:24 wendyreid: checking caniuse... 14:11:34 https://caniuse.com/opus 14:11:35 ... widely supported with the exception of iOS 14:11:44 ack ivan 14:11:44 ... needs to be packaged for iOS 14:11:50 ivan: from a formal w3c sense 14:12:01 ... it is perfectly possible to add now ogg as a media type 14:12:19 ... and if during the CR phase, we can mark "at risk" and possibly remove if there's not enough support 14:12:25 ... CR is not for a year at least 14:12:39 q+ 14:12:41 q+ 14:12:45 ... we can add a note to the spec warning the reader about this issue 14:12:47 ack Avneesh 14:12:54 Avneesh: I was thinking the same as Ivan 14:13:00 ... Opus is used so much in webrtc 14:13:14 ... it's hard to imagine safari will not support soon 14:13:22 ... we had the same issue in 3.2 14:13:28 ... so +1 to add now 14:13:30 ack duga 14:13:39 duga: I'm impressed by Avneesh's optimism 14:13:47 ... I'm fine adding this with an explicit note 14:14:01 ... we'll just transcode in our implementation 14:14:03 q+ 14:14:23 CharlesL: I thought that we only required two implementation for REC 14:14:25 q+ 14:14:25 q+ 14:14:31 ack char 14:14:33 q+ 14:14:44 ack dauwhe_ 14:15:08 "at least 2", "not only 2" 14:15:10 +1 dauwhe_ 14:15:15 dauwhe_: If we are going to make a change it needs to be universally usable, 2 implementations is the W3C minimum, but we have a higher requirement to meet 14:15:16 q+ 14:15:20 ... we would be fragmenting EPUB 14:15:25 ack mgarrish 14:15:39 mgarrish: the core media types are a higher bar than w3c's rec process 14:16:00 ... core media types are meant to be relied on by publishers 14:16:10 ack Garth 14:16:11 ... it's OK as long as we have a note saying we need better support 14:16:19 In EPUB 3.1 even android support was an issue. 14:16:20 ack Hadrien 14:16:38 Hadrien: you can support OPUS in iOS, but you don't get it for free 14:16:49 ... you'll just have to jump through some additional hoops 14:16:57 ... it's still easier than pagination 14:17:03 wendyreid: there are ways around this 14:17:18 Proposal: Add the media-type for OPUS/OGG to the core media types (address issue #645) 14:17:19 ... I think we're good as long as we supply some context 14:17:29 q+ 14:17:29 +1 14:17:33 +1 14:17:33 +1 14:17:36 +1 14:17:38 +1 14:17:41 +1 14:17:51 ivan: adding to proposal that a note should be added to the doc 14:17:52 +1 14:17:56 +1 14:18:00 +1 14:18:05 +1 14:18:09 Proposal: Add the media-type for OPUS/OGG to the core media types (address issue #645) with a note explaining the exception for Safari 14:18:16 ack ivan 14:18:16 +1 14:18:16 0 14:18:18 +1 14:18:21 +1 14:18:30 RESOLVED: Add the media-type for OPUS/OGG to the core media types (address issue #645) with a note explaining the exception for Safari 14:18:36 +1 14:18:51 https://github.com/w3c/publ-epub-revision/issues/1323 14:19:00 Topic: #1323, validation of SVG 14:19:25 wendyreid: SVG documents with DTD declarations cannot pass EPUBCheck, which is problematic 14:19:35 ... most people don't hand-code SVG; tools insert the DTD 14:19:40 q+ 14:19:44 ack ivan 14:20:00 ivan: AFAIK, the same problem exists with MathML 14:20:34 ... both MathML and SVG, the DTDs use modularization; the DTDs are full of entities; somewhere else we say DTDs are not to be used 14:20:40 ... this is the point where these collide 14:21:02 q+ 14:21:06 ack duga 14:21:09 q+ 14:21:20 duga: raises eyebrows expressively 14:21:33 ... we're talking about DTDs 14:21:39 q+ 14:21:43 ... I don't see a DTD in this failing SVG 14:21:48 is it just a DTD declaration? 14:21:55 q+ 14:21:58 ... I think EPUBCheck is validating against some schema and failing 14:22:06 ... I don't think it's only an issue of DTDs? 14:22:13 ivan: I don't know what SVG you are looking at 14:22:18 ack ivan 14:22:22 ... what I hit, and there is a trace in the EPUBcheck issue 14:22:24 q+ 14:22:30 ... it complains about external entities being used 14:22:41 https://github.com/w3c/epubcheck/issues/1172 14:22:44 ... so if SVG doesn't have DTD, EPUBCheck ought to accept it 14:22:53 duga: that's the issue 14:23:01 Garth: there are two failure cases in this world 14:23:03 ack laurent_ 14:23:05 q- 14:23:20 q+ 14:23:20 laurent_: EPUBCheck validates the HTML; was there a decision to validate SVG and MathML? 14:23:22 q+ 14:23:29 ... is it a previous decision, or a grey area? 14:23:37 ivan: what they said is they do what's in the standard 14:23:39 ack mgarrish 14:23:46 mgarrish: we got mixed up in issues 14:23:51 ... the DTD issue is something else 14:24:00 ... Garth opened an issue with epubcheck 14:24:06 ... about the rel attribute on 14:24:14 ... we take schemas from validator.nu 14:24:22 ... and they don't implement SVG2 validation 14:24:36 ... so that raised the issue of SVG validation--should we do it at all? 14:24:52 ... duga mentioned we lost a requirement when we gave up our own SVG reference 14:25:09 ... there's two parts: 1. what should epubcheck be doing? should we differ from validator.nu? 14:25:24 ack Garth 14:25:24 ... should we say we support SVG2 in the same way the web does? 14:25:27 q+ to point out similarity to CSS 14:25:43 Garth: one could look to what we do with png and jpeg; we don't validate those, and SVG is an image type 14:25:52 q+ to comment about EPUBCheck maintenance 14:26:02 ... we only had a hundred books with a problem, we could get rid of @rel 14:26:20 ... but if this content keeps coming in... almost all SVGs are mechanically authored 14:26:30 1. Should we add back validity? 2. If yes, how do we phrase it? 3. If no, should epubcheck validate by default? 14:26:30 ack duga 14:26:32 q+ 14:26:37 ... I'd like to hear other opinions. Is svg a black box? 14:26:44 duga: @rel is an interesting case 14:26:58 ... there was a fill that works everywhere but isn't allowed in SVG 1.1 14:27:12 ... we don't have validity in SVG right now 14:27:39 ... how could we say we require validity while the spec evolves? Which schema? is it a live schema? 14:27:54 ... should epubcheck be checking for validatity by default? I think no. 14:28:02 ... it's not required by the spec 14:28:03 ack tzviya 14:28:03 tzviya, you wanted to point out similarity to CSS 14:28:16 tzviya: I agree with brady that epubcheck shouldn't check for things in the spec 14:28:25 ... this is more like CSS than other image types 14:28:35 ... EPUBcheck does little with CSS 14:28:53 ... since there are tools that check svg, we have options whether to use them 14:29:03 ... I don't think we should build additional tools to check SVG 14:29:11 ... and we have to pay for anything we do with EPUBCheck 14:29:29 q+ 14:29:37 https://inclusivepublishing.org/epubcheckdonate/ 14:29:39 ... let's not build an SVG validator 14:29:46 ack Avneesh 14:29:47 Avneesh, you wanted to comment about EPUBCheck maintenance 14:29:53 Avneesh: tzviya read my mind :) 14:30:03 ... EPUBCHeck maintenance is additional work 14:30:23 ... the more we increase the demand on EPUBCheck, it becomes more difficult to maintain 14:30:32 q? 14:30:45 ... we can reduce overhead of HTML by migrating to the HTML validator in the future 14:31:04 ... but if we have to keep updating schema inside EPUBCheck for each spec, that's too much overhead. 14:31:07 ack George 14:31:22 George: I want to emphasise the importance of SVG for people with low vision 14:31:35 ... it's an important issue; RSs need to deal with the spec properly 14:31:49 ... we see interactive SVG applications, like exploration of chemical molecules 14:32:01 q+ 14:32:05 q+ 14:32:20 ... it has to run the same way on various platforms 14:32:33 ... I don't know how images are validations; I think we use the same expectations 14:32:36 ack ivan 14:32:42 ivan: i wonder about one thing 14:32:50 ... SVG is an image file, but it's also an XML file 14:33:02 q+ 14:33:04 q+ 14:33:07 ... I think we require XML validity for all our docs 14:33:11 ... the DTD problem comes from that 14:33:32 ack mgarrish 14:33:51 mgarrish: the DTD problem comes from XML requirements that you can't have an external entity set 14:34:03 ... it comes up for NCX, for SVG... 14:34:08 ... they get errors 14:34:23 ... we look at this validity question. Is it just images, or XHTML? 14:34:35 ... we'll have SVG inside of HTML. Do we validate that? 14:34:54 ... is there broader application of leniency? 14:34:58 ack CharlesL 14:35:17 CharlesL: you could have SVG as an image file, brought in, vs. inline SVG in HTML 14:35:25 ... would checker ignore both? 14:35:26 ack duga 14:35:45 duga: if XHTML docs have to be valid, they have to be valid. 14:36:03 ... if you have a base64png in the doc, it still has to be valid 14:36:16 ... we don't have a validity requirement anymore in EPUB. We deleted them. 14:36:30 ... one could argue this is a step towards our Great HTML Future (tm) 14:36:45 ... if we want validity checking, we have to put it in 14:36:55 ... today we don't actually require XML validity 14:37:24 wendyreid: should we put aside as we clarify some more of the HTML future? 14:37:26 q? 14:37:31 ack laurent_ 14:37:36 laurent_: I agree with brady 14:37:48 q+ 14:37:49 ... when I see that reading systems are a non-validationg processors 14:38:05 ... I don't know how EPUBCHeck validates HTML 14:38:10 q+ 14:38:12 ... maybe we should just require well-formedness 14:38:12 ack mgarrish 14:38:30 mgarrish: it's validator.nu schema; it constantly changes 14:38:40 ... it's not even fully integrated; we just take the schemas 14:38:51 ... even for a11y, valid HTML isn't a requirement 14:38:56 q+ 14:39:06 ... WCAG doesn't require it 14:39:15 ack ivan 14:39:20 q+ 14:39:22 ivan: I am just a go-between 14:39:27 https://www.w3.org/publishing/epub3/epub-spec.html#confreq-xml-extmarkupdecl 14:39:37 ... here is the reference I got from Romain 14:40:11 ... any publication resource that is an XML Media type... external entities must not appear in the DTD 14:40:21 q? 14:40:30 wendyreid: External identifiers must not appear in DTD 14:41:10 duga: AFAIK this has nothing to do with DTDs; EPUBCheck is validating is against a 1.1 schema 14:41:24 ivan: the standard DTDs for SVG include external identifiers 14:41:29 q+ 14:41:39 ... the problem is that SVG 1.1 defines a DTD which includes external identifiers 14:41:48 ... therefore SVG 1.1 can't pass EPUBCheck 14:41:53 ack dauwhe_ 14:41:56 ... same for MathML. That's the problem 14:42:05 q+ 14:42:19 dauwhe_: To the general question of validation, we need to think about each language individually 14:42:32 ... HTML validation is less critical because browser error handling is well-defined 14:42:45 scribe+ wendyreid 14:42:46 ... package file validation is more important because we haven't defined errors 14:42:58 ... a broken package file is something a reading system would struggle with 14:43:00 ack dau 14:43:05 ... I don't know where svg would fall into this 14:43:09 ack tzviya 14:43:14 tzviya: not sure I have much more to add 14:43:20 ... re: a11y and SVG 14:43:26 q- 14:43:34 ... we're being caught up in what validation means, and confusing it with requirements 14:43:40 ... and we should talk about this with romain 14:43:54 ... we try to have EPUBCheck match the specification 14:44:09 ... let's try to shift from EPUBCheck, and talk about the spec 14:44:18 q+ 14:44:24 ivan: what it means is that we cannot put a valid SVG 1.1 into EPUB per spec 14:44:29 tzviya: that's a problem with the spec 14:44:35 ivan: yes 14:44:44 tzviya: talking about epubcheck is a distraction 14:44:56 wendyreid: as a group we control the spec but not EPUBCheck :) 14:45:02 q+ 14:45:05 ack duga 14:45:14 duga: I'm going to ignore ivan's comments right now 14:45:29 ... historical perspective on why we required XHTML validity 14:45:40 ... in the early days of OEB, people would abuse tags to get style behaviour 14:45:51 ... people would use

in