23:55:12 RRSAgent has joined #epub 23:55:12 logging to https://www.w3.org/2021/06/10-epub-irc 23:55:14 RRSAgent, make logs Public 23:55:16 please title this meeting ("meeting: ..."), dauwhe 23:55:22 meeting: EPUB 3 WG Telecon 23:55:28 chair: dauwhe 23:56:01 dauwhe has changed the topic to: https://lists.w3.org/Archives/Public/public-epub-wg/2021May/0048.html 23:56:05 shiestyle has joined #epub 23:56:25 dauwhe has changed the topic to: https://lists.w3.org/Archives/Public/public-epub-wg/2021Jun/0024.html 23:56:26 wendyreid has joined #epub 23:57:37 mgarrish has joined #epub 23:58:32 toshiakikoike has joined #epub 23:59:15 MattChan has joined #epub 23:59:16 present+ 23:59:25 present+ 23:59:30 MasakazuKitahara has joined #epub 23:59:35 present+ 23:59:46 present+ 00:00:41 present+ 00:00:41 present+ 00:00:49 present+ 00:01:13 scribe+ 00:02:32 BenSchroeter has joined #epub 00:02:40 present+ 00:02:46 marisa has joined #epub 00:03:02 dlazin has joined #epub 00:03:26 https://github.com/w3c/epub-specs/issues/1690 00:03:28 TOPIC: Removing the PLS section 00:03:50 present+ 00:04:20 mgarrish: basically we created this for 3.0 without W3C input, and as it turns out there hasn't been wide uptake 00:04:54 ... if we really want this to work it shouldn't be the epub content document spec 00:05:38 ... is it time to remove this until there is some real world implementation? possibly after taking this to W3C 00:06:16 dauwhe: so the spec text basically just describes how to use the link element, which is really an HTML thing, not an epub specific thing 00:06:38 ... do we keep statements about these things not requiring fallbacks? 00:06:59 mgarrish: we already say link element doesn't need fallback, nothing changes by cutting this 00:07:43 dauwhe: yes, i'm also concerned about people seeing this and thinking that it does more than it really will 00:08:18 mgarrish: right, and if we really want this to work, we should take it from here and make a standard for it, or turn it into a note 00:09:22 marisa: good in theory, but i've never seen it used in the wild 00:09:59 mgarrish: there are also other avenues to pursue to get to the same goal, parts of ARIA for example 00:10:17 Proposed: Remove PLS section from the authoring document, close issue 1690 00:10:26 +1 00:10:29 +1 00:10:31 +1 00:10:33 +1 00:10:34 +1 00:10:37 +1 00:11:04 +1 00:11:08 dauwhe: do we need to have the CG look at it? No? 00:11:13 https://www.w3.org/TR/2021/WD-spoken-html-20210518/ 00:11:15 RESOLVED: Remove PLS section from the authoring document, close issue 1690 00:11:41 wendyreid: if any issues come up, we can redirect to one of the WG or CG that are working on this already 00:12:05 marisa: interesting work done with SSML in HTML 00:13:21 https://github.com/w3c/epub-specs/issues/1681 00:13:23 TOPIC: URLs and the package document 00:14:08 dauwhe: this is a bunch of issues that revolve around how you interpret URLs in the package document, especially if they're absolute URLs 00:14:14 ... came from an issue in epubcheck 00:14:18 https://github.com/w3c/epub-specs/issues/1374 00:14:32 ... and there's also an older issue about what the IRI of the package document is 00:14:40 https://github.com/w3c/epub-specs/issues/1688 00:14:42 ... or what if there are file scheme URLs in the manifest 00:15:01 https://github.com/w3c/epub-specs/issues/1686 00:15:27 ... and what happens if two URLs resolve to the same item in the manifest? 00:16:51 mgarrish: in epubcheck there was a root-relative URL that caused an error, and that spawned all of this 00:17:03 ... e.g. "/something/thing" 00:17:13 ... so what is the root of the epub? 00:17:31 ... to me it doesn't make sense that we even allow these root-relative URLs 00:17:40 ... the root differs based on the RS 00:18:57 ... and Romain mentioned that we require that all resources resolve to something inside container, but depending on what RS does, there is even ambiguity about what that even is 00:20:08 dauwhe: in issue 1688 Romain he suggests that manifest items should have one of the special schemes (EXCEPT file) 00:20:36 mgarrish: there are edge cases where file scheme items make sense, but not generally for epub 00:21:00 dauwhe: it goes against epub as a portable format, and the file scheme ties the epub to a specific file system 00:21:25 ... how much out there does have file URLs on purpose, not by accident? 00:21:32 mgarrish: never heard of one 00:22:01 ... and they'd end up being remote resources 00:22:31 dauwhe: okay, so what if we just say no file URLs in epub? 00:22:46 ... what is the risk that we break something? 00:23:05 q? 00:23:08 ... maybe this is something where we try to enforce it and see if anyone complains 00:23:23 mgarrish: most RS probably won't do anything with file URL 00:23:32 ... probably security concern 00:23:57 wendyreid: depending on platform you might not even be able to access parts of the file system (e.g. iOS apps) 00:24:26 dauwhe: can we start by resolving on this point from 1688? 00:25:26 Proposed: Absolute URLs for manifest items should have a special scheme that is not "file", close issue 1688 00:25:29 +1 00:25:30 +1 00:25:31 +1 00:25:34 +1 00:25:35 +1 00:25:41 +1 00:25:46 +1 00:25:55 RESOLVED: Absolute URLs for manifest items should have a special scheme that is not "file", close issue 1688 00:26:10 MasakazuKitahara has joined #epub 00:26:21 dlazin: is there a use case for some of these other schemes? Why would you have an FTP in your epub? 00:26:48 mgarrish: if we go too far, do we prevent future stuff? will we have to come back and re-add this in the future? 00:26:58 ... FTP kind of fits within the web framework 00:27:14 ... maybe we just leave it to authors to stick with HTTP, HTTPS, etc. 00:27:41 present+ 00:28:29 BenSchroeter: is the idea that if we disallow file scheme, then we also disallow "slash URLs"? 00:28:40 mgarrish: not sure those are the same 00:29:25 ... i think 1681 is contingent on us forcing RS to unpack epub in a certain way 00:29:37 ... otherwise we can't say there is a single consistent root that can be referenced 00:29:58 ... and we don't tell RS how/where to unpack right now 00:31:01 ... this kind of came up 5 years ago with multiple rendition, but we left it buried in the discussions we had 00:31:10 dauwhe: what would be the consequences of forbidding root-relative paths? 00:31:27 mgarrish: not sure there are any, because epubcheck had forbidden these until a recent update 00:31:46 ... we're reasonably safe from backwards compat point of view 00:31:57 dauwhe: and this is just for href on manifest? 00:32:06 mgarrish: no, this would be anywhere, e.g. in content docs too 00:33:08 ... all the "../" stuff would still be okay 00:33:56 ... i proposed somewhere that we say all content must be below the content document 00:34:09 s/content document/package document 00:34:36 ... if we could enforce an authoring requirement that made a root, then we could enforce these relative paths 00:34:56 ... but maybe its cleaner to just disallow them 00:35:01 q? 00:35:15 q+ 00:35:22 ack dl 00:35:29 dlazin: do we support the base tag? 00:35:42 ... and does that have implications for the handling of these issues? 00:36:04 dauwhe: we've been phasing out xml base, its been forbidden from package file or example 00:36:13 s/or example/for example 00:36:34 dlazin: the base tag allows you to define what the relative path is relative to 00:36:56 ... so if we're allowing or disallowing certain types of URLs, maybe we should take a stance on base too 00:37:05 ... not sure what stance though 00:37:51 mgarrish: base would force you to have all external resources, right? It exists, but I don't imagine anyone really going there 00:38:06 https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base 00:38:18 marisa: there was a resolution a few weeks ago about dumping xml base from the spec 00:38:33 dauwhe: and that's separate from the HTML base element 00:39:16 ... i think i just want to say no root-relative URLs 00:39:51 dlazin: if you set base to some website, and then use root-relative URLs, your URLs would appear to be relative, when they are actually absolute 00:40:00 ... but maybe that's too far of a stretch 00:40:27 dauwhe: but can we really say anything about base because its part of HTML? 00:41:36 mgarrish: so you must not use root-relative URLs unless you use a base? 00:41:48 ... but it also applies to SVGs, to the package document... 00:42:31 dlazin: what was the harm in not banning root-relative? 00:43:04 mgarrish: because the RS might treat zip root as the root, but they could also treat location of package doc as root 00:43:18 ... so no consistent root 00:43:42 dlazin: maybe permit it, but use SHOULD NOT? 00:44:02 ... is it acceptable for an author to write an epub for a specific RS? 00:44:26 ... and where it has undefined behavior for other RS 00:44:34 ... probably acceptable, right? 00:44:47 dauwhe: yes, e.g. with books that only work with iBooks because of scripting support 00:45:32 mgarrish: maybe just a note that root-relative could cause issues if authors use it? 00:46:30 dauwhe: so does that mean that there are epubs that could be build to work in some RS, but expose an interop issue if opened in another RS? 00:46:38 mgarrish: right 00:46:46 s/could be build/could be built 00:47:10 mgarrish: usually this happens in epubs that try to go from one folder to a sibling folder 00:47:23 ... but when all content is below the package document its fine 00:47:40 ... but we don't specify that right now, only that content must be below the root 00:48:37 dauwhe: not sure what the right course of action is, but maybe we can continue this another time with Romain present 00:49:33 wendyreid: we need RS people here on next call that know exactly what RSes are doing right now 00:50:03 marisa: one of the github threads has a sample, but I wasn't able to download it 00:50:16 ... maybe if we wrote to the mailing list Romain could provide samples 00:50:35 ... would also love to have a list of epubs that must absolutely continue to work 00:51:26 I have filed https://github.com/w3c/epub-specs/issues/1699 00:51:33 mgarrish: also, there's not much hand authoring, and most tools will put all the content into one folder 00:51:57 ... we only ran into an issue with this with multiple renditions, and that hasn't really gone anywhere 00:52:06 ... so is this maybe more of a theoretically issue 00:52:39 s/theoretically/theoretical 00:53:04 TOPIC: AOB? 00:53:18 wendyreid: the agenda item about the a11y note is postponed 00:53:40 dauwhe: and a reminder that we have TFs 00:53:49 wendyreid: locators TF has slightly changed times 00:54:26 ... moved to the same week, but friday at 10 am 00:54:32 ... eastern time 00:54:38 ... boston 00:55:47 dlazin: do we know what the fallback algorithms are in JP RS? 00:56:12 ... in most RS we're familiar with, they have a proprietary way of counting position 00:56:35 ... e.g. every 1000 bytes, or every 1024 bytes of the zipped file size 00:56:53 ... would love to know what JP RS are doing 00:57:38 shiestyle: I'll encourage JP RS people to join the TF 00:58:10 BenSchroeter: i think there's an issue with the TF invite 00:58:15 wendyreid: okay, i'll fix 00:58:39 Zakim, end meeting 00:58:39 As of this point the attendees have been toshiakikoike, MattChan, MasakazuKitahara, wendyreid, dauwhe, shiestyle, mgarrish, BenSchroeter, marisa, dlazin 00:58:43 RRSAgent, please draft minutes 00:58:43 I have made the request to generate https://www.w3.org/2021/06/10-epub-minutes.html Zakim 00:58:45 I am happy to have been of service, dauwhe; please remember to excuse RRSAgent. Goodbye 00:58:49 Zakim has left #epub 01:01:21 RRSAgent: bye 01:01:21 I see no action items