EPUB 3 Working Group Telco — Minutes

Date: 2021-03-26

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, George Kerscher, Avneesh Singh, Ken Jones, Matthew Chan, Masakazu Kitahara, Toshiaki Koike, Wendy Reid, Juliette McShane, Matt Garrish, Charles LaPierre, Teenya Franklin, Dan Lazin, Brady Duga, Bill Kasdorf, Hadrien Gardeur, Gregorio Pellegrino

Regrets:

Guests: Dave Cramer

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

Dave Cramer: I believe we have a new member of the wg?

Dan Fauxsmith: I work at google. Have a diverse background. Not an epub expert yet. But I worked as designer and a technical writer. Have worked tangentially in publishing.
… interested in the cross platform compatibility of epubs

1. PR Clarifying non-linear items

See github pull request #1584.

See github issue #1480.

Dave Cramer: much of what we are talking about is in the comment to this issue
… there is some history to linear=no
… items are linear=yes when they are in reading order
… but we don’t say what to do when linear=no
… most common implementation seems to have linear=no content only appear when link is clicked
… belief that that content can be suppressed, but we wanted to clarify that that content must be reachable if explicitly clicked

Brady Duga: linear=no was put in for publishers, to better control what RSes was doing with order of their content

Dave Cramer: one of the issues was with cover images right? sometimes in the spine, sometimes in metadata?

Brady Duga: no, this was more about content at the end, e.g. footnotes
… where each footnote is in its own document, but only linked to the main book, not in reading order
… so without linear the footnotes would sometimes appear in random order at the end of the book

Dave Cramer: i think some RS will also just move all linear=no content at the end regardless

Ivan Herman: just to clarify, e.g. i have a complex illustration that i don’t want in the text, like an svg, and there is a reference to it, is this an example of linear=no?

Brady Duga: if you have a link to that from something in your spine, then yes, that would be a use for linear=no

Dave Cramer: and in some RS clicking that sort of link would open that content in a window in front of the text

Brady Duga: its essentially metadata about this piece of content that enables RS to make informed decision about how to process this piece of content in its UI

Charles LaPierre: we just had a example where extended image descriptions were marked as linear=no and but some RSes were still showing it where it appeared in the spine
… this was kind of counter intuitive

Brady Duga: if its a link then it has to show up in the spine, so RSes that want to show it know where to do so
… this kind of goes back to the ideological debate of whether ebooks should replicate limitations of print
… some RS are going to show all content, and some won’t
… linear doesn’t change that
… it just allows publishers to have some control over whether it appears at the back of the book vs some other location

Matt Garrish: from a RS “make it render consistently” point of view, I’m not sure we can solve that
… from a user perspective, that’s why we wanted to give users an option to skip linear=no content or not

Dave Cramer: there’s so much existing content that i’m not sure there is a path towards uniform behaviour of the linear attribute
… that said, i think the clarifying language of the PR is good
… just underlining that RS must still show linear=no content if the user clicks a link
… and not just suppress that content

Ivan Herman: the current text uses a lot of MAYs
… i just want to be sure that this is as far as we can go

Hadrien Gardeur: in Readium community (Thorium etc.), we decided 3 years ago that if something is marked as linear=no then you won’t encounter if you’re just moving forward through a pub, but that you will see it if accessed via a link
… this was not a hard decision
… but how do you present these resources?
… some people think that linear=no resource should behave like the rest of the content (i.e. if everything is normally paginated, then it should also be paginated)
… but it could also be scrolled etc.
… it may not be wg’s role to deal with this, but it is a problem lacking a solution
… even when we simply the scenario, by excluding desktop user case, for example, there is still disagreement about what to do with it

Ivan Herman: so, the maximum we can do at this point in terms of the PR is to say yes, but i don’t know whether we are in position to put the various alternatives of what can happen (along the lines of what Hadrien just discussed)
… but that can be a separate issue
… and maybe have it somewhere in spec as note
… as it currently stands, you are in for a surprise, not even sure what behaviour to expect

Wendy Reid: we get very similar comments about how we handle footnotes
… need clarity about what to do with content that is linked from main text, but not necessarily required for main text
… e.g. is it a pop-up, or does the link take you somewhere else, etc.

Dave Cramer: can we resolve on accepting PR?

Proposed resolution: Close PR 1584 with the new language around linear=”no”, close issue 1480 (Wendy Reid)

Brady Duga: +1

Matt Garrish: +1

Gregorio Pellegrino: +1

Masakazu Kitahara: +1

Wendy Reid: +1

Toshiaki Koike: +1

Juliette McShane: +1

Matthew Chan: +1

Bill Kasdorf: +1

Dan Lazin: +1

Hadrien Gardeur: +1

Charles LaPierre: +1

Ivan Herman: +1

Resolution #1: Close PR 1584 with the new language around linear=”no”, close issue 1480

2. Data URLs PR

See github pull request #1582.

See github issue #1564.

Matt Garrish: this is from what we discussed last week’s call
… where do we allow data URLs, etc.
… browsers are starting to disallow navigation to data URLs (to circumvent security issues)
… so last week we said we would follow that path, but still allow embedding content via data URLs
… plus we were going to say that we wouldn’t allow data URLs as spine docs
… how to phrase this was kind of complicated
… the language uses “top level browsing”
… but some RSes don’t use a browser based model
… so we say that in those cases, they still have to treat the data URLs similar to the way that a browser would

Brady Duga: its hard to get the language right so that we don’t disallow things by mistake, or allow things by mistake
… e.g. when an RS wants to provide the ability to let user pop out content embedded via data URL in a separate window
… wonder if there is another group working on specifying how this should work?
… or are we on the bleeding edge here? Would rather not be the ones who set this standard

Matt Garrish: this very much seems to be raised and discussed in the browser realm
… potentially a part of the HTML spec
… but nothing I can point to specifically

Ivan Herman: this PR does a lot that is not contentious, i think
… i propose to merge PR as it is, subject to the nitty gritty about the exact terminology
… but then open an issue saying that this terminology still has to be checked with TAG and HTML community
… and link to our language
… that way we specifically flag this for TAG input
… the new issue would be more focused
… and in the meantime we capture everything else in the PR

Matt Garrish: in that light, do we maybe want to keep the authoring side requirements, but leave out the RS expectations side?

Ivan Herman: pref trying to do something now, even with it being incomplete, raise a separate issue about the terminology, link that issue to the text and ask for external help, e.g., from the TAG.

Brady Duga: would refer this to TAG, yes

Ivan Herman: also, let’s mark issues as explicitly “referred to TAG for input”

Dave Cramer: i’m okay with merging for now, on understanding that this is not final final

Proposed resolution: Merge PR 1582, open issue for TAG review (Wendy Reid)

Ivan Herman: +1

Wendy Reid: +1

Matt Garrish: +1

Charles LaPierre: +1

Matthew Chan: +1

Brady Duga: +`

Brady Duga: +1

Bill Kasdorf: +1

Resolution #2: Merge PR 1582, open issue for TAG review

3. Extending “role” cardinality in contributor metadata

See github issue #1129, #1583.

Dave Cramer: this came up early in epub 3.2 in CG
… can you have more than one metaproperty role pointing to meta element
… schema said 0 or 1
… CG felt it would be tricky for RS to do anything else, and there wasn’t a lot of demand for change at the time
… but recently people have been using role property to reflect fact that each contributor can do multiple things for publication

Matt Garrish: part of the restriction is because we had the OPF role attribute role in epub
… and we were trying to match things up
… i’m not sure its critical anyway
… not harmful to have multiple roles
… happy to let people do what they want with metadata
… for epub2 compat, maybe an informative note that you may want to limit yourself to 1 role

Dave Cramer: more RS i’m aware of won’t display this to end user at all

Bill Kasdorf: allowing this might be good just for removing friction for publishers
… really common
… so maybe let’s allow it if it does no harm

Hadrien Gardeur: from Readium perspective, we could support it
… we could parse it, make it easy to work with, and then its up to the RS to do with that what they want
… and then about OPF, for some RSes its the only metadata they have

Dan Fauxsmith: given that we are currently saying 0 to 1, but publishers are saying they have lots of ebooks where this is already >1, should we recommend that if there is more than 1 then it should be in priority order?
… as an author, you don’t know about RS behaviour. You just want to know what is the best value to populate

Ivan Herman: +1 to dlazin

Gregorio Pellegrino: my Q is about ONIX
… in ONIX do you have to duplicate the contributor, or can the contributor have multiple roles?

Bill Kasdorf: this is really common in higher ed publishing
… highly likely that they’d need to be able to do this

Hadrien Gardeur: disagree that we should try to align with ONIX
… its not produced by the same people
… one person does OPF, and often someone else does ONIX
… repeating roles rather than repeating author is more elegant

Dave Cramer: ONIX cardinality for contributor is that each can have multiple roles
… i’m seeing strong support to relax this restriction, to allow cardinality of multiple

Ivan Herman: agree, but i think we should also make it clear that they should be in priority order

Charles LaPierre: i just created book for diagram center that had multiple contributors, and there i had to add in all these roles for each contributor. Would have loved to have been able to do this in the epub as well.

Brady Duga: for priority, i could seen some RS taking the first one, and some taking the last one

Matt Garrish: can we also agree to 1583?

Proposed resolution: Relax the restriction on cardinality for OPF metadata (Wendy Reid)

Ivan Herman: +1

Charles LaPierre: +1

Matthew Chan: +1

Brady Duga: +1

Bill Kasdorf: +1

Gregorio Pellegrino: +1

Ken Jones: +1

Wendy Reid: +1

Juliette McShane: +1

Toshiaki Koike: +1

Masakazu Kitahara: +1

Resolution #3: Relax the restriction on cardinality for OPF metadata

Wendy Reid: so we’ll leave to mgarrish to draft amending language

3.1. referral to epubcheck

George Kerscher: does this trigger a change to our schemas, and who if so, who does that?

Matt Garrish: there’s going to be a need to change epubcheck, yes

Ivan Herman: let’s let Romain, etc. know

Wendy Reid: there’s a corresponding issue in epubcheck repo

Ivan Herman: so let’s comment in their issue to let them know the resolution here?

Wendy Reid: i’ll do that yes, once we have the comment with the resolution in

Avneesh Singh: about epubcheck, this change is for epub 3.3, but epubcheck is on epub 3.2 right now
… so we’d have to request an exception to epub 3.2 compliance

Dave Cramer: can we do an errata to 3.2 or…. Ivan?

Ivan Herman: that goes a little beyond the current topic
… not sure that this should be an exception
… we’ve already made changes to media type, security related issues, that are very much on the same level
… perhaps some epubcheck issues could be tagged that they’ve already been changed in 3.3
… and then leave it up to epubcheck group to determine how they want to handle that

Avneesh Singh: e.g. in prior spec, when we changed requirement related to order of toc, we discovered that this caused issues for jp publishers
… in that case we made a special request for epubcheck to deviate from spec

Ivan Herman: i don’t think we should be prescribing to epubcheck how to prioritize their tasks

Avneesh Singh: agreed, this wg just provides recommendations

Ivan Herman: we’ve been fairly good in documenting our decision making, maybe this is enough of a basis for epubcheck to make a decision…

Matt Garrish: i’ve been flagging things as changed already when i remember to

Ivan Herman: okay, then we should be good

Dave Cramer: right, thanks everyone for coming!
… see you all next week

4. Resolutions