23:59:11 RRSAgent has joined #epub 23:59:11 logging to https://www.w3.org/2021/01/07-epub-irc 23:59:16 Zakim has joined #epub 23:59:23 zakim, start meeting 23:59:23 RRSAgent, make logs Public 23:59:24 please title this meeting ("meeting: ..."), wendyreid 23:59:26 present+ 23:59:39 meeting: EPUB 3 Working Group Telco Jan 7, 2021 23:59:47 chair: wendyreid 00:00:05 present+ 00:00:26 MasakazuKitahara has joined #epub 00:00:31 marisa has joined #epub 00:00:35 present+ 00:01:02 present+ 00:01:11 present+ 00:01:34 BenSchroeter has joined #epub 00:01:44 agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021Jan/0000.html 00:01:48 present+ 00:02:26 present+ 00:03:06 scribe+ 00:03:26 present+ 00:03:28 wendyreid: welcome back everyone 00:04:04 ... today we have 3 open issues that weren't finished during the last meeting 00:04:17 ... these are either older, or ones which came up during testing 00:04:20 https://github.com/w3c/epub-specs/issues/1325 00:04:27 Topic: Clarify language tag values 00:04:30 issue, 1325 00:05:12 wendyreid: there's an open issue in epubcheck repo re. dc:language, specifically, whether it has to be well formed or valid 00:05:32 ... currently we require one conforming dc:language value in the OPF 00:06:14 ... some earlier discussion resulted in conclusion that well formed dc:language value wasn't of great use 00:06:23 present+ Garth 00:06:31 ... this is in line with other specs 00:07:34 ... by well formedness, we are referring to bcp47 00:07:45 Garth_: is there a specific proposal? 00:08:09 wendyreid: Matt didn't come up with new language 00:08:15 DQ has joined #epub 00:08:23 ... but the gist, i think, was to drop the MSUT to a SHOULD 00:08:31 s/MSUT/MUST 00:08:54 BenSchroeter: is it a should in LTLI? 00:09:03 wendyreid: yes, and the idea is to align with that language 00:09:16 BenSchroeter: there are a11y implications to this change... 00:09:50 wendyreid: currently epubcheck doesn't check the value of dc:language, only that you have one 00:10:10 BenSchroeter: and under a SHOULD, epubcheck functionality would remain the same 00:10:26 Garth_: I thought that a SHOULD meant that epubcheck would only throw a warning? 00:11:24 wendyreid: acknowledge point about a11y, but the a11y guideline could be updated to require a valid bcp47 language declaration 00:11:59 duga has joined #epub 00:12:10 present+ 00:12:16 ... RS also has some part to play in this, as it may or may not honor the language attribute value, vs preferring what the ONIX says, etc. 00:13:46 ... clarifying the issue in epubcheck, the open issue is that epubcheck does not validate the content of the dc:language, only that it is present and is well formed 00:14:34 q+ 00:14:48 ack duga 00:14:54 ... and making this a SHOULD in our spec would not change that behaviour in epubcheck 00:16:52 duga: *reviewing what the spec actually says* 00:17:14 wendyreid: so the spec actually doesn't make a reference to "well formedness", only "valid" 00:17:40 marisa: *reviewing Matt's comments on this issue* 00:18:12 ... reviewing the epubcheck codebase, there are checks for both MUST assertions and SHOULD assertions 00:18:13 q+ 00:18:24 ... so I think Garth_ is right about the epubcheck warning 00:18:57 ack Garth_ 00:19:09 ... so if we change the spec to say SHOULD, maybe epubcheck should be changed to throw a warning (but not an error) 00:20:26 wendyreid: as opposed to the current behaviour, where it throws an error only if dc:language is missing completely 00:20:45 ... and does nothing otherwise 00:21:16 BenSchroeter: we should clarify what Matt is advocating here: either 1) downgrading from MUST to SHOULD, or 2) removing it completely 00:21:46 wendyreid: I think we should give authors something to work with, rather than being silent, but maybe Matt should come up with the specific language 00:22:08 s/specific language/specific revision to the spec 00:23:54 https://github.com/w3c/epub-specs/issues/1422 00:24:03 issue, 1422 00:24:07 Topic: Missing conformance criteria around item properties 00:24:46 wendyreid: essentially, the content side of the spec says that authors must set the scripted property on items, but there's no equivalent language in the RS side of the spec 00:25:07 ... no prescribed behaviour for what RS should do if the property is missing 00:25:24 ... applies to other properties, but scripting is a good example of this discrepancy 00:25:52 ... can either leave the RS spec as is, or we can add some language to prescribe behaviour if this is important 00:26:29 q+ 00:26:43 Garth_: in another discussion, about I believe MathML, I think we ended up saying that these properties are useful to RS, but not something they can absolutely rely on 00:27:34 ack duga 00:27:40 wendyreid: there was a suggestion in the issue that if the property is absent, the RS could in theory choose not to enable the script, but this goes against the expectations of authors is seems counter productive 00:28:30 duga: i can see how RS could use the presence or absence of these properties to modify RS behaviour 00:28:48 ... it is not trivial to ask an RS to just look at a document is determine for itself whether it has scripts or not 00:29:17 s/is determine/and determine 00:29:45 ... so that's a point in favor of leaving it 00:30:59 BenSchroeter: *reviewing the differing positions as presented in the issue* 00:31:21 ... i think the rub is whether we should require the authoring requirements have a 1-to-1 correspondence to the RS requirements 00:31:32 ... and i don't think we've done that 00:32:02 wendyreid: leaning towards leaving it as is 00:32:28 ... with the proviso that we can come back to this after we have the larger discussion about scripting 00:32:37 +1 to leave it as is 00:32:52 +1 00:32:53 Proposal: Close #1422, leaving the language in the content document as is 00:32:56 +1 00:32:58 +1 00:33:01 +1 00:33:03 +1 00:33:04 +1 00:33:08 +1 00:33:10 +1 00:33:11 +1 00:33:22 RESOLVED: Close #1422, leaving the language in the content document as is 00:33:45 https://github.com/w3c/epub-specs/issues/1313 00:33:47 Topic: The default value of rendition:flow 00:33:50 issue, 1313 00:33:57 wendyreid: this came up during testing 00:34:32 ... rendition:flow is a property by which an author can determine if pagination style is scrolled, paginated, or auto 00:34:41 ... if the RS supports it 00:35:22 q+ 00:35:27 ... the issue is that the spec says that the default value is auto, and that the RS may choose to support only the default 00:35:28 ack duga 00:35:47 ... since auto means that its basically the RS's choice, does this make the assertion untestable? 00:36:04 duga: i think this is solved by saying that the default is auto, period. 00:36:57 ... with the understanding that if authors are not explicit, then they get default functionality 00:37:29 wendyreid: to clarify, W3C says any time we make a MUST statement, the assertion must be accompanied by a test 00:37:45 ... or, the statement shouldn't be MUST 00:37:56 ... if this results in something untestable, we're going to run into issues later 00:38:23 BenSchroeter: or change MUST to SHOULD? 00:39:10 Garth_: that would only mean that the RS SHOULD do whatever it wants. It works around the W3C's testability requirement, but doesn't make much of a difference 00:39:23 Proposed: Change the language for rendition:flow to define the default is auto, but remove the MUST statement/ untestable assertion 00:39:28 s/a difference/a functional difference 00:39:37 +1 00:39:39 +1 00:39:40 +1 00:39:43 +1 00:39:44 +1 00:39:45 +1 00:39:46 +1 00:39:48 +1 00:40:01 RESOLVED: Change the language for rendition:flow to define the default is auto, but remove the MUST statement/ untestable assertion 00:40:16 Topic: FXL Accessibility 00:41:33 wendyreid: how do we want to tackle this? There are options. We could form a taskforce that meets separately. Or we can continue to just open issues and log PRs. Or dedicate upcoming meeting time to talk about this. 00:41:59 q+ 00:42:01 ... I'm leaning towards task force, though this would place additional scheduling burden on task force members to meet on their own 00:42:06 ack BenSchroeter 00:42:37 BenSchroeter: even if we do open issues and PRs, at some point we'll have to talk about those issues as a group 00:42:55 ... especially regarding the more hotly debated issues 00:43:39 wendyreid: right now there are three main approaches to a11y 00:43:49 ... explore the extent of svg 00:44:11 ... clearer language about implementing multiple modalities 00:44:47 ... the most pie in the sky option, some kind of overlay that creates a layer specifically for a11y technologies, maybe involving audio 00:45:19 ... people could explore these options on their own, and report their findings back to the main group 00:46:08 BenSchroeter: maybe we could start running these discussions in the main group, and then breaking out to a task force once we've decided on a more concrete direction? 00:46:51 ... or after we decide that we need a compromise of the 3 directions 00:47:17 wendyreid: yeah, perhaps the a11y approach might depend on the type of content 00:48:33 BenSchroeter: aside there was a very interesting accessible ebook example presented at AHG recently 00:48:48 ... maybe some ideas for directions to explore there 00:49:31 Topic: AOB? 00:50:15 s/maybe epubcheck should be changed to throw a warning (but not an error)/epubcheck would be expected to throw a warning, not an error; but really it doesn't change the amount of work required for epubcheck, so even a SHOULD could be unrealistic./ 00:50:15 zakim, end meeting 00:50:15 As of this point the attendees have been toshiakikoike, MattChan, MasakazuKitahara, marisa, shiestyle, wendyreid, BenSchroeter, Karen, Garth, duga 00:50:17 RRSAgent, please draft minutes 00:50:17 I have made the request to generate https://www.w3.org/2021/01/07-epub-minutes.html Zakim 00:50:21 I am happy to have been of service, MattChan; please remember to excuse RRSAgent. Goodbye 00:50:25 Zakim has left #epub 00:50:55 rrsagent, make minutes public 00:50:55 I'm logging. I don't understand 'make minutes public', wendyreid. Try /msg RRSAgent help 00:51:47 rrsagent, make logs public 01:28:57 duga has joined #epub 02:05:11 duga has joined #epub 05:07:33 ivan has joined #epub 05:41:41 duga has joined #epub 09:09:39 ivan has joined #epub 09:13:46 ivan_ has joined #epub 09:56:26 ivan has joined #epub