13:28:05 <RRSAgent> RRSAgent has joined #epub
13:28:05 <RRSAgent> logging to https://www.w3.org/2022/03/25-epub-irc
13:28:08 <Zakim> RRSAgent, make logs Public
13:28:08 <Zakim> please title this meeting ("meeting: ..."), ivan
13:28:35 <ivan> ivan has changed the topic to: Meeting Agenda 2022-03-25: https://lists.w3.org/Archives/Public/public-epub-wg/2022Mar/0017.html
13:28:36 <ivan> Chair: dauwhe
13:28:36 <ivan> Date: 2022-03-25
13:28:36 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2022Mar/0017.html
13:28:36 <ivan> Meeting: EPUB 3 Working Group Telco
13:28:36 <ivan> Regrets+ toshiakikoike
13:37:11 <Karen> Karen has joined #epub
13:54:04 <dauwhe> dauwhe has joined #epub
13:57:48 <LauraB__> LauraB__ has joined #epub
13:58:22 <ivan> present+
13:58:31 <GeorgeK> GeorgeK has joined #epub
13:58:37 <ivan> present+ avneeshsingh
13:58:38 <LauraB__> present+
13:59:04 <MasakazuKitahara> MasakazuKitahara has joined #epub
13:59:07 <MattChan> MattChan has joined #epub
13:59:10 <MasakazuKitahara> present+
13:59:11 <wendyreid> wendyreid has joined #epub
14:00:12 <ivan> present+ wendy
14:00:12 <ivan> present+ rickj
14:00:12 <ivan> present+ dauwhe
14:00:24 <ivan> present+ gregorio
14:00:24 <rickj> rickj has joined #epub
14:00:28 <MattChan> present+
14:00:34 <rickj> present+
14:01:24 <dkaplan3> dkaplan3 has joined #epub
14:01:25 <ivan> present+ george
14:01:28 <MattChan> scribe+
14:01:28 <Avneesh> Avneesh has joined #epub
14:01:33 <ivan> present+ dan
14:01:37 <Avneesh> present+
14:01:39 <ivan> present+ jeff
14:01:45 <dkaplan3> present+
14:01:47 <dauwhe> https://github.com/w3c/epub-specs/issues/2093
14:01:48 <MattChan> TOPIC: Tolerance Margin for Media Overlays
14:02:03 <zheng_xu> zheng_xu has joined #epub
14:02:04 <duga> duga has joined #epub
14:02:06 <GeorgeK> present+
14:02:09 <duga> present+
14:02:11 <zheng_xu> present+
14:02:33 <MattChan> dauwhe: we say the sum of the duration for each MO document should equal the total duration, but we've never specified a margin or tolerance for this
14:02:39 <ivan> present+ JenG
14:02:41 <MattChan> ... suggestion was that perhaps we should do so?
14:02:42 <dauwhe> q?
14:02:48 <dlazin> dlazin has joined #epub
14:02:52 <ivan> q+
14:03:15 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
14:03:21 <MattChan> dauwhe: the suggestion was to allow 1 sec of tolerance before epubcheck would complain, to account for rounding errors
14:03:28 <MattChan> Avneesh: i think this is not controversial
14:03:29 <dauwhe> ack iv
14:03:36 <CharlesL> CharlesL has joined #epub
14:03:41 <CharlesL> present+
14:03:45 <mgarrish> mgarrish has joined #epub
14:03:50 <MattChan> ivan: what i learned when i learned when I tried to do something in MO, is that this value which is in the manifest is there to check the data
14:03:51 <Avneesh> present+
14:03:53 <Bill_Kasdorf> present+
14:03:59 <MattChan> ... mariassa has suggested that this is unnecessary
14:04:03 <Jen_G> Jen_G has joined #epub
14:04:11 <GeorgeK> ?+
14:04:12 <Jen_G> Present+
14:04:23 <MattChan> ... i can't say whether or not that is so, but if it is just for checking purposes, then allowing some rounding error is fine
14:04:24 <zheng_xu> q+
14:04:28 <Avneesh> q+
14:04:30 <duga> q+
14:04:38 <MattChan> ... not sure what the actual threshold should be, so for now I think 1 second is fine
14:04:41 <dauwhe> ack zhe
14:04:47 <BenSchroeter> BenSchroeter has joined #epub
14:04:53 <BenSchroeter> present+
14:05:04 <ivan> present+ jeff_xu
14:05:22 <MattChan> zheng_xu: from what i've implemented, the duration is variable for different players on different platforms
14:05:27 <MattChan> ... so i wonder if this is even useful
14:05:28 <dauwhe> ack av
14:05:45 <ivan> present+ charles
14:05:51 <MattChan> Avneesh: regarding 1 second, i feel this is more than enough. Maximum 50 ms is what i've used in the past
14:06:17 <MattChan> ... for large audios (120 hours), a tolerance of 150 ms was enough
14:06:19 <ivan> present+ mgarrish
14:07:04 <dauwhe> ack du
14:07:18 <MattChan> ... per my understanding, the purpose of stating this metadata is to allow RS to pull a "total duration" value into features like "you are 5 minutes into 12 total hours"
14:07:33 <MattChan> duga: can epubcheck just tell you the total duration value that should be in the manifest?
14:07:35 <ivan> q+
14:07:35 <GeorgeK> q+
14:07:41 <zheng_xu> q+
14:07:42 <MattChan> ... epubcheck can give you the right value, right?
14:08:13 <ivan> q-
14:08:20 <MattChan> mgarrish: epubcheck is checking the total time, yes. I guess it could output that value.
14:08:24 <dauwhe> ack ge
14:08:51 <MattChan> GeorgeK: my recollection is that its difficult to calculate some of these things precisely, depending upon the compression that is being used, resulting in it being off by a smidgen in each file
14:09:07 <dauwhe> ack zh
14:09:08 <MattChan> ... so this type of tolerance seems absolutely fine, 1 second seems fine
14:09:20 <ivan> +1 to George
14:09:20 <tzviya> tzviya has joined #epub
14:09:32 <MattChan> zheng_xu: as a RS i appreciate having the duration values for the whole book, and for each file
14:09:56 <dauwhe> q?
14:10:12 <ivan> present+ tzviya
14:10:18 <tzviya> present+
14:10:23 <MattChan> ... we use it as an indication of approximately where the user is, but it doesn't have to be that accurate
14:10:34 <MattChan> dauwhe: i'm not hearing an argument against the 1 sec tolerance
14:10:43 <MattChan> ... it's obviously a useful piece of metadata for people reading the book
14:10:45 <ivan> https://github.com/w3c/epub-specs/pull/2106
14:11:11 <MattChan> ... and having epubcheck able to tell if the sum = total is useful authoring tool, with 1 second tolarance
14:11:14 <zheng_xu> +1
14:11:18 <MattChan> s/tolarance/tolerance
14:11:20 <ivan> +1
14:11:29 <ivan> github-bot, bye
14:11:29 <github-bot> github-bot has left #epub
14:11:51 <wendyreid> Proposed: Merge PR 2106, close issue 2093
14:11:58 <dauwhe> q?
14:12:00 <dauwhe> +1
14:12:01 <mgarrish> +1
14:12:01 <MattChan> +1
14:12:02 <duga> +1
14:12:02 <MasakazuKitahara> +1
14:12:03 <wendyreid> +1
14:12:08 <LauraB__> +1
14:12:09 <Avneesh> +1
14:12:13 <Bill_Kasdorf> +1
14:12:13 <ivan> +1
14:12:13 <GeorgeK> +1
14:12:20 <zheng_xu> +1
14:12:27 <wendyreid> RESOLVED: Merge PR 2106, close issue 2093
14:12:39 <rickj> +1
14:12:40 <dauwhe> https://github.com/w3c/epub-specs/issues/2098
14:12:47 <ivan> topic: https://github.com/w3c/epub-specs/issues/2098
14:12:49 <MattChan> TOPIC: Scripted SVG
14:12:50 <BenSchroeter> +1
14:13:43 <MattChan> dauwhe: we can have scripted Top Level Content document, and scripted svg in iframe is container-constrained, but what about other cases?
14:14:28 <MattChan> mgarrish: so is scripted svg valid? And what about RS support for scripting? Are we saying you can put scripted SVG anywhere, but it might not be supported/
14:14:45 <MattChan> dauwhe: has anyone here ever put scripted SVG into an epub?
14:14:52 <duga> q+
14:14:58 <dauwhe> ack du
14:15:13 <MattChan> duga: it's a weird question, because its scripting, so it's already not guaranteed to work
14:15:36 <MattChan> ... the real question is do we explicitly make it illegal in some cases
14:16:08 <MattChan> ... i'm not sure why we would need to because there are already no guarantees when it comes to scripting, seems like an edge case we don't need to spend that much time on
14:16:13 <ivan> q+
14:16:28 <MattChan> dauwhe: i presume there have not been epubcheck bugs specifically about this?
14:16:49 <dauwhe> ack iv
14:16:59 <MattChan> mgarrish: no, it's valid, so we don't say you can't do it. But this doesn't fall into container-constrained
14:17:11 <MattChan> ivan: we should say yes it's allowed, and we should write some tests for it
14:17:22 <dauwhe> q?
14:17:41 <MattChan> ... i've already done some tests of svg in <object>, and i've tried putting svg in iframe
14:17:56 <MattChan> ... if testing reveals lack of support, then we will deal with that
14:18:03 <MattChan> ... but I wouldn't make it invalid
14:18:21 <MattChan> ... i think there is a big difference in HTML whether you use svg as object or in img tag
14:18:39 <MattChan> ... not sure if scripted svg will work in img tag even in HTML
14:19:05 <MattChan> mgarrish: no, scripting won't work in img tag
14:19:33 <MattChan> mgarrish: just strange to say that the container-constrained ones must be done in iframe (not object)
14:19:55 <MattChan> ... any reason why we can't add object to container-constrained?
14:20:05 <MattChan> ... what is container-constrained stopping?
14:20:06 <dauwhe> q?
14:20:39 <MattChan> duga: i think container-constrained was meant to make is to that the element wouldn't change its size, that it wouldn't interact with the DOM, or break anything else
14:20:47 <MattChan> ... but you don't really get that with object
14:21:02 <MattChan> ivan: so, as of right now, using object is illegal?
14:21:13 <MattChan> duga: it's fine, it just doesn't count as container-constrained
14:21:47 <MattChan> ... it means that the content document would be scripted, instead of scripting being limited to the element
14:22:11 <MattChan> mgarrish: we say you should support container-constrained scripting, but may support scripting in the content document
14:22:33 <MattChan> dauwhe: i found the part of HTML spec that says you can't have scripted svg in img
14:22:48 <MattChan> ... (it also says support for svg is not required for HTML spec)
14:22:57 <MattChan> ivan: okay, so what's the resolution?
14:23:04 <MattChan> dauwhe: we wait to see what tests tell us?
14:23:26 <MattChan> ivan: if we are responding to a specific question (as it says in issue) then we should make an editorial comment
14:23:55 <MattChan> mgarrish: we can mention that object does not count as container constrained
14:24:28 <MattChan> duga: it sounds like a good idea to add clarifying text, but is there something in our spec that makes people believe that putting something in an object tag would make something container-constrained?
14:24:57 <MattChan> mgarrish: content document is silent on whether or not it is valid to put scripted svg in object, you'd need to go to RS spec to see that
14:25:26 <MattChan> duga: i'm fine with making people who want to use scripting in epub read RS spec
14:25:45 <MattChan> ivan: my position is that a real question came up, so that means the core spec isn't clear enough. We should do something about that.
14:25:57 <MattChan> ... let's not make a big deal about it
14:26:35 <zheng_xu> q+
14:26:44 <dauwhe> ack zh
14:27:13 <MattChan> zheng_xu: what does the RS need to do beyond a normal web browser?
14:27:22 <MattChan> ... regarding scripted svg
14:27:29 <ivan> q+
14:27:33 <MattChan> dauwhe: i don't think there's anything
14:27:52 <MattChan> ... our basic idea is to make it easier for RS, to think of ways to allow some scripting that doesn't blow up the entire layout of the book
14:27:57 <dauwhe> ack iv
14:28:33 <MattChan> ivan: only minor thing is that an svg file should have access to the epubreadingsystem object
14:29:14 <MattChan> zheng_xu: in terms of bad usage of svg scripting, I don't know how to avoid this
14:29:20 <dauwhe> q?
14:29:30 <MattChan> ivan: as soon as we allow scripting, we can no longer prevent users from shooting themselves in the foot with it
14:30:04 <wendyreid> Proposed: Add note about container constraints to scripting section, close issue 2098
14:30:08 <dauwhe> +1
14:30:12 <ivan> +1
14:30:12 <tzviya> +1
14:30:12 <MattChan> +1
14:30:12 <rickj> +1
14:30:13 <CharlesL> +1
14:30:13 <mgarrish> +1
14:30:14 <wendyreid> +1
14:30:15 <BenSchroeter> +1
14:30:15 <MasakazuKitahara> +1
14:30:16 <Bill_Kasdorf> +1
14:30:19 <LauraB__> +1
14:30:26 <duga> 0
14:30:34 <zheng_xu> 0
14:30:43 <dlazin> present+
14:30:46 <wendyreid> RESOLVED: Add note about container constraints to scripting section, close issue 2098
14:31:07 <dauwhe> https://github.com/w3c/epub-specs/pull/2060
14:31:08 <ivan> topic: https://github.com/w3c/epub-specs/pull/2060
14:31:12 <MattChan> TOPIC: Separate collection authoring from specialization requirements
14:31:59 <MattChan> mgarrish: in reviewing this part of authoring spec, found that this was defining how to create collections
14:32:23 <ivan> -> Diff file for the PR https://pr-preview.s3.amazonaws.com/w3c/epub-specs/2060/8d4a9d6...ec770fc.html
14:32:24 <MattChan> ... initially what I did was take user requirements about how to create these collections and moved them into a separate subsection
14:32:45 <tzviya> q+ to ask if collection was EVER implemented
14:32:59 <MattChan> ... from there ivan and I discussed, and the question was that if we're not using collections anymore (and even the ones that have been authors have not met with huge uptake) can we deprecate the authoring of new collection elements?
14:33:14 <MattChan> ... then we wouldn't need to have all these weird requirements about authoring new collections
14:33:48 <MattChan> ... we already had a note saying that we had no intention of continuing these, so is it okay to officially deprecate the authoring of new collections?
14:34:06 <MattChan> dauwhe: but we keep the existing ones
14:34:20 <MattChan> mgarrish: yes, anything already created stay valid, there will not be issues with epubcheck
14:34:30 <MattChan> ... but you should not be creating new collection roles
14:34:45 <dauwhe> ack tz
14:34:45 <Zakim> tzviya, you wanted to ask if collection was EVER implemented
14:35:08 <MattChan> tzviya: reading back into history of collections, I'm very much in agreement that this should be removed
14:35:36 <MattChan> ... we were optimistic, but real world implementation was never a certain thing
14:36:07 <MattChan> mgarrish: the whole collection element was complicated, cases of collections within collections, complications to spine, etc.
14:36:24 <ivan> present+ BenSchroeter
14:36:26 <MattChan> ... i just want to make it clearer than the note that we're not moving towards this in the future
14:36:36 <dauwhe> q?
14:36:57 <MattChan> wendyreid: i don't think i've ever seen this in the real world
14:37:09 <MattChan> dauwhe: did the index spec refer to this?
14:37:33 <MattChan> mgarrish: there are a lot of specs that refer to collections, but they were just never really authored
14:37:40 <dauwhe> q?
14:37:43 <wendyreid> Proposed: Merge PR 2060, deprecate collections
14:37:46 <MattChan> ... and anything that did rely on this would still be valid
14:37:46 <mgarrish> +1111111111111111
14:37:46 <CharlesL> +1
14:37:47 <ivan> +1
14:37:49 <wendyreid> +1
14:37:49 <rickj> +1
14:37:49 <tzviya> +1
14:37:50 <dlazin> +1
14:37:50 <BenSchroeter> +1
14:37:50 <MasakazuKitahara> +1
14:37:51 <MattChan> +1
14:37:51 <LauraB__> +1
14:37:51 <Bill_Kasdorf> +1
14:37:52 <dauwhe> +1
14:37:58 <zheng_xu> +1
14:38:13 <wendyreid> RESOLVED: Merge PR 2060, deprecate collections
14:38:48 <Karen> Karen has joined #epub
14:39:06 <MattChan> TOPIC: Volunteers for review
14:39:08 <dauwhe> https://docs.google.com/spreadsheets/d/1qer78BUDpaDb_nav_wuhjeyjMD8Fk7UiakoP2sBf5jc/edit#gid=0
14:39:21 <MattChan> dauwhe: we are getting closer to CR, and as part of that we need more eyes on the spec
14:39:35 <MattChan> ... to make sure that things make sense, that we haven't missed anything obvious
14:39:51 <MattChan> ... we are looking for volunteers for this, and the signup sheet is linked above
14:39:55 <duga> q+
14:40:01 <dauwhe> ack du
14:40:01 <MattChan> ... volunteer now while you can still have your choice of which section to review
14:40:20 <ivan> q+
14:40:40 <MattChan> duga: i asked this earlier but, what's the timing for this? I will be gone for 2 weeks starting morning. I'm part way through what i've already signed up for, but not sure if I should claim more sections
14:41:06 <MattChan> wendyreid: please finish before you leave
14:41:13 <MattChan> ... some sections are very very short, btw
14:41:35 <MattChan> ... you don't need to be an expert on this. Just make sure the language is clear, that it makes sense, that it is readable and coherent
14:41:52 <MattChan> ... you can also flag grammar issues
14:42:05 <MattChan> mgarrish: I start to expect what is there, rather than reading it with fresh eyes
14:42:09 <MattChan> duga: so, the deadline?
14:42:19 <tzviya> q+ to suggest opening the review up to the CG
14:43:04 <MattChan> ivan: the CR means that the group feels that all technical issues are solved. So in essence, editorial things can still change later, after it is in CR. But it is more complicated if we find technical problems requiring changes to normative text later
14:43:18 <MattChan> ... duga if you can look at those sections where they may be technical issues, that would be helpful
14:43:22 <MattChan> ... editorial things can be done later
14:44:01 <MattChan> ... the point is, per charter, we are already late for CR. We should really aim for going to director for approval for mid-April
14:44:14 <MattChan> ... there are already a lot of PRs in queue, but most of those are editorial
14:44:23 <BenSchroeter> q+
14:44:38 <MattChan> ... wonderful if you could complete your reviews by the end of the week, but that may be too much to ask
14:44:57 <MattChan> duga: this is for everyone. Understanding the urgency is helpful, thank you.
14:45:23 <MattChan> ... i have a couple of changes (typos, minor edits), so I shouldn't spend time turning those into PR right now, I'll focus on technical things for now
14:45:39 <MattChan> ... those editorial ones can wait for later in April, and so on
14:45:40 <dauwhe> ack iv
14:45:42 <dauwhe> ack tz
14:45:42 <Zakim> tzviya, you wanted to suggest opening the review up to the CG
14:46:07 <MattChan> tzviya: I would suggest that we go to CR for some more volunteers
14:46:22 <MattChan> dauwhe: it's been filling up noticeably
14:46:25 <tzviya> s/CR/CG
14:46:39 <dauwhe> ack b
14:46:54 <MattChan> BenSchroeter: what if we come across something we'd like to change?
14:47:28 <MattChan> ivan: yes, we have a bunch of PRs, and you all incur the danger of looking at a version that may be altered via an in queue PR
14:47:38 <LauraB__> LauraB__ has left #epub
14:47:47 <MattChan> ... there is one PR that mgarrish is very busy with that will have impact on quite a number of areas
14:47:48 <dauwhe> q?
14:48:02 <MattChan> ... PR #2101
14:48:19 <MattChan> ... diffs are too many to display in Github UI
14:48:28 <MattChan> ... it is creative chaos
14:48:56 <MattChan> wendyreid: thank you everyone, the list is almost full!
14:49:42 <MattChan> tzviya: do you really want that many PRs? Won't you end up with merge conflicts?
14:49:54 <MattChan> mgarrish: so long as people are working in separate areas it shouldn't be that bad
14:50:30 <MattChan> dauwhe: okay, thank you everyone for a productive meeting
14:50:33 <MattChan> ... go forth and review
14:50:38 <MattChan> ... we will see you all next week
14:50:54 <ivan> rrsagent, draft meeting
14:50:54 <RRSAgent> I'm logging. I don't understand 'draft meeting', ivan.  Try /msg RRSAgent help
14:50:58 <ivan> rrsagent, draft minutes
14:50:58 <RRSAgent> I have made the request to generate https://www.w3.org/2022/03/25-epub-minutes.html ivan
14:51:32 <ivan> zakim, end meeting
14:51:32 <Zakim> As of this point the attendees have been ivan, avneeshsingh, LauraB__, MasakazuKitahara, wendy, rickj, dauwhe, gregorio, MattChan, george, dan, Avneesh, jeff, dkaplan, GeorgeK,
14:51:35 <Zakim> ... duga, zheng_xu, JenG, CharlesL, Bill_Kasdorf, Jen_G, BenSchroeter, jeff_xu, mgarrish, tzviya, dlazin
14:51:35 <Zakim> RRSAgent, please draft minutes
14:51:35 <RRSAgent> I have made the request to generate https://www.w3.org/2022/03/25-epub-minutes.html Zakim
14:51:37 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
14:51:42 <Zakim> Zakim has left #epub
14:51:43 <ivan> rrsagent, bye
14:51:43 <RRSAgent> I see no action items