13:50:55 <RRSAgent> RRSAgent has joined #epub
13:50:56 <RRSAgent> logging to https://www.w3.org/2021/10/08-epub-irc
13:50:58 <Zakim> RRSAgent, make logs Public
13:50:59 <Zakim> please title this meeting ("meeting: ..."), ivan
13:51:16 <ivan> ivan has changed the topic to: Meeting Agenda 2021-10-08:https://lists.w3.org/Archives/Public/public-epub-wg/2021Oct/0001.html
13:51:17 <ivan> Chair: wendy
13:51:17 <ivan> Date: 2021-10-08
13:51:17 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021Oct/0001.html
13:51:17 <ivan> Meeting: EPUB 3 Working Group Telco
13:51:17 <ivan> Regrets+ tzviya
13:54:06 <BenSchroeter> BenSchroeter has joined #epub
13:58:42 <MattChan> MattChan has joined #epub
13:59:19 <MasakazuKitahara> MasakazuKitahara has joined #epub
13:59:28 <MasakazuKitahara> present+
13:59:35 <MattChan> present+
13:59:36 <toshiakikoike> toshiakikoike has joined #epub
13:59:48 <wendyreid> wendyreid has joined #epub
13:59:49 <George> George has joined #epub
13:59:50 <toshiakikoike> present+
13:59:55 <wendyreid> present+
14:00:19 <George> George has joined #epub
14:00:37 <George> present+
14:01:07 <ivan> present+
14:01:31 <ivan> present+ gregorio
14:01:39 <ivan> present+ avneesh
14:01:45 <ivan> present+ toshiakikoike
14:01:47 <gpellegrino> gpellegrino has joined #epub
14:01:59 <ivan> present+ duga
14:02:08 <duga> duga has joined #epub
14:02:12 <duga> present+
14:02:12 <MattChan> scribe+
14:02:16 <avneeshsingh> avneeshsingh has joined #epub
14:02:19 <ivan> regrets+ dauwhe
14:02:23 <gpellegrino> present+
14:02:28 <wendyreid> https://github.com/w3c/epub-specs/issues/1763
14:02:31 <MattChan> TOPIC: Should all Structural Vocab Items be normative?
14:02:33 <avneeshsingh> present+
14:02:52 <George> George has joined #epub
14:03:05 <ivan> present+ MasakazuKitahara
14:03:09 <MattChan> wendyreid: as we approach CR we have to clear out our issue list (or defer them). I prefer finding resolution.
14:03:21 <ivan> present+ BenSchroeter
14:03:22 <BenSchroeter> present+
14:03:28 <ivan> present+ makoto
14:03:44 <MattChan> ... this one is regarding SSV. We had previously decided to do research about moving epub:type out of spec and into its own document.
14:04:11 <MattChan> ... so what are publishers using? Are they using DPUB-ARIA? And also, what are RS doing with epub:type (if anything)?
14:04:22 <MattChan> ... i was still working on the RS research side of things
14:04:36 <ivan> present+ BillK
14:04:37 <ivan> q+
14:04:40 <wendyreid> ack ivan
14:04:41 <duga> q+
14:04:45 <MattChan> ... but mgarrish shared a survey of publishers who had reported use of DPUB-ARIA
14:04:52 <George> George has joined #epub
14:05:02 <ivan> https://github.com/w3c/epub-specs/issues/1763#issuecomment-938659529
14:05:02 <MattChan> ivan: i did some work on this topic. Posted my results on the issue recently.
14:05:22 <duga> q-
14:05:26 <MattChan> ... i looked at what the DPUB-ARIA group did about collecting information, and compared it against what is today in the spec
14:05:34 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
14:05:45 <Bill_Kasdorf> present+
14:05:51 <MattChan> ... per W3C rules, we have to prove that each term is used at least by 2 publishers (in this case)
14:05:54 <Bill_Kasdorf> q+
14:06:18 <ivan> https://w3c.github.io/test-results/dpub-aria/
14:06:19 <MattChan> ... this is what DPUB-ARIA group did for certain of their terms
14:06:52 <George> George has joined #epub
14:07:01 <MattChan> ... so I compared this list with what is in our document, to see which are the terms that may have issues under this W3C process (i.e. which terms might we have to specify as non-normative)
14:07:17 <Bill_Kasdorf> q-
14:07:18 <MattChan> ... good thing is that a lot of terms are already okay, and can be kept as normative
14:07:22 <Jen_G> Jen_G has joined #epub
14:07:32 <MattChan> ... but some terms (or even sections) might have to be labelled as non-normative
14:07:34 <Jen_G> Present+
14:07:52 <MattChan> ... you can go to my comment, in which i went through the SSV, and listed terms that are not covered in DPUB-ARIA
14:08:11 <MattChan> ... for these we have to do our own research to show that they are used by at least 2 publishers, or we have to clarify that these terms are non-normative
14:08:21 <Jen_G> Present+
14:08:32 <MattChan> ... some of the affected terms comprise entire sections
14:08:50 <MattChan> ... when i say non-normative, an alternative approach is to label as "depreciated"
14:08:52 <George> George has joined #epub
14:09:11 <MattChan> ... if we did this we would still have to clarify that "deprecated" means "non-normative"
14:09:17 <MattChan> s/depreciated/deprecated
14:09:36 <MattChan> ... there are a few sections towards the end of my list in the comment that are slightly different
14:09:57 <MattChan> ... as far as I know ARIA does not define labels for those HTML elements that have clear semantics attached to them
14:10:12 <MattChan> ... so all our SSV terms for tables, asides, etc. are not DPUB-ARIA terms
14:10:52 <George> George has joined #epub
14:10:59 <MattChan> ... i wonder whether we can do the same as what ARIA does. We could deprecate those completely.
14:11:02 <duga> q+
14:11:07 <MattChan> wendyreid: very helpful, Ivan
14:11:09 <wendyreid> ack duga
14:11:23 <George> George has joined #epub
14:11:33 <MattChan> duga: for marking something as a table it might be used in the case of CSS tables
14:12:12 <MattChan> ivan: but are there cases of publishers using that?
14:12:38 <MattChan> duga: its typically used where publisher wants to emulate the styling of a table, but for non-tabular data
14:12:52 <George> George has joined #epub
14:13:03 <MattChan> wendyreid: for most of these we could find weird edge cases like that
14:13:26 <George> George has joined #epub
14:13:26 <dlazin> dlazin has joined #epub
14:13:33 <MattChan> ... with DPUB-ARIA testing has already been done, but we don't have that same data for epub:type
14:13:33 <duga> q+
14:13:42 <MattChan> ... and getting similar data for epub:type could be difficult
14:14:56 <MattChan> ivan: if I understand well, what they did in that report is to look at use of epub:type by publishers to show that use of ARIA makes sense
14:15:04 <wendyreid> ack duga
14:15:08 <MattChan> ... but we'd need someone who was there at the time, e.g. mgarrish, to say for sure
14:15:29 <avneeshsingh> q+
14:15:36 <MattChan> duga: we had discussed doing searches in our epubs for these, but we left it off at asking for a list of search terms
14:15:45 <George> George has joined #epub
14:15:59 <MattChan> ... but I can't tell you which publishers use which terms (that's private user data)
14:16:04 <ivan> q+
14:16:17 <MattChan> ... but I might be able to 1) go to publisher to ask permission to share, or 2) share data in the aggregate
14:16:22 <George> George has joined #epub
14:16:23 <wendyreid> ack avneeshsingh
14:16:28 <mgarrish> mgarrish has joined #epub
14:16:29 <MattChan> wendyreid: yeah, that at least 2 publishers are using a term, for example
14:16:29 <ivan> q+ george
14:16:30 <wendyreid> q+ George
14:16:37 <MattChan> duga: right, as long as you will take my word for it
14:17:06 <MattChan> avneeshsingh: ARIA roles becomes significant for a11y, but epub:type became used for production processes
14:17:25 <MattChan> ... from principle of backwards compat, I would be concerned about removing it
14:17:36 <mgarrish> present+
14:17:44 <MattChan> ... but also, historically, epub:type was intended to be extensible
14:17:48 <ivan> present+ mgarrish
14:17:53 <wendyreid> ack ivan
14:17:58 <MattChan> ... so I would prefer moving the SSV into WG note
14:18:23 <gpellegrino> q+
14:18:29 <George> George has joined #epub
14:18:40 <MattChan> ivan: re duga comment, i understand some of that information is confidential, and I seem to remember that the W3C process might allow that sort of evidence to be accepted
14:18:46 <wendyreid> ack George
14:18:53 <duga> q+
14:19:03 <MattChan> ... but please do the search first, and if the result shows at least 2 publishers, then I will talk to W3C internal about using it
14:19:35 <MattChan> george: all this stuff about SSV came from old work about a11y, but once DPUB-ARIA got going, a lot of these things got replicated
14:19:52 <George> George has joined #epub
14:20:16 <MattChan> ... because SSV is outside the norm of HTML processing, I see no reason not to move it to a note, preserving the ability of publishers to use it for production if they wish
14:20:19 <wendyreid> ack gpellegrino
14:20:28 <MattChan> ... but it would also encourage more extensive use of DPUB-ARIA
14:20:52 <George> George has joined #epub
14:20:54 <MattChan> gpellegrino: from epub author perspective, InDesign only allows users to put epub:type, but not ARIA role semantics
14:20:58 <wendyreid> ack duga
14:21:40 <MattChan> duga: re. Ivan, I'm greatly constrained in what I can do with user data, regardless of what the W3C process allows
14:22:40 <MattChan> ivan: right, so in that case, I might be able to look into how we could use that research without need to show any user data
14:22:52 <George> George has joined #epub
14:23:35 <Hadrien> Hadrien has joined #epub
14:23:49 <MattChan> ... @mgarrish, is it the case that in your report, was it the case that you looked at each epub:type, and then looked at which DPUB-ARIA role analog they could/would use?
14:23:55 <Hadrien> present+
14:24:07 <MattChan> mgarrish: yes, it basically confirms that those epub:types were in use by those publishers
14:24:20 <MattChan> ivan: so for those terms that appear on your list, we could decided to make them normative, if we wanted?
14:24:23 <MattChan> mgarrish: yes
14:24:35 <MattChan> ... the question I have is whether there is a need to make them normative
14:24:52 <George> George has joined #epub
14:25:10 <MattChan> ivan: that's a somewhat separate question. We were talking about what we could ascertain about publisher usage from that DPUB-ARIA report
14:25:31 <MattChan> mgarrish: if epub:type isn't really a major focus of the spec anymore, then do we need it in the spec at all?
14:25:43 <Hadrien> q+
14:25:45 <MattChan> ... it takes a lot of space in the spec for something that we're really de-emphasizing at this point
14:26:02 <wendyreid> ack Hadrien
14:26:06 <MattChan> ... there are some terms that the spec depends on, but do we need the entirely SSV just to call on a couple terms?
14:26:12 <MattChan> Hadrien: i don't think we should have it
14:26:27 <MattChan> ... we're giving a lot of emphasis to something that isn't widely implemented
14:26:43 <ivan> q+
14:26:52 <George> George has joined #epub
14:26:59 <gpellegrino> q+
14:27:12 <MattChan> ... we have too much in the SSV, and I wouldn't miss anything if we just had the DPUB-ARIA terms
14:27:18 <wendyreid> ack ivan
14:27:33 <George> George has joined #epub
14:28:03 <MattChan> ivan: based on all that, I propose that we formally say we will move SSV into a separate note, leaving the follow up as editorial work
14:28:25 <MattChan> ... but we also have other vocabs in the spec for which the same question (normative or not) arises
14:28:35 <wendyreid> ack gpellegrino
14:28:35 <MattChan> wendyreid: let's take one at a time
14:28:52 <George> George has joined #epub
14:28:53 <MattChan> gpellegrino: it would be fine for me to remove SSV from spec, but epub:type is important for MO, right?
14:29:00 <avneeshsingh> q+
14:29:08 <avneeshsingh> q-
14:29:20 <MattChan> mgarrish: it is meant to influence that, but its not a requirement
14:29:50 <MattChan> ... the navigation relies on epub:type too, but I don't know that you need the entire SSV in the spec to enable that
14:29:50 <BenSchroeter> q+
14:29:52 <George> George has joined #epub
14:29:54 <MURATA> MURATA has joined #epub
14:29:58 <MURATA> present+
14:30:22 <wendyreid> ack BenSchroeter
14:30:32 <MattChan> ... don't know if its a procedural issue to reference terms from a note, but assuming its not an issue, this isn't a problem
14:30:48 <MattChan> BenSchroeter: i thought that UA relied on epub:type for certain affordances like notes
14:31:08 <MattChan> mgarrish: yes but that was never part of the spec
14:31:28 <MattChan> ... epub:type was loosely defined on purpose to encourage experimentation
14:31:57 <MattChan> wendyreid: RS do use epub:type to identify footnotes, but most RS also have to have 2 or 3 fallback ways of identifying footnotes because its so inconsistently used
14:32:16 <avneeshsingh> q+
14:32:24 <wendyreid> ack avneeshsingh
14:32:52 <George> George has joined #epub
14:32:58 <MattChan> avneeshsingh: is there any benefit of putting this SSV into W3C registry instead of WG note?
14:33:02 <ivan> q+
14:33:07 <wendyreid> ack ivan
14:33:27 <MattChan> ivan: i wonder whether this is a vocab that will be used in coming years, or more for archival of something that will not evolve much
14:33:32 <George> George has joined #epub
14:33:35 <MattChan> ... i feel it is probably more the latter than the former
14:33:39 <Bill_Kasdorf> q+
14:33:52 <mgarrish> q+
14:34:06 <MattChan> ... if that is correct, then turning it into a registry is not for us
14:34:07 <George> George has joined #epub
14:34:08 <wendyreid> ack Bill_Kasdorf
14:34:10 <MattChan> avneeshsingh: thank you
14:34:28 <MattChan> Bill_Kasdorf: SSV is used a lot in production workflows, both by publisher and vendors
14:34:30 <George> George has joined #epub
14:34:41 <MattChan> ... and there's a value for everyone to be using the same terms for the same things
14:35:01 <wendyreid> mgarrish:
14:35:04 <wendyreid> ack mgarrish
14:35:09 <MattChan> ... so having it live somewhere and be referenceable is valuable
14:35:34 <MattChan> mgarrish: i don't think we need to worry that people will think the SSV has disappeared or anything
14:35:50 <Bill_Kasdorf> q+
14:36:31 <wendyreid> ack Bill_Kasdorf
14:36:38 <MattChan> ... i'm for not making it into a formal registry
14:36:52 <George> George has joined #epub
14:36:59 <MattChan> Bill_Kasdorf: what i was saying was the terms themselves, not so much the epub:type prefix
14:37:25 <George> George has joined #epub
14:37:31 <wendyreid> Proposed: Move the epub-type vocabulary into it's own note
14:37:33 <BenSchroeter> +1
14:37:34 <mgarrish> +1
14:37:35 <MattChan> +1
14:37:36 <ivan> +1
14:37:37 <duga> +1
14:37:37 <wendyreid> +1
14:37:38 <MURATA> +1
14:37:39 <Bill_Kasdorf> +1
14:37:40 <MasakazuKitahara> +1
14:37:41 <avneeshsingh> +1
14:37:42 <dlazin> +1
14:37:42 <toshiakikoike> +1
14:37:44 <gpellegrino> +1
14:37:46 <George> +1
14:38:06 <MattChan> dlazin: why do we want to move it into its own note? What does this accomplish?
14:38:15 <wendyreid> RESOLVED: Move the epub-type vocabulary into it's own note
14:38:24 <MattChan> ivan: the question was not raised this way, but rather whether the SSV is normative or not
14:38:43 <MattChan> ... if yes, then we have to have a mechanism to prove that each of those terms are used by two publishers
14:38:52 <George> George has joined #epub
14:38:56 <MattChan> ... and because there are so many terms, it would present a problem for testing
14:38:59 <MattChan> dlazin: that makes sense, thank you
14:39:19 <wendyreid> https://github.com/w3c/epub-specs/issues/1061
14:39:20 <MattChan> TOPIC: iframes and external resources
14:39:25 <George> George has joined #epub
14:40:53 <MattChan> wendyreid: this issue is from epub 3.2 and we also discussed at last F2F. Last time we said that there are use cases for external content in epub, BUT its not uncommon for RS to block this content for security and privacy concerns. AND its not up to us to tell RS how to handle these security and privacy issues, which leads to usability and interop issues.
14:40:58 <MattChan> ... that's where we left it
14:41:27 <George> George has joined #epub
14:41:34 <George> q+
14:41:42 <MattChan> ... we've had our review done (but still waiting on the report) and some of the things mentioned were handling of content that lives outside the epub
14:41:55 <wendyreid> ack Geo
14:41:55 <MattChan> ... or user interaction between content that lives inside epub and that which lives outside
14:42:09 <George> George has joined #epub
14:42:27 <ivan> q+
14:42:34 <MattChan> george: it would be great if publisher could put in picture of something classically in textbook, and alternatively link out to a youtube video of same
14:42:52 <MattChan> ... depending on the settings that are allowed by the RS, the epub could show one or the other
14:42:53 <dlazin> q+
14:43:06 <MattChan> ... this is a place that I see significant innovation in the education space
14:43:07 <wendyreid> ack ivan
14:43:20 <Bill_Kasdorf> +1 to George--increasingly common in educational content
14:43:22 <MattChan> ivan: i want to understand what are our reasonable options here?
14:43:25 <mgarrish> q+
14:43:38 <MattChan> ... is one option to disallow reference to external content from iframe?
14:43:45 <MattChan> ... or we allow, but discourage this use case?
14:44:01 <wendyreid> ack dlazin
14:44:17 <MattChan> dlazin: first, i think it would be great to support it. This is more secure than arbitrary js inside the epub
14:44:26 <MattChan> ... but obviously at the cost of allowing network access
14:44:52 <George> George has joined #epub
14:45:46 <mgarrish> q-
14:45:51 <MattChan> ... inside Google documentation we allow HTML and CSS, but not arbitrary js
14:46:02 <duga> q+
14:46:31 <MattChan> ... but then how do you deal with cores? How would the maintainer of content define that an ebook is allowed to load it in an iframe
14:46:32 <wendyreid> ack duga
14:46:43 <wendyreid> s/cores/CORS/
14:46:52 <George> George has joined #epub
14:47:24 <MattChan> duga: i think this is a more specific question. We recommend container constrained scripting. In that that case the script would have to be part of the epub, which is okay, since we want the epub to be self-contained
14:47:45 <MattChan> ... but what happens when you want your epub to reference a youtube video? You can put that into your epub
14:47:59 <MattChan> ... which is usually video or audio from a service you don't control
14:48:05 <ivan> q+
14:48:23 <wendyreid> ack ivan
14:48:35 <MattChan> wendyreid: and even where you do host the content, but the ebook is sold via an external retailer, then you have the same security issue arise
14:48:51 <MattChan> ivan: the biggest argument raised against allowing this is that ebooks no longer become readable offline
14:48:52 <George> George has joined #epub
14:49:41 <MattChan> ... i know that we already have a number of ways to warn RS via the package file (e.g. MathML inside)
14:50:01 <MattChan> ... then RS has the option to warn the reader that "you may lose some content if you go offline"
14:50:09 <duga> q+
14:50:12 <wendyreid> ack duga
14:50:24 <MattChan> ... could we build this into epub, and thereby allow this method of delivering external content
14:50:44 <Hadrien> q+
14:50:52 <George> George has joined #epub
14:51:00 <MattChan> duga: the security issues around this aren't clear. We assume RS is a web browser, but it often isn't. It's usually a webview, which lacks the security model that a browser has.
14:51:08 <wendyreid> ack Hadrien
14:51:28 <MattChan> Hadrien: this is all very confusing. Why are we talking about how something should be implemented and iframes?
14:51:31 <George> George has joined #epub
14:51:44 <MattChan> ... you can write what you want in the spec, but devs could still do their own thing
14:52:01 <MattChan> ... there are a number of ways to handle this, you can open link in chrome or safari, for example
14:52:08 <George> George has joined #epub
14:52:13 <Karen> Karen has joined #epub
14:52:15 <MattChan> ... and there are even different types of webviews
14:52:24 <MattChan> ... given all that, it shouldn't be part of the spec
14:52:39 <MattChan> ivan: the question is whether external iframes should be allowed or not
14:52:42 <George> George has joined #epub
14:53:25 <MattChan> wendyreid: as ivan said, this isn't addressed in the spec. Addressing it could involve some kind of normative statement about iframes, which creates a testing problem where RS have arbitrarily determined how to handle this
14:53:37 <MattChan> ... it could pass or fail
14:53:52 <George> George has joined #epub
14:54:06 <MattChan> Hadrien: as a RS developer, iframes in the content are you enemy. Iframes in your RS are a different thing. But iframes in content are always a problem.
14:54:11 <ivan> q+
14:54:14 <George> q+
14:54:23 <wendyreid> ack ivan
14:54:33 <MattChan> wendyreid: so even if we said something about it, in the real world we're going to see a variety of different results
14:54:52 <George> George has joined #epub
14:54:57 <MattChan> ivan: what happens if epub spec forbids use of iframes in content, bar none. Is this the kind of statement you would like to see?
14:55:11 <MattChan> Hadrien: as RS dev it would help, yes
14:55:21 <mgarrish> q+
14:55:35 <wendyreid> ack George
14:55:37 <MattChan> ivan: i don't know if the community would accept such a normative statement, but its a possible direction
14:55:47 <MattChan> george: why are we forcing this into an iframe and only an iframe?
14:56:19 <MattChan> ... i think its a case of the external resource, and if the RS wants to launch the default browser, then yes it takes you out of the RS, but you can navigate back to the RS and you're left off where you were
14:56:34 <MattChan> ... we just have to say that external resources are allowed in epub, and leave it at all
14:56:37 <wendyreid> ack mgarrish
14:56:53 <MattChan> ... i think we're concerned with iframes in particular because of security, but we should leave that to RS
14:56:56 <duga> q+
14:57:25 <wendyreid> ack duga
14:57:38 <MattChan> mgarrish: i think its weird to get into banning HTML elements. Iframes are useful and have been used in existing content.
14:57:52 <George> George has joined #epub
14:58:26 <MattChan> duga: we do allow external audio and video, and typically you'll get a play button in your book. The reason iframe is interesting is that its not necessarily a video resource. Its an entire page inside the book that could contain its own scripting, etc.
14:58:35 <Bill_Kasdorf> I buy the argument that we say "EPUB uses the current version of HTML" full stop. Not "except iframes."
14:58:45 <Hadrien> q+
14:59:13 <wendyreid> ack Hadrien
14:59:22 <MattChan> ... the issue is what if you want to play youtube video in my book, because a youtube video is not a video (not the same thing as having a link in your book to the youtube video)
14:59:33 <dlazin> q+
14:59:59 <duga> q+
15:00:13 <MattChan> Hadrien: RS can recognize templates for link and provide special handling if they want, but that's outside of spec
15:00:20 <MattChan> wendyreid: sorry to all queued members, we're out of time
15:00:40 <MattChan> ... i've posted a link above to TPAC registration, please register if you want to setup meetings
15:00:41 <duga> For next time - I agree with Hadrien, the question I have is would that iframe be legal?
15:01:03 <MattChan> ... have a great weekend everyone (happy Canadian Thanksgiving to those who celebrate!)
15:03:42 <ivan> rrsagent, draft minutes
15:03:42 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/08-epub-minutes.html ivan
16:47:56 <Karen> Karen has joined #epub
17:28:24 <Zakim> Zakim has left #epub
21:19:17 <Karen> Karen has joined #epub
22:41:06 <Karen> Karen has joined #epub