EPUB 3 Working Group Telco — Minutes

Date: 2021-03-04

See also the Agenda and the IRC Log

Attendees

Present: Masakazu Kitahara, Toshiaki Koike, Wendy Reid, Matthew Chan, Brady Duga, Marisa DeMeglio, Matt Garrish, Shinya Takami (高見真也), Dave Cramer

Regrets: Ben Schroeter

Guests:

Chair: Wendy Reid

Scribe(s): Matthew Chan

Content:

Wendy Reid: this week we are going through outstanding issues
… a lot of them are carryover issues from prior versions of spec

1. Media type parameter for EPUB

See github issue #1026.

Wendy Reid: epub type parameter would add hint to epub mime type about the specific epub
… e.g. is it FXL? Does it have a special DRM?
… these hints can be interpreted by RS for specific functionality
… there was a concern about backwards compatibility, but it was determined that that wasn’t really an issue
… however, a lot of this same info can be found in package metadata

Brady Duga: clarify that this is changing IANA registration, not the mimetype file

Wendy Reid: benjamin posted that there is an existing registry of IANA properties

Matthew Chan: dauwhe joining by call-in

Dave Cramer: without interest from multiple implementers I’m not sure that we should invest in this issue speculatively

Proposed resolution: Close issue #1026, will not implement (Wendy Reid)

Matt Garrish: +1

Brady Duga: +1

Masakazu Kitahara: +1

Marisa DeMeglio: +1

Wendy Reid: +1

Toshiaki Koike: +1

Matthew Chan: +1

Resolution #1: Close issue #1026, will not implement

2. Allow multiple instances of dcterms:modified

See github issue #841.

Wendy Reid: I believe the initial intent was to allow this to show progression of update to book

Matt Garrish: yeah, a revision history
… at the time we cared because of Release Identifier
… but now it doesn’t seem to matter as much
… but if we have multiple, we should define which one is the last modified

Brady Duga: I also don’t really care, but what does this enable?
… you can’t add comments to these fields, so it would just be a bunch of ambiguous dates and times
… not against removing restriction on only having one, but also not really any features that would benefit from doing so

Wendy Reid: in practice, one thing that I’ve seen publishers do is track the version of the epub on the copyright page

Dave Cramer: all the big trade publishers do that
… ours is a long string that is unintelligible to outsiders
… and we’d keep doing this regardless of changes to this field

Proposed resolution: Close issue 841, will not change usage of dcterms:modified (Wendy Reid)

Brady Duga: +1

Matthew Chan: +1

Masakazu Kitahara: +1

Matt Garrish: 0

Wendy Reid: +1

Toshiaki Koike: +1

Marisa DeMeglio: 0

Wendy Reid: mgarrish please feel free to refine the language

Resolution #2: Close issue 841, will not change usage of dcterms:modified

3. Complex page layouts

See github issue #588.

Wendy Reid: basically asking why nothing exists between reflow and completely fixed layouts
… e.g. something like fixed, but which could respond to things like media queries
… now we have things like grid and flexbox

Matt Garrish: we could really get sucked into something big like this
… it really needs to be fleshed out
… and could have a seriously negative impact on readability of some epubs

Brady Duga: this also comes from a time when people were trying to do a lot with magazines in epub format
… not so much of a priority these days
… may be another feature with lack of implementation support

Dave Cramer: i think its hard to do things without proposed implementations (i.e. how it would work in detail, what it would enable)
… probably not for our current spec

Wendy Reid: I see the use case, but agree with mgarrish that there could be a big negative impact on a11y if done badly
… more experimentation is needed first

Dave Cramer: ultimately something other than fxl could help a11y, but we don’t know what that is

Wendy Reid: has anyone done any interesting experiments in this area in JP?

Shinya Takami (高見真也): in japan, it is not easy to make fxls
… fxl content and magazines are mostly made using images

Proposed resolution: Close issue 588 (Wendy Reid)

Brady Duga: +1

Matt Garrish: +1

Wendy Reid: +1

Matthew Chan: +1

Toshiaki Koike: +1

Shinya Takami (高見真也): +1

Marisa DeMeglio: +1

Masakazu Kitahara: +1

Resolution #3: Close issue 588

4. [Media Overlays] Add media:paused-class

See github issue #428.

Brady Duga: this was a way to style content when MO playback is paused

Marisa DeMeglio: so, you’d be playing MO and an element would be highlighted, and then you would pause, and the style of that element would change to whatever is defined by media:paused

Wendy Reid: e.g. the highlight could change to an underline

Brady Duga: so right now, when you pause, what happens when you pause?

Marisa DeMeglio: we don’t say what should happen

Brady Duga: so this would make behaviour clearer

Wendy Reid: this is something that RSes might already have found a behaviour for…

Marisa DeMeglio: I think different RSes do their own thing
… from an implementation point of view, if you don’t address this, then the styling will just stay even when the MO playback is paused
… could this open up a can of worms?

Wendy Reid: most RSes that implement MO also implement a standard style
… that overwrites what the content says

Brady Duga: we don’t do that, we just go with whatever style the content says to apply for MO playback

Marisa DeMeglio: i’m trying to think of what impact this has on synched media where we do highlighting in a pretty different way

Wendy Reid: could we just defer this to synched media?

Marisa DeMeglio: synced media already has a pretty long list of deferred things

Brady Duga: one thing to consider is that if we do add this, existing content would be absolutely okay
… and then if new content begins to use this feature, it’s fairly easy to implement

Marisa DeMeglio: a player can also do this without it formally being in spec, but its just that author wouldn’t be able to pick the style

Dave Cramer: who filed the original issue?

Matthew Chan: all now referring to posts in the issue

Dave Cramer: i think we should ask around to see if people are actually interested in using this feature

Proposed resolution: Explore implementation of a media:paused class in EPUB 3.3 (Wendy Reid)

Brady Duga: +1

Matthew Chan: +1

Matt Garrish: +1

Toshiaki Koike: +1

Wendy Reid: +1

Masakazu Kitahara: +1

Resolution #4: Explore implementation of a media:paused class in EPUB 3.3

5. Handling of dc:title

See github issue #1527, #1553.

Wendy Reid: these next two are related
… there was some confusion about the example provided for <dc:title>
… specifically when there are multiple, but they have different xml:lang-s
… the discussion raised the question of whether refines needs a translation value
… because the different titles might not be translations of one another

Dave Cramer: is there any RS that does anything with the title beyond the bare minimum?

Wendy Reid: probably no

Dave Cramer: i’ve been writing tests and most RS seem to just display the first of each when there are fields that can occur multiple times
… authors are asking for more expressive power, but no RS seems to be presenting this additional data to the user

Matt Garrish: we tried what Laurent brought up in the issue
… up to epub 3.1 you had to define your title type
… and nobody used it, so we took it out
… we’d be going back in circles. I think maybe we should just move on.
… about the refines translation, we haven’t found a case for it
… people aren’t making one epub with metadata in all these different various languages

Brady Duga: agreed to all of that
… unclear what an RS should even do when presented with the title in multiple different languages

Wendy Reid: especially if the book itself is only in one language
… one of the concerns we had was about JP, because Japanese has 3 different script sets, for lack of a better way of explaining it
… so could an RS potentially implement a feature where the user could swap between script sets?

Dave Cramer: ultimately the purpose of title is so you can distinguish books within your own collection
… not meant to be as rigorous as a metadata record at some high level aggregator level (e.g. library of congress)
… maybe change not needed

Brady Duga: should we clarify the example then?

Matt Garrish: we can’t get rid of multipart dc:titles at this point
… so do we guide people towards putting everything in a single title?

Dave Cramer: I think our examples should reflect what will work for most people
… so maybe we need to dial back the example

Matt Garrish: or say that you can do multipart titles, but that there is no guarantee that RS can use them, or guarantee as to consistency

Brady Duga: say “you can put multipart titles, but nobody knows what will happen, so you should probably only put one”

Proposed resolution: Close issues 1527 and 1553, add editorial note regarding the current use of dc:title in the market (Wendy Reid)

Wendy Reid: this should probably be an editorial note

Proposed resolution: Close issues 1527 and 1553, add editorial note regarding the current use of dc:title on the market and edit the example (Wendy Reid)

Brady Duga: +1

Matthew Chan: +1

Matt Garrish: +!

Wendy Reid: +1

Toshiaki Koike: +1

Matt Garrish: +1

Masakazu Kitahara: +1

Resolution #5: Close issues 1527 and 1553, add editorial note regarding the current use of dc:title on the market and edit the example

6. Reporting accessibility conformance

See github issue #1455.

Wendy Reid: there was a comment about whether the resolved solution raises i18n issues

Matt Garrish: we’ll wait to see what the i18n folks say about it

Wendy Reid: ivan mentioned that not all languages use spaces, so our patterned string, which does, might be problematic

Matt Garrish: hopefully people are just copying and pasting this, instead of trying to type it in

Wendy Reid: if people are using production tools, this is just going to be inserted programmatically
… but we need answers from i18n before we can resolve this question

7. AOB?

Wendy Reid: have a lovely evening/friday. We’ll see you all next week!

8. Resolutions