14:43:56 <RRSAgent> RRSAgent has joined #epub
14:43:56 <RRSAgent> logging to https://www.w3.org/2022/03/11-epub-irc
14:43:57 <Zakim> RRSAgent, make logs Public
14:43:59 <Zakim> please title this meeting ("meeting: ..."), ivan
14:44:04 <ivan> github-bot, bye
14:44:04 <github-bot> github-bot has left #epub
14:44:23 <ivan> ivan has changed the topic to: Meeting Agenda 2022-03-11: https://lists.w3.org/Archives/Public/public-epub-wg/2022Mar/0004.html
14:44:24 <ivan> Chair: dauwhe
14:44:24 <ivan> Date: 2022-03-11
14:44:24 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2022Mar/0004.html
14:44:24 <ivan> Meeting: EPUB 3 Working Group Telco
14:44:24 <ivan> Regrets+ ToshiakiKoike, MasakazuKitahara
14:49:51 <dauwhe> Regrets+ Wendy
14:58:26 <BenSchroeter> BenSchroeter has joined #epub
14:58:42 <dauwhe> present+
14:59:18 <ivan> present+
14:59:27 <MattChan> MattChan has joined #epub
14:59:28 <ivan> present+ avneesh
14:59:31 <avneeshsingh> avneeshsingh has joined #epub
14:59:55 <zheng_xu> zheng_xu has joined #epub
14:59:57 <avneeshsingh> present+
15:00:11 <ivan> present+ BenSchroeter
15:00:16 <ivan> present+ MattChan
15:00:22 <ivan> present+ tzviya
15:00:26 <ivan> present+ rickj
15:00:37 <ivan> present+ gregorio
15:00:45 <gpellegrino> gpellegrino has joined #epub
15:01:14 <gpellegrino> present+
15:01:15 <ivan> present+ brady
15:01:29 <ivan> present+ zheng_xu
15:01:32 <rickj> rickj has joined #epub
15:01:35 <rickj> present+
15:01:37 <duga> duga has joined #epub
15:01:43 <duga> present+
15:02:28 <CharlesL> CharlesL has joined #epub
15:02:30 <ivan> present+ charles
15:02:34 <MattChan> scribe+
15:03:19 <dauwhe> https://github.com/w3c/epub-specs/issues/1464
15:03:32 <MattChan> dauwhe: we have a small number of items on the agenda today, let's get started
15:03:34 <ivan> topic: https://github.com/w3c/epub-specs/issues/1464
15:03:44 <MattChan> ... given that CR is approaching we want to work through our remaining issues
15:03:46 <MattChan> Topic: What does it mean to support a foreign resource?
15:04:01 <ivan> present+ billk
15:04:03 <MattChan> dauwhe: this is one we've discussed many times before, re. foreign resources and manifest fallbacks
15:04:26 <mgarrish> mgarrish has joined #epub
15:04:29 <MattChan> ... as you remember I made a bunch of test books, putting weird MIME types in spine with HTML fallback to see what would happen in real RS
15:04:31 <mgarrish> present+
15:04:42 <MattChan> ... much to my surprise I have not yet found one where fallback is displayed to end user
15:05:00 <MattChan> ... question is how do we interpret these tests? What are RS expected to do in these circumstances?
15:05:24 <duga> q+
15:05:27 <MattChan> ... one of the most straightforward examples is if I have JSON in spine with HTML fallback, pretty much every RS will display JSON in plain text the way a browser would
15:05:52 <MattChan> ... in some sense that's in keeping with HTML spec since that spec has instructions for how browsers should display all sorts of different MIME types
15:06:08 <ivan> -> Dave's reference to HTML spec on xml and text https://github.com/w3c/epub-specs/issues/1464#issuecomment-1018083509
15:06:20 <MattChan> ... similar thing might happen if you try to put XML in spine, where some RS will give you the browser style tree view
15:06:22 <duga> qq-
15:06:24 <duga> q-
15:06:29 <ivan> present+ george
15:06:38 <MattChan> ... we have something of a conflict between spec and reality, so what do we do? (if anything)
15:06:40 <Bill_Kasdorf__> Bill_Kasdorf__ has joined #epub
15:06:46 <MattChan> ... the idea of fallback is pretty woven through the spec
15:07:03 <MattChan> ... at least one RS will read the fallback chain, though unclear what it does with that data
15:07:15 <dauwhe> q?
15:07:19 <ivan> present+ JenG
15:07:19 <duga> q+
15:07:23 <MattChan> ... so, is the test with JSON in spine (as described above) failing?
15:07:25 <dauwhe> ack dug
15:07:25 <GeorgeK> GeorgeK has joined #epub
15:07:30 <Jen_G> Jen_G has joined #epub
15:07:38 <Jen_G> Present+
15:07:40 <Bill_Kasdorf__> present+
15:07:58 <MattChan> duga: fallbacks are at the resource level, but you still have to use the resource correctly
15:08:00 <GeorgeK> present+
15:08:16 <MattChan> ... a RS may well support JSON if read into a script, the test kind of misuses JSON
15:08:28 <MattChan> ... what happens if you reference an image from an audio resource?
15:08:44 <MattChan> ... you're still going to get weird rendering even if that image is cmt
15:08:53 <MattChan> ... we still require author to use resource in sensible way
15:09:11 <MattChan> dauwhe: say you are doing book about javascript and you want to hyperlink to JSON file
15:09:21 <MattChan> ... if you hyperlink to something it has to be in the spine, so it still has to work
15:09:45 <MattChan> duga: little weird to hyperlink to JSON in spine when author could style JSON text in their style to make it look correct visually
15:09:56 <MattChan> ... so i'm not sure what it means to support it
15:10:02 <ivan> q+
15:10:12 <MattChan> ... but i think it's valid to say that you've supported JSON if you just display to user
15:10:31 <dauwhe> ack iv
15:10:40 <MattChan> dauwhe: we had once envisioned special purpose RS that could display docbook format, for example, but where same epub could still be displayed reasonably in non-speciality RS
15:10:59 <rickj> For reference as a reading system, while we support scripting, we do not support manifest fallbacks.  We only support xhtml in the spine.  For example, if you want to show just an image at the content doc level in Bookshelf, you must wrap it in xhtml for us to be able to present it.
15:11:03 <MattChan> ivan: re. question about whether fallback should be used - strictly speaking, your test follows what the spec allows
15:11:26 <MattChan> ... but if nobody implements fallbacks, then it becomes an underimplemented feature of epub, and a problem
15:11:35 <ivan> https://github.com/w3c/epub-specs/issues/1464#issuecomment-1018083509
15:12:02 <MattChan> ... that said, I was intrigued by your comment back in January, because we rely on the HTML spec, and the HTML spec has statement of what to do with text files
15:12:31 <dauwhe> q?
15:14:00 <duga> scribe+
15:14:49 <AUbbink_> AUbbink_ has joined #epub
15:15:03 <AUbbink_> present+
15:15:05 <duga> ivan: Reading systems rely of webview which per html display text files properly (per that spec)
15:15:11 <mgarrish> q+
15:15:14 <dauwhe> q?
15:15:25 <dauwhe> ack mg
15:15:25 <duga> ... we should liberalize the spec and not force removing a usable feature
15:15:42 <duga> mgarrish: Not sure if opening up the spine is a good idea now
15:16:02 <duga> ... We can just restrict to epubs for now, to avoid controversy
15:16:25 <duga> ... Don't really like fallbacks, we have kind of made a mess of the html model
15:16:40 <dauwhe> q?
15:16:41 <duga> ... would love to get rid of it, but what happens to old content?
15:16:47 <ivan> q+
15:16:50 <dauwhe> ack iv
15:17:20 <duga> ivan: We can make deprecated, or say it is underimplemented
15:17:22 <rickj> q+
15:17:34 <duga> ... But we can find a backwards compat way of specifying it
15:17:49 <zheng_xu> q+
15:17:53 <dauwhe> ack ri
15:18:01 <duga> dauwhe: Can we avoid throwing away the concept, but make it clear RSes will never show the fallbacks?
15:18:41 <duga> rickj: Is this a case for some standard language to say there are not two implementations and it is dangerous to use?
15:18:44 <dauwhe> q?
15:18:48 <CharlesL> q+
15:19:00 <duga> ivan: Yes, underimplemented is our current term
15:19:03 <CharlesL> q-
15:19:08 <dauwhe> ack zh
15:19:33 <mgarrish> q+
15:19:37 <duga> zheng_xu: From implementor side, how to support foreign resources is passed of to web engine
15:19:39 <tzviya> zakim, what color is dauwhe's bikeshed?
15:19:39 <Zakim> I think Coral pink
15:20:03 <duga> ... But fallback is used in some case depending on region
15:20:47 <dauwhe> q?
15:20:50 <duga> ... So some resource will work in RS, but not others and it can't be wrapped in xhtml. How should we do specify this?
15:21:27 <duga> ... A normal browser just downloads the resource, but a RS still needs to be able to turn pages
15:21:55 <dauwhe> ack mg
15:22:35 <duga> mgarrish: If we put a big scary box in the manifest section it will help, but how do we tell people?
15:22:36 <duga> q+
15:23:09 <dauwhe> scribe+
15:23:36 <dauwhe> duga: we walks the fallback chain for something that should be displayed like html or svg
15:23:46 <dauwhe> ... but we haven't actually tested it
15:23:55 <dauwhe> ... we did add this intentionally
15:24:01 <dauwhe> ... we might use it in a few other places
15:24:15 <dauwhe> ... we have a list of what resources we expect at a particular point
15:24:22 <dauwhe> ... and find one on the list
15:24:28 <dauwhe> ... responding to Matt
15:24:49 <dauwhe> ... if no one supports this, their epubs are going to be stupid :)
15:25:00 <dauwhe> q?
15:25:03 <dauwhe> ack dug
15:26:04 <ivan> q+
15:26:06 <duga> dauwhe: It has been common to wrap things in <a> tags to make them bigger, but that isn't legal in epub
15:26:09 <dauwhe> ack iv
15:26:32 <duga> ivan: What does html spec say about images like that?
15:27:02 <duga> ... that is, what to do when the link is an image?
15:27:04 <tzviya> q+ to mention iframes
15:27:27 <dauwhe> https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-media
15:27:36 <duga> ivan: Whatever the html spec says is displayable, we should follow or at least allow
15:27:37 <GeorgeK> q+
15:27:55 <dauwhe> ack tz
15:27:55 <Zakim> tzviya, you wanted to mention iframes
15:28:32 <duga> tzviya: There is also linking with iframes that has been done in epub. It is clumsy, though, Agree with Ivan, we should allow what html allows
15:29:01 <dauwhe> ack geo
15:29:08 <duga> dauwhe: [Reading processing model for non-html content]
15:29:37 <ivan> q+
15:29:44 <duga> GeorgeK: This was presented as an a11y issue, but don't see any real a11y benefits here
15:29:49 <dauwhe> ack iv
15:29:54 <duga> ... So I am ok with getting rid of it
15:30:27 <duga> ivan: The big issue here is a .dmg or .exe file being linked
15:31:10 <duga> ... Maybe we need to make this much more explicit in the security section
15:31:12 <duga> q+
15:31:23 <dauwhe> ack du
15:31:25 <duga> ... This whole procedure seem obsolete
15:31:44 <dauwhe> duga: I don't think that security statement makes sense
15:31:57 <dauwhe> ... all that security stuff depends on manifest mime types, which would be false
15:32:09 <dauwhe> ... you shouldn't trust the package here
15:32:14 <dauwhe> ... we download all the resources
15:32:24 <dauwhe> ... my android reader downloads everythign in the manifest
15:32:37 <dauwhe> ... but then if you tell me I shouldn't download certain parts of the epub
15:32:50 <dauwhe> .... I don't think that restriction makes a lot of sense
15:32:57 <dauwhe> ... we shouldn't execute stray code from an epub
15:33:03 <dauwhe> ... I'm hoping that's clear already
15:33:15 <dauwhe> ... I don't see how we turn this into a security issue
15:33:57 <mgarrish> q+
15:33:58 <duga> dauwhe: There is a distinction between downloading as a RS, vs as an end user clicking on a navigation link that allows me to download
15:34:00 <dauwhe> ack mg
15:34:29 <duga> mgarrish: Are we saying we should allow anything in the spine?
15:34:57 <duga> dauwhe: I don't think we are talking about opening the spine
15:35:01 <duga> ivan: I agree
15:35:23 <duga> dauwhe: But we still have the existing epubs that have fallbacks
15:36:06 <ivan> q+
15:36:08 <dauwhe> ack iv
15:36:31 <duga> ivan: We may have to separate two situations. Let's put the spine aside for now
15:36:55 <mgarrish> q+
15:36:55 <duga> ... the other use case is an <a> element linked to a json file, what should the RS do?
15:37:08 <duga> ... I think we should just refer to the html spec in that case
15:37:36 <duga> ... The only reason we keep the fallback is for core media in the spine
15:37:45 <duga> ... Since there is existing content
15:38:08 <dauwhe> ack mg
15:38:11 <duga> ... We may end up with it being under implented when we exit CR
15:38:34 <duga> mgarrish: These aren't different cases - if it is linked to it must be in the spine
15:38:53 <duga> ivan: What if it is outside the epub?
15:39:06 <duga> mgarrish: In that case it opens in a new browser context
15:39:36 <duga> dauwhe: Say you click on that image that isn't in the spine, then we have all the nav issues (how do you go forward, bookmark, etc)
15:40:11 <duga> mgarrish: We have looked at pop out content, but have never gotten that far with it
15:40:27 <duga> ivan: Why does it have to be in the spine?
15:40:42 <duga> mgarrish: To avoid the nav issues
15:41:05 <duga> ... Once it is loaded in the viewport, there has to be a position in the spine so the RS can handle it
15:41:13 <Karen> Karen has joined #epub
15:41:18 <duga> q+
15:41:28 <dauwhe> ack du
15:41:40 <dauwhe> duga: this is related to linear=no
15:41:50 <dauwhe> ivan: it's in the spine but linear is no
15:42:09 <dauwhe> duga: it has to be in the spine to link to it
15:42:58 <tzviya> q+
15:43:04 <dauwhe> ack tz
15:43:21 <duga> tzviya: We have had this conversation after about every rev of the spec
15:43:55 <duga> ... and we end up saying we can't rewrite browser contexts, and this conversation has to be about RSes and not content
15:44:09 <CharlesL> q+
15:44:12 <dauwhe> ack ch
15:44:13 <duga> ... So it is more about RS paging and the concept of a page, and not content
15:44:29 <zheng_xu> q+
15:44:30 <duga> CharlesL: One thing a browser has is a back button
15:44:53 <duga> ... Also solves multiple references to a single place
15:44:57 <dauwhe> q?
15:44:59 <ivan> +1 to CharlesL
15:45:03 <duga> ... All problems are solved by the back button
15:45:03 <dauwhe> ack zh
15:45:30 <duga> zheng_xu: We have a back button, but then there is still the issue with bookmarks
15:45:57 <duga> dauwhe: History and html (ie back buttons) is really complex
15:46:04 <mgarrish> q+
15:46:38 <dauwhe> ack mg
15:46:40 <duga> zheng_xu: for this issue is the question how we can write a test?
15:47:01 <duga> mgarrish: Maybe there is some discussion to resurrect about the target of an <a>
15:47:16 <duga> ... So you could do this without having it in the spine
15:48:01 <duga> dauwhe: I don't really know what epub without fallbacks looks like
15:48:05 <ivan> q+
15:48:32 <duga> ... might need something that says a fallback is not likely to be presented
15:48:34 <dauwhe> ack iv
15:48:39 <tzviya> +1 to dauwhe
15:48:46 <duga> ivan: we must solve this before cr
15:48:55 <duga> q+
15:49:20 <duga> ... We need to say what happens to text
15:49:31 <duga> dauwhe: RSes understand JSON
15:49:34 <dauwhe> ack du
15:50:42 <dauwhe> duga: from a CR perspective a test for this is JSON in the spine, saying that if you see this means the RS supports JSON
15:51:02 <duga> dauwhe: And that is basically the test I made
15:51:41 <dauwhe> duga: we are trying to define support, when the reading system should define it
15:51:49 <duga> dauwhe: Agree
15:52:15 <duga> ivan: We don't want to say RSes should support types html says they should
15:52:17 <duga> q+
15:52:20 <dauwhe> ack du
15:52:32 <dauwhe> duga: it's up to the RS to decide if they're gonna use a fallback
15:52:37 <ivan> q+
15:53:02 <dauwhe> ... if you put JSON in you're supposed to put in a fallback. The RS chooses.
15:53:15 <dauwhe> ack iv
15:53:23 <duga> dauwhe: And no RSes would display the fallback
15:53:53 <duga> ivan: Isn't it correct that all RSes that are newer and rely on browser cores would display json correctly
15:54:20 <duga> ... We are saying for epub content to be correct you must put a fallback even though RSes don't need that
15:54:22 <duga> q+
15:54:26 <dauwhe> ack du
15:54:32 <dauwhe> zakim, close queue
15:54:32 <Zakim> ok, dauwhe, the speaker queue is closed
15:54:47 <dauwhe> duga: fallbacks are not just because RSs cant display something
15:55:03 <dauwhe> ... we did this because we need a11y info
15:55:22 <dauwhe> ... we could display an image in the spine, no problem. But there's no a11y and no styling.
15:55:50 <dauwhe> ... it may look great somewhere and looks terrible somewhere else
15:56:02 <ivan> q+
15:57:14 <dauwhe> ... let's have authors style things, rather than chasing reading systems
15:57:20 <dauwhe> https://docs.google.com/spreadsheets/d/1qer78BUDpaDb_nav_wuhjeyjMD8Fk7UiakoP2sBf5jc/edit#gid=0
15:57:30 <duga> dauwhe: Want time to disucss CR
15:57:33 <ivan> Topic: CR Review
15:57:46 <duga> ... We have a lot of specs - we need people to review them all
15:58:09 <duga> ... This is too big a job for one person, so we made a sign up sheet
15:58:18 <duga> ... we need volunteers
15:58:33 <ivan> q+
15:58:37 <dauwhe> ack iv
15:58:38 <duga> ... After people volunteer we will just assign people
15:58:41 <dauwhe> zakim, open queue
15:58:41 <Zakim> ok, dauwhe, the speaker queue is open
15:59:11 <duga> ivan: If you review and find problems, it would help if you submit github PR instead of telling us what to change
15:59:36 <duga> ... if you can't then of course report it anyway!
16:00:10 <CharlesL> CharlesL has left #epub
16:00:21 <ivan> rrsagent, draft minutes
16:00:21 <RRSAgent> I have made the request to generate https://www.w3.org/2022/03/11-epub-minutes.html ivan
16:01:06 <ivan> zakim, end meeting
16:01:06 <Zakim> As of this point the attendees have been dauwhe, ivan, avneesh, avneeshsingh, BenSchroeter, MattChan, tzviya, rickj, gregorio, gpellegrino, brady, zheng_xu, duga, charles, billk,
16:01:09 <Zakim> ... mgarrish, george, JenG, Jen_G, Bill_Kasdorf__, GeorgeK, AUbbink_
16:01:09 <Zakim> RRSAgent, please draft minutes
16:01:09 <RRSAgent> I have made the request to generate https://www.w3.org/2022/03/11-epub-minutes.html Zakim
16:01:11 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:01:12 <ivan> rrsagent, bye
16:01:12 <RRSAgent> I see no action items