22:47:10 RRSAgent has joined #epub 22:47:10 logging to https://www.w3.org/2020/10/22-epub-irc 22:47:13 RRSAgent, make logs Public 22:47:13 please title this meeting ("meeting: ..."), dauwhe 22:47:29 meeting: EPUB 3 Working Group Telecon, Virtual TPAC Day 1 23:49:50 zhengxu has joined #epub 23:56:21 BenSchroeter has joined #epub 23:57:14 toshiakikoike has joined #epub 23:57:23 present+ 23:57:40 MasakazuKitahara has joined #epub 23:58:25 agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2020Oct/0034.html 23:58:42 ShinyaTakami has joined #epub 23:59:16 present+ 23:59:30 present+ 23:59:37 present+ 00:00:26 prenset: 00:00:30 present: 00:00:37 :( 00:00:39 present+ 00:01:03 LauraB__ has joined #epub 00:01:26 present+ 00:01:35 present+ 00:01:47 marisa has joined #epub 00:01:59 present+ 00:02:22 MattChan has joined #epub 00:03:54 duga has joined #epub 00:04:14 present+ 00:04:30 present+ 00:05:12 present+ Garth 00:05:48 I can rotate after Garth 00:06:07 scribe+ Garth 00:07:20 George has joined #epub 00:07:27 dauwhe: Welcome 00:07:34 present+ 00:07:48 Yanni has joined #epub 00:08:41 Juliette_McShane has joined #epub 00:09:55 ... Some technical issues first. 00:11:30 ... Agenda. 00:12:04 1-Welcome/Overview of Topics (10 min) 00:12:04 2-Navigation Order Issue #1283 [1] (30 min) 00:12:04 3-External Entities Issue #1338 [2] (30 min) 00:12:06 4-Break (15 min) 00:12:08 5-Testing EPUB (60 min) 00:12:10 6-FXL Accessibility (25 min) 00:12:12 7-Wrap Up/AOB (5 min) 00:13:17 Wendy: Like to finish with accomplishments; closing initial issues (Nav order, and external entities); progress on FLX A11Y & Testing. 00:13:30 dauwhe: And volunteers to work on same. 00:13:35 https://github.com/w3c/epub-specs/issues/1283 00:13:42 Topic: Must navigation order match spine order? 00:13:50 ... Must navigation order match spine order? 00:14:11 ... Required by EPUB 3, only recently enforced by epubcheck. 00:14:14 q+ 00:14:18 ... Causing existing content to start failing. 00:14:32 q- 00:14:40 q+ 00:14:44 ... EPUB 3 CG: make it a warning rather than error; out of alignment with check. 00:14:54 present+ 00:15:12 ... MUST is spec is an error; SHOULD is a warning (in epubcheck). 00:15:16 q? 00:15:35 ... Dave read relevant portion of EPUB 3.2 spec. 00:15:47 s/read/reads/ 00:16:22 ... Why is this a problem? Existing content doesn't conform. Perhaps valid editorial reasons. 00:16:53 ... This, though, may be an A11Y concern. At least one RS stumbles on difference between spine and nav order. 00:17:03 q? 00:17:10 ack shiestyle 00:17:14 ... Should we keep or relax the restriction? 00:17:18 q+ 00:18:12 shiestyle: Presentation to explain issue. 00:19:00 ... EPUB 3.0 required spine/nav to match. 00:19:12 ... Request de-regulation of current restrictions. 00:19:39 ... Compatibility with existing content and even paper books. 00:19:56 ... Priority or grouping maybe more important than reading order 00:20:24 ... Yes, A11Y could be an issues -- order of story should be consistent. 00:20:31 ... Examples 00:21:29 ... Manga magazine example 00:22:20 ... Cookbook example 00:23:05 ... (multiple navs for single book) 00:23:30 ... Magazine of novels example 00:23:54 q? 00:23:59 ack duga 00:23:59 ... This all "violate" spec in their paper form -- want to do the same in valif EPUB 3.2's. 00:24:35 q+ 00:24:36 q+ 00:24:37 Duga: Is this the right way to do multiple-TOCs? 00:25:18 ... Is this the right time to make such a change? 00:25:27 q+ 00:25:29 ... Columns could be done via nesting. 00:26:08 ... Sympathetic to existing content using the non-matching feature. 00:26:38 ... Maybe relax restriction and make it something caught by an A11Y checker. 00:26:58 q+ 00:27:14 ... Not too many folks will write reverse Moby Dick. 00:27:25 ... maybe a SHOULD or remove. 00:28:15 dauwhe: Don't get why nav is so important isn't spine order used? 00:28:40 duga: nav to next chapter is done by Nav. 00:28:57 ... Don't need it for next page (that spine order). 00:29:23 ... N pages left if chapter comes from Nav -- out of order, could be an issue. 00:29:32 dauwhe: Other RS's? 00:29:35 q? 00:29:38 ack dau 00:29:42 ack geo 00:30:17 George: Small portion of text, reading order is very important. 00:30:38 ... Like a "this is poison" warning next to paragraph. 00:30:41 q+ 00:30:45 q+ 00:31:02 ... History comes from audiobooks, always linear. 00:31:33 ... Nav in docs -- some don't make sense from beginning to end. 00:31:51 ... We are happy to remove restriction. 00:32:46 ... Folks need to understand how they use the TOC. Cookbook is a fine example. Multiple TOCs make sense there. 00:32:58 q+ 00:33:12 q++ 00:33:25 q+ 00:33:28 qq+ 00:34:04 ack dauwhe 00:34:04 dauwhe, you wanted to react to George 00:34:06 dauwhe: Nav docs are interesting as there may be multiple Navs, one is primary. 00:34:10 ack wen 00:34:40 wendyreid: Chairs hat: we do have a proposed solution. 00:35:38 ... Chairs hat off: RS's have to fall back to spine due to incomplete/confusing Nav docs (like ncx and Nav). 00:36:04 ... Spec needs more verbiage around Nav.xhtml andRS behavior. 00:36:17 s/andRS/and RS/ 00:36:53 ... Some clarification is required regardless of approach. 00:36:57 q? 00:37:02 ack zh 00:37:36 zhengxu: Nav is displayed in RS TOC. 00:37:49 ... Random pointers into Spine. 00:38:45 ... Examples (like multi-TOC) could be pages in the book. 00:39:28 ... RS's need the high level info form the Nav file. 00:40:07 ... Linear order or otherwise? 00:40:14 q? 00:40:37 ... Maybe spine be the linear order, let Nav be otherwise. 00:40:39 scribe+ 00:40:40 ack Gar 00:41:09 Garth: I suspect the proposed solution is to make the MUST a SHOULD, I am ok with this 00:41:12 ack shi 00:41:26 Garth: Maybe just make the MUST should be a SHOULD. 00:41:32 shiestyle: +1 00:41:56 ack du 00:41:56 ... Linear order should be ordered by spine. 00:42:20 Duga: Last time we talked about this, we invented tours; lets not do this again. 00:42:35 ack + 00:42:41 ... Multi-TOCs could be in content. 00:42:49 ... Okay with MUST->SHOULD 00:43:22 dauwhe: Propose MUST->SHOULD. Can be more MUSTy in ACE. 00:43:47 +1 00:43:53 ... This approach would leave epubcheck unchanged, making many folks happy. 00:43:59 +1 00:44:07 ... Does this work? 00:44:11 +1 00:44:23 +1 00:44:24 +1 00:44:26 +1 00:44:26 +1 00:44:29 +1 00:44:29 Proposal: The nav order SHOULD match the spine order and the content order 00:44:31 +1 00:44:32 +1 00:44:37 +1 00:44:51 +1 00:45:36 +1 00:45:41 Resolved: The nav order SHOULD match the spine order and the content order 00:45:44 dauwhe: All votes in favor, let's resolve! 00:46:11 Topic: Problem with XML content requirements and external entities: make MathML and SVG1.1 invalid 00:46:16 https://github.com/w3c/epub-specs/issues/1338 00:46:20 https://github.com/w3c/epubcheck/issues/1114 00:46:39 dauwhe: External entities. 00:46:55 https://www.w3.org/publishing/epub32/epub-spec.html#confreq-xml-extmarkupdecl 00:46:59 ... Lots of XML statements in specs. 00:47:05 > External identifiers MUST NOT appear in the document type declaration [XML]. 00:47:23 ... This is a problem. 00:47:43 ... Breaks normal things -- like inline SVG with DOCTYPE. 00:47:51 ... I think that's bad. 00:48:24 ... Forcing folks to edit machine created content seems like a waste of effort. 00:49:13 Agree with the summary and history 00:49:25 ... EPUB RS's are not validating SVG's with DOCTYPE of against that. 00:49:52 ... Should not expect an RS to run an validator. 00:50:17 ... Hope RS's don't need to be validating XML parsers. 00:50:43 q+ 00:50:49 ack dauwh 00:50:51 ack dug 00:50:52 ... Maybe just say "ignore DOCTYPE's" -- don't use content that depending on processing DTD features 00:51:22 duga: Stunned if anybody other than epubcheck is doing said validation. 00:51:24 +1 we do this too 00:51:57 dauwhe: Assuming WV's doing to such validation. 00:52:10 duga: What is this XML of which you speak? 00:52:32 ... RS's likely display HTML, not XML, content. 00:52:43 ... Natively not XHTML in RS's. 00:53:00 wendyreid: +1 00:53:32 dauwhe: Principle in HTML that we should try to match reality -- maybe we should do the same in here? 00:54:21 +1 to not restrict 00:54:37 ... Resolve tonight restricting DTDs in XML documents that are part of an epub. 00:54:45 q+ 00:54:46 SUZUKI has joined #epub 00:54:57 Garth: I think we should try it! 00:55:46 wendyreid: In line with what Dave has say it -- try it for now. It will come done to testing too. 00:56:00 ... Can that bridge when we come to it. 00:56:12 Proposal: remove bullet "External identifiers MUST NOT appear in the document type declaration [XML]." Add reading system conformance saying that reading systems SHOULD NOT validate against DTDs. 00:56:42 +1 00:57:18 +1 00:57:19 dauwhe: RS's have no validation requirement against DTDs that may be found. 00:57:39 +1 00:57:56 +1 00:58:18 +1 00:58:29 +1 00:58:29 wendyreid: If you use inline SVG's out of ID (and other commercial tools) you won't get unexpected errors. 00:58:50 0 00:59:50 ... Found W3C listing DTDs that should be used; seems strange to prohibit. 00:59:50 +1 01:00:16 Resolved: Proposal: remove bullet "External identifiers MUST NOT appear in the document type declaration [XML]." Add reading system conformance saying that reading systems SHOULD NOT validate against DTDs. 01:00:22 SUZUKI_ has joined #epub 01:00:24 ... No objection; relax restriction on external identifiers in DTDs. 01:00:29 s/Proposal: // 01:01:49 01:05:49 SK has joined #epub 01:18:39 scribe+ MattChan 01:19:54 dauwhe: moving on to testing 01:20:16 ... what we have to do is go through all the specs 01:20:27 ... mark where it says rs "must" and then make a test 01:20:43 ... then try that test in all rs and document what the result is, conformed or not 01:20:47 q+ 01:20:55 ack wendyreid 01:21:09 ... i've started making little test epubs 01:21:32 ... in package doc, rs must trim leading and trailing white space in dc-title, dc-creator etc. 01:21:48 ... make an example epub to test this, opened it in ibooks 01:22:10 ... ibooks didn't seem to trim white space from package file 01:22:32 ack dug 01:22:32 ... just as an example 01:22:58 q+ 01:23:16 ack dauwhe 01:23:21 duga: how is this different from previous testing that was done? Before it turned out it was difficult to make use of this data 01:23:36 q+ 01:23:37 dauwhe: epubtest.org, described as caniuse, but for epub 01:23:55 ... goal was to answer "can i use" different aspects of epub in each rs 01:24:10 ... bit of a focus on higher level features, media type support, types of css, etc. 01:24:25 ... not as much testing of foundations 01:24:27 What we tried to test: https://daisy.github.io/old-epub3-support-grid/features/ 01:25:23 ... in css there is infrastructure to automate testing, they have 1000s of tests 01:25:38 ... but how could we automate testing for rs? Most rs support little/no scripting 01:25:52 q? 01:26:03 ... but epubtest.org was trying to be comprehensive in testing a lot of rs, but we only require 2 independent implementations 01:26:09 q+ 01:26:09 ... we could get away with not testing everything 01:26:14 q+ 01:26:19 q+ 01:26:22 ack wen 01:26:23 ... although we'd want all the features to work for all the major rs 01:26:37 wendyreid: i've done this once before with a different spec 01:26:54 ... one difference vs. epubtest 01:27:17 ... when i did epubtest we retested very frequently, like with every os update 01:27:36 ... but with what we are doing now, we only need to test once, at a particular point in time 01:27:45 q? 01:27:50 ... not so worried about rs conformance after 01:28:18 ... also, the spirit of epubtest was to make it so that content authors could see which features they could use for a given rs 01:28:34 ... some of the stuff they tested was very very specific 01:28:51 ... but for our tests, we're only testing certain assertions, fewer tests 01:28:55 q- 01:29:10 q+ 01:29:18 ack Garth 01:29:27 ... only concerned with the assertions in the spec, required to meet CR requirements 01:30:34 qq+ 01:30:43 ack dauwhe 01:30:43 dauwhe, you wanted to react to Garth 01:30:52 Garth: is the idea that we'd end this process with a collection of test epubs? 01:31:07 dauwhe: we should put some thought into how we build tests 01:31:24 ... instead of having a bunch of independent epubs, maybe have a more upstream solution that could be scripted 01:31:35 shiestyle has joined #epub 01:31:43 ... maybe make a core file that contains all the assertions, and then build a structure around it? 01:32:03 shiestyl_ has joined #epub 01:32:18 ... multiple epubs means more maintenance for keeping all the test epubs up to date 01:32:20 q? 01:32:54 https://w3c.github.io/publ-tests/test_reports/manifest_processing/index.html 01:33:24 wendyreid: our final report might look something like a grid of all the assertions, tested against all the major rs 01:33:45 ... we'd be looking for something like at least two passes for each assertions 01:34:16 ... we're looking to see that 1. the spec is actually possible, and can be implemented 01:34:31 2. and that the spec is understandable, and actually makes sense 01:35:06 ... i.e. whether the assertions both actually make sense, and are actually testable 01:35:29 q? 01:35:51 marisa: epubtest has 2 separate lives 01:36:08 ... the old version was really really hard to maintain, to have the test results updated regularly 01:36:13 ... it was volunteer run 01:36:45 ... new version of epubtest dedicated to accessibility 01:36:51 ack marisa 01:37:02 ... now we have staff who are dedicated to moderation of testing, they are experts in what is being tested 01:37:18 ... accessibility testing is very specialized, so manual testing is effective 01:37:33 ... testers can leave notes for things that can't just be quantified as a checkmark in a box 01:37:50 ... testing via multiple books allowed the manual tests to be distributed to different people 01:38:15 ... maintaining the test books isn't fun, but its possible (maybe we could use scripts for this) 01:38:15 ack zhengxu 01:38:34 zhengxu: maybe we don't need to rush into automation testing 01:39:10 ... even 10 years ago, css compatibility on browsers wasn't automated 01:39:33 ... (testing of css compatibility) 01:39:45 q+ 01:40:19 q? 01:40:21 q+ 01:40:26 ... maybe we can start with simple tests, like javascript support 01:40:49 ... another example of something easy to check is core media types 01:40:56 q+ 01:41:22 ... but with other things, like trimming white space, maybe we can take the opportunity to revisit whether this needs to be an assertion 01:41:30 ... if these things are difficult to test 01:41:59 ack wendyreid 01:42:09 ... so let's start with the assertions that are easy to confirm, and built a framework 01:42:27 wendyreid: before we decide anything, first, we need to understand our scope 01:42:44 ... next few days, we just need to decide a direction, and some assignment of tasks 01:42:55 ... first, what is the scope? 01:43:10 ... we have to test all the must statements, this is non-negotiable 01:43:28 ... but we have other statements, e.g. support for javascript 01:43:54 ... but how much javascript support do we want to test? How thorough does the support need to be? 01:44:17 ... do we mean vanilla, react, angular? 01:44:31 ... Another thing, what is our testing methodology? 01:45:03 ... one potential way, test as a series of statements, with particular statements that can be tested via automation 01:45:16 https://docs.google.com/spreadsheets/d/1wOe-6MqFk296dCoRUmrd3ghmVXH3yM-i97hFOuGlX4k/edit#gid=1730700660 01:45:36 ... for tasks, we need to figure out how to divvy up the responsibility 01:45:57 dauwhe: this google sheet is a first attempt at identifying testable assertions 01:47:24 ... there's a lot in here, testing is going to take significant amounts of time 01:47:40 q+ 01:47:40 ... ideally there'd be a test lead who would direct and organize 01:47:45 ... any volunteers? 01:47:49 ack dauwhe 01:47:52 ack Garth 01:48:00 Garth: awesome sheet dave! 01:48:15 dauwhe: it isn't complete 01:48:44 Garth: our total number of tests would still probably be less than what we had on epubtest 01:49:29 ... i'm representing an rs that has chosen not to support js 01:50:11 ... i don't think an rs should fail automatically if it fails the js test 01:50:46 dauwhe: js support is optional, so we couldn't have all tests dependent on js support 01:50:49 ack zhengxu 01:51:05 zhengxu: i could help create a test epub 01:51:10 q+ 01:51:54 q+ 01:51:56 q+ 01:52:14 ack dauwhe 01:52:16 ... if we had a standard file that could be loaded into each rs, and the results could be collated, that'd be a good start 01:52:47 dauwhe: based on my experience in other wg, in css for example, a lot of the tests were donated by the browsers themselves 01:53:14 ... maybe the rs could donate some of the tests that they use internally? 01:53:44 q? 01:53:55 zhengxu: well, some of the tests developed for an rs will only make sense for that rs 01:54:07 ... but i could contribute to a communal test suite 01:54:48 wendyreid: the tests i've written to test kobo rs have been posted in public, they'd work 01:55:16 ... we have to test all the normative statements (musts, shoulds), but we also make informative statements in spec 01:55:28 ... maybe we should test these informative statements too 01:55:29 ack wen 01:55:40 ... best practice type stuff 01:55:56 ... should these statements form part of our testing scope? 01:56:47 ack Geor 01:56:58 ... although we should focus on the tests which get us through the CR process 01:57:32 q? 01:58:31 George: we could ask rs to donate their tests and tell us how they perform, and have other people validate these reported results 01:58:49 q? 01:58:58 ... rs have a business case for contributing, but we'd also have a safeguard against exploitation 01:59:51 q+ 01:59:55 q+ 02:00:47 wendyreid: we have a tool that someone wrote to pull must and should statements out of the spec for audiobooks/pub manifest 02:01:05 ... we should start by asking if we could repurpose this tool for our own spec 02:01:17 ack dauwhe 02:01:39 dauwhe: we need to do a lot of planning before we start writing tests 02:01:50 ... there's a lot of work to do to define scope 02:02:23 ... do we do all this in our existing repo? or start a new testing-specific repo? 02:02:40 q? 02:02:53 ack duga 02:03:05 ... some of these things require input from W3 staff contact 02:03:33 duga: as rs implementor, we don't really test against spec, we test against epubs 02:04:37 ... would it be more useful to go through all the weird edge cases we deal with, and come up with tests based on that? 02:04:38 q? 02:04:49 ... not sure what else we could offer, in terms of donating tests 02:05:05 q+ 02:05:32 ... in terms of js testing, not sure how this would work in practice 02:05:37 ack zhengxu 02:05:51 ... if we get an epub with js, we can just not display the js, and that would also be valid... 02:06:38 zhengxu: we can create subfolders to categorize tests 02:06:48 q+ 02:06:49 ... populate the subfolders with test epubs 02:06:59 ack dauwhe 02:07:04 George_ has joined #epub 02:07:26 q+ 02:07:50 ack shiestyle 02:08:00 dauwhe: this will be a learning process, maybe we could pick a section of a spec and try different testing ideas on this section 02:08:38 shiestyle: in japan, rs browser based rs just convert epub to images, and display those images in a browser window 02:08:50 ... these rs would be inoperable with js based testing 02:09:27 wendyreid: rs will be running the tests, but the test results will be relied upon by authors 02:09:56 ... so what would an author want to see out of these tests? What would an author find useful? 02:10:56 dauwhe: we have a number of people who have expressed interest in helping with testing 02:11:05 ... i would help too 02:11:12 ... we should consult with Ivan tomorrow 02:11:40 ... and then collect a group of people who will be responsible, who could then meet outside regular wg meetings 02:11:40 +1 02:11:46 to baby step 02:11:48 ... and report back to the entire wg 02:12:54 scribe+ LauraB_ 02:13:32 wendyreid: FX: a11y. One of the biggest problems is that we don't have a lot of advice here. 02:13:48 FXL is growing, it's not going away so we have to deal with it. 02:14:32 @wendyreid : did some reachout via Twitter and got some expressions of interest 02:15:07 https://comica11y.humaan.com/ 02:15:10 Some suggestions. Project, a link to which Wendy will post. 02:15:44 This project was developed by Human (a studio). Dev met with Wendy to explain their process and challenges. 02:16:37 That dev said it's really difficult to develop this content. They used SVGs + captions. Widgets to change page layout, font size -- things that were common to EPUB. 02:17:18 But they use dynamic SVGs that regenerates on the fly. Translates into 30 languages and adjust based on line length. 02:17:26 Not sustainable. Too much work. 02:18:00 Most useful feature was captioning -- caption that shows across the bottom of the page. They are considering developing it further. 02:18:24 George: Comments about how cool this project was. 02:18:47 wendyreid: Loved Comicly, but not sustainable. 02:19:02