EPUB 3 Working Group Telco — Minutes

Date: 2021-10-08

See also the Agenda and the IRC Log

Attendees

Present: Masakazu Kitahara, Matthew Chan, Toshiaki Koike, Wendy Reid, George Kerscher, Ivan Herman, gregorio, Avneesh Singh, Brady Duga, Gregorio Pellegrino, Ben Schroeter, Murata Makoto, Bill Kasdorf, Jen Goulden, Matt Garrish, Hadrien Gardeur

Regrets: Tzviya Siegman, Dave Cramer

Guests:

Chair: Wendy Reid

Scribe(s): Matthew Chan

Content:

1. Should all Structural Vocabulary Items be normative? (issue epub-specs#1763)

See github issue epub-specs#1763.

Wendy Reid: as we approach CR we have to clear out our issue list (or defer them). I prefer finding resolution.
… this one is regarding SSV. We had previously decided to do research about moving epub:type out of spec and into its own document.
… so what are publishers using? Are they using DPUB-ARIA? And also, what are RS doing with epub:type (if anything)?
… I was still working on the RS research side of things
… but mgarrish shared a survey of publishers who had reported use of DPUB-ARIA

Ivan Herman:

Ivan Herman: i did some work on this topic. Posted my results on the issue recently.
… I looked at what the DPUB-ARIA group did about collecting information, and compared it against what is today in the spec
… per W3C rules, we have to prove that each term is used at least by 2 publishers (in this case)

Ivan Herman:

Ivan Herman: this is what DPUB-ARIA group did for certain of their terms, namely those that have an equivalent as epub:type values.
… 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)
… good thing is that a lot of terms are already okay, and can be kept as normative by referring to the DPUB-ARIA report
… but some terms (or even sections) might have to be labelled as non-normative
… you can go to my comment, in which I went through the SSV, and listed terms that are not covered in DPUB-ARIA report
… 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
… some of the affected terms comprise entire sections
… when I say non-normative, an alternative approach is to label as “deprecated”
… if we did this we would still have to clarify that “deprecated” means “non-normative”
… there are a few sections towards the end of my list in the comment that are slightly different
… as far as I know ARIA does not define labels for those HTML elements that have clear semantics attached to them
… so all our SSV terms for tables, asides, etc., are not DPUB-ARIA terms
… I wonder whether we can do the same as what ARIA does. We could deprecate those completely.

Wendy Reid: very helpful, Ivan

Brady Duga: for marking something as a table it might be used in the case of CSS tables

Ivan Herman: but are there cases of publishers using that?

Brady Duga: its typically used where publisher wants to emulate the styling of a table, but for non-tabular data

Wendy Reid: for most of these we could find weird edge cases like that
… with DPUB-ARIA testing has already been done, but we don’t have that same data for epub:type
… and getting similar data for epub:type could be difficult

Ivan Herman: 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 the same terms in ARIA makes sense
… but we’d need someone who was there at the time, e.g. mgarrish, to say for sure

Brady Duga: we had discussed doing searches in our epubs for these, but we left it off at asking for a list of search terms
… but I can’t tell you which publishers use which terms (that’s private user data)
… but I might be able to 1) go to publisher to ask permission to share, or 2) share data in the aggregate

Wendy Reid: yeah, that at least 2 publishers are using a term, for example

Brady Duga: right, as long as you will take my word for it

Avneesh Singh: ARIA roles becomes significant for a11y, but epub:type became used for production processes
… from principle of backwards compatibility, I would be concerned about removing it
… but also, historically, epub:type was intended to be extensible
… so I would prefer moving the SSV into WG note

Ivan Herman: 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
… 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

George Kerscher: all this stuff about SSV came from old work about a11y, but once DPUB-ARIA got going, a lot of these things got replicated
… 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
… but it would also encourage more extensive use of DPUB-ARIA

Gregorio Pellegrino: from epub author perspective, InDesign only allows users to put epub:type, but not ARIA role semantics

Brady Duga: re. Ivan, I’m greatly constrained in what I can do with user data, regardless of what the W3C process allows

Ivan Herman: 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
… mgarrish, was it the case in your report that you looked at each epub:type, and then looked at which DPUB-ARIA role analog they could/would use?

Matt Garrish: yes, it basically confirms that those epub:type values were in use by those publishers

Ivan Herman: so for those terms that appear on your list, we could decided to make them normative, if we wanted?

Matt Garrish: yes
… the question I have is whether there is a need to make them normative

Ivan Herman: that’s a somewhat separate question. We were talking about what we could ascertain about publisher usage from that DPUB-ARIA report

Matt Garrish: if epub:type isn’t really a major focus of the spec anymore, then do we need it in the spec at all?
… it takes a lot of space in the spec for something that we’re really de-emphasizing at this point
… there are some terms that the spec depends on, but do we need the entirely SSV just to call on a couple terms?

Hadrien Gardeur: i don’t think we should have it
… we’re giving a lot of emphasis to something that isn’t widely implemented
… we have too much in the SSV, and I wouldn’t miss anything if we just had the DPUB-ARIA terms

Ivan Herman: 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
… but we also have other vocabs in the spec for which the same question (normative or not) arises

Wendy Reid: let’s take one at a time

Gregorio Pellegrino: it would be fine for me to remove SSV from spec, but epub:type is important for MO, right?

Matt Garrish: it is meant to influence that, but its not a requirement
… the navigation relies on epub:type too, but I don’t know that you need the entire SSV in the spec to enable that
… 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

Ben Schroeter: i thought that UA relied on epub:type for certain affordances like notes

Matt Garrish: yes but that was never part of the spec
… epub:type was loosely defined on purpose to encourage experimentation

Wendy Reid: 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

Avneesh Singh: is there any benefit of putting this SSV into W3C registry instead of WG note?

Ivan Herman: 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
… I feel it is probably more the latter than the former
… if that is correct, then turning it into a registry is not for us

Avneesh Singh: thank you

Bill Kasdorf: SSV is used a lot in production workflows, both by publisher and vendors
… and there’s a value for everyone to be using the same terms for the same things

Bill Kasdorf: so having it live somewhere and be referenceable is valuable

Matt Garrish: I don’t think we need to worry that people will think the SSV has disappeared or anything
… I’m for not making it into a formal registry

Bill Kasdorf: what I was saying was the terms themselves, not so much the epub:type prefix

Proposed resolution: Move the epub:type vocabulary into it’s own note (Wendy Reid)

Ben Schroeter: +1

Matt Garrish: +1

Matthew Chan: +1

Ivan Herman: +1

Brady Duga: +1

Wendy Reid: +1

Murata Makoto: +1

Bill Kasdorf: +1

Masakazu Kitahara: +1

Avneesh Singh: +1

Dan Lazin: +1

Toshiaki Koike: +1

Gregorio Pellegrino: +1

George Kerscher: +1

Resolution #1: Move the epub:type vocabulary into it’s own note

Dan Lazin: why do we want to move it into its own note? What does this accomplish?

Ivan Herman: the question was not raised this way, but rather whether the SSV is normative or not
… if yes, then we have to have a mechanism to prove that each of those terms are used by two publishers
… and because there are so many terms, it would present a problem for testing

Dan Lazin: that makes sense, thank you

2. iframes and external content (issue epub-specs#1061)

See github issue epub-specs#1061.

Wendy Reid: 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.
… that’s where we left it
… we’ve had our PING review done (but still waiting on the report) and some of the things mentioned were handling of content that lives outside the epub
… or user interaction between content that lives inside epub and that which lives outside

George Kerscher: 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
… depending on the settings that are allowed by the RS, the epub could show one or the other
… this is a place that I see significant innovation in the education space

Bill Kasdorf: +1 to George–increasingly common in educational content

Ivan Herman: I want to understand what are our reasonable options here?
… is one option to disallow reference to external content from iframe?
… or we allow, but discourage this use case?

Dan Lazin: first, I think it would be great to support it. This is more secure than arbitrary js inside the epub
… but obviously at the cost of allowing network access
… inside Google documentation we allow HTML and CSS, but not arbitrary js
… but then how do you deal with CORS? How would the maintainer of content define that an ebook is allowed to load it in an iframe

Brady 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
… but what happens when you want your epub to reference a youtube video? You can put that into your epub
… which is usually video or audio from a service you don’t control

Wendy Reid: 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

Ivan Herman: the biggest argument raised against allowing this is that ebooks no longer become readable offline
… I know that we already have a number of ways to warn RS via the package file (e.g. MathML inside)
… then RS has the option to warn the reader that “you may lose some content if you go offline”
… could we build this into epub, and thereby allow this method of delivering external content

Brady 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.

Hadrien Gardeur: this is all very confusing. Why are we talking about how something should be implemented and iframes?
… you can write what you want in the spec, but developers could still do their own thing
… there are a number of ways to handle this, you can open link in chrome or safari, for example
… and there are even different types of webviews
… given all that, it shouldn’t be part of the spec

Ivan Herman: the question is whether external iframes should be allowed or not

Wendy Reid: 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
… it could pass or fail

Hadrien Gardeur: 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.

Wendy Reid: so even if we said something about it, in the real world we’re going to see a variety of different results

Ivan Herman: what happens if epub spec forbids use of iframes in content? Is this the kind of statement you would like to see?

Hadrien Gardeur: as RS developer it would help, yes

Ivan Herman: I don’t know if the community would accept such a normative statement, but its a possible direction

George Kerscher: why are we forcing this into an iframe and only an iframe?
… 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
… we just have to say that external resources are allowed in epub, and leave it at all
… I think we’re concerned with iframes in particular because of security, but we should leave that to RS

Matt Garrish: I think its weird to get into banning HTML elements. Iframes are useful and have been used in existing content.

Brady 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.
… 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)

Bill Kasdorf: I buy the argument that we say “EPUB uses the current version of HTML” full stop. Not “except iframes.”

Hadrien Gardeur: RS can recognize templates for link and provide special handling if they want, but that’s outside of spec

Brady Duga: For next time - I agree with Hadrien, the question I have is would that iframe be legal?

Wendy Reid: sorry to all queued members, we’re out of time
… i’ve posted a link above to TPAC registration, please register if you want to setup meetings
… have a great weekend everyone (happy Canadian Thanksgiving to those who celebrate!)

3. Resolutions