EPUB 3 Working Group Telco — Minutes

Date: 2021-05-13

See also the Agenda and the IRC Log

Attendees

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

Regrets:

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

Dave Cramer: welcome Fred!

Fred Chasen: i’m AC rep for Scribd (online subscription service for epubs, PDFs)
… good to be back

1. Update on TFs

Wendy Reid: this week both TFs met
… FXL TF solved issue with markdown not working in respec doc
… FXL TF will also start meeting biweekly instead of weekly
… Locators TF continue to go through use-cases
… considering potentially coming back around to page numbers

Dave Cramer: any questions above TFs?

2. Remove CSS Speech Support

See github issue #1298.

Dave Cramer: a while ago the CSS Speech module was unimplemented, but apparently it has come back, and is in CR now
… though still not aware of too many implementations, at least in epub world
… given CR status, not comfortable taking it out at this point

Brady Duga: there hasn’t been much harm to it being there yet, so it seems fine to leave it

Matt Garrish: as its unimplemented, nobody has done anything with it
… but if we’re not touching PLS or SSML then we can probably leave it too

Wendy Reid: do we know why CSS put this back on rec track?
… wonder if it is reviving due to resurgence of voice tech

Dave Cramer: did some quick searching this AM, and there seem to be a few voice over things that will read a few of these properties

Matt Garrish: it’s also been stripped down a little

Dave Cramer: okay, so we close the issue

Proposed resolution: Close issue 1298 (Wendy Reid)

Ben Schroeter: +1

Shinya Takami (高見真也): +1

Matthew Chan: +1

Toshiaki Koike: +1

Wendy Reid: +1

Dave Cramer: +1

Matt Garrish: +1

Masakazu Kitahara: +1

Brady Duga: +1

Fred Chasen: +1

Resolution #1: Close issue 1298

3. Alt-text for cover images

See github issue #1300.

Dave Cramer: this was discussed in a11y call this morning

Matt Garrish: we didn’t end with a proposal
… we’re looking for feedback from RS people about which of the possible solutions could realistically be implemented

Brady Duga: not sure how we get covers

Wendy Reid: probably sent separately

4. Are fragment identifiers allowed in manifest?

See github issue #1303.

Dave Cramer: i made an epub that had fragment identifier in href
… epubcheck threw an error
… but not sure which section of the spec this requirement came from
… so something to think about, especially as we’re rewriting the spec to refer to WHATWG URL spec

Ben Schroeter: would we need to do some epubcheck work if we were to decide to allow these fragment identifiers?

Dave Cramer: yes, but that shouldn’t be an obstacle, not big code change

Ben Schroeter: any downside? could it be abused?

Matt Garrish: just curious what the expectation is for RS if it is a fragment? What is RS supposed to do?
… load then scroll to fragment?
… and what about only having each resource listed once?

Dave Cramer: i think this is the same as activating a link in toc, i.e., yes to scroll
… but not suppress any of the document before the fragment

Brady Duga: how would that work in the spine? So chapter 1 is beginning of chapter, but chapter 2 is link to middle of the book?

Dave Cramer: yes, but we could have a note to say not to do that

Ben Schroeter: is there a legitimate reason to do this?
… or is this just to fix the epubcheck thing?

Matt Garrish: suspect this has something to do with the requirement to point to a resource, not a fragment of that resource

Brady Duga: maybe if you want to skip some kind of chapter heading for each chapter, so that you start with the first paragraph of the chapter?

Wendy Reid: we’ve had some cases where the entire book is in a single HTML file
… so this would allow you to actually navigate to the inside chapters?

Ben Schroeter: what about the fact that fragments need to be allowed for refines and stuff like that?

Matt Garrish: that’s not in the manifest

Dave Cramer: a valid reason for changing the spec is to make it match reality, and given that we already enforce this, allowing a fragment here would vastly complicate the responsibilities of an RS
… i think we just say hrefs in items shouldn’t have fragments

Matt Garrish: and the URL spec has a type that specifically can’t have fragments
… so easy to do in spec

Wendy Reid: is that the current test in the PR that you have out?

Matt Garrish: yeah (I didn’t know we had an issue out for this at the time)

Proposed resolution: Merge PR 1670, close issue 1303 (Wendy Reid)

Shinya Takami (高見真也): +1

Toshiaki Koike: +1

Masakazu Kitahara: +1

Proposed resolution: Merge PR 1670, close issue 1303, forbidding fragment identifiers in hrefs for items (Wendy Reid)

Dave Cramer: +1

Matt Garrish: +1

Ben Schroeter: +1

Brady Duga: +1

Matthew Chan: +1

Wendy Reid: +1

Fred Chasen: +1

Shinya Takami (高見真也): +1

Resolution #2: Merge PR 1670, close issue 1303, forbidding fragment identifiers in hrefs for items

5. Detailed definition of Content Display Area

See github issue #1306.

Dave Cramer: supposed to be the area in the display for epub content documents, excluding borders, margins, etc. injected by RS
… touches upon what part of screen real-estate should be controlled by author vs RS
… is just purely a FXL issue?

Fred Chasen: one place where this comes up is the little page dog-ear icon that clashes with book

Matt Garrish: we haven’t spec’ed what a viewport is, then we tried to describe a part within the viewport where content is displayed
… hard for us to be very specific about this

Dave Cramer: then is it possible to be more specific? Esp. given that RS might mess with putting more margin on body so that content doesn’t clash with bevel
… is there anything to be gained by being more precise?

Brady Duga: +1

Wendy Reid: are we talking about reflow, or FXL? Because the problems around headers, footers, etc. are mainly a problem for reflow where authors might have their own ideas about these regions
… for FXL the only question is whether it fits within the screen

Brady Duga: Content Display Area is only used within FXL (except for definitions)
… the idea was that RS should not mess with visuals in cases of FXL
… but Content Display Area technically applies to everything, because its just in the definitions

Dave Cramer: so is restricting the definition a solution?

Brady Duga: we could
… also, looking at the definitions, its not clear what the difference between viewport and Content Display Area is supposed to be

Ben Schroeter: I think there should be general guidance that RS should not obscure publisher content
… for the question at hand, I think the definition we have is suitable
… not sure how much more precise we can be

Dave Cramer: one more factor is that we’ve quite often had request for “full bleed” even in reflow
… e.g. where authors want something like an image to take up the entire screen
… e.g. in chapter opening photos in recipe books

Matt Garrish: should we try to move it over to RS spec, and try to explain the concept of Content Display Area?
… seems to apply only to RS rendering of FXL content

Shinya Takami (高見真也): +1 to mgarrish

Dave Cramer: this could really use a diagram to help explain
… i’ll look into that

Ben Schroeter: maybe we just need to reframe the question to how should RS accommodate the desire for full bleed content?

Brady Duga: there are plenty of FXL implementations that enable full bleed

Dave Cramer: and some user gestures make an overlay appear over the content

6. SVG Validation

See github issue #1323.

Dave Cramer: one of the complicating factors is undated references to specs, and now we have SVG1 and SVG2

Brady Duga: would prefer if we didn’t validate SVG
… this came up because there was an SVG 1.1 with a rel=no refer, and this failed epubcheck
… i’ve found a couple other SVG validation errors that came up because of things that weren’t valid in 1.1
… and even if we do validate, we can only say that it was valid to an SVG Schema at the time of validation

Matt Garrish: compounding the problem is that validator.nu has partially gone with SVG2, with no plans to fully move to SVG2

Brady Duga: i understand need for validity of XHTML, as XHTML is often edited by hand
… not true for SVG, which are often made by tools
… so you’re putting authors at the mercy of their tools, if those tools are generating invalid SVG
… and note that at this point spec doesn’t require validation

Dave Cramer: is there a requirement for well-formedness of XML?

Ben Schroeter: what about the XML entities in the DTDs of the SVG?

Dave Cramer: we’re not touching anything about rendering or processing, just saying that spec does not require validity, therefore epubcheck does not need to check validity

Brady Duga: if we don’t have requirement for validity, then Ivan’s issue goes away

Matt Garrish: i we’ve always had requirement that things conform to XHTML syntax
… but what about when SVGs are embedded in the content?

Dave Cramer: maybe our current action item is to talk to Romain about how this would affect epubcheck
… would also like to hear what Ivan says about this

7. Handling of invalid properties

See github issue #1673.

Matt Garrish: when I was making the URL spec change this came up
… when property values expand, they are supposed to expand into valid URL string
… assuming that if it is invalid, then RS should ignore property

Brady Duga: there are also situations where RS is suppose to ignore in failure case

Dave Cramer: right, this causes as little disruption to reading experience as possible
… e.g. not doing something to alert the reader

Proposed resolution: If a property is invalid, ignore it, close issue 1673 (Wendy Reid)

Ben Schroeter: +1

Shinya Takami (高見真也): +1

Brady Duga: +1

Matt Garrish: +1

Dave Cramer: +1

Matthew Chan: +1

Fred Chasen: +1

Toshiaki Koike: +1

Wendy Reid: +1

Resolution #3: If a property is invalid, ignore it, close issue 1673

8. AOB?

Wendy Reid: I sent invites for F2F earlier today
… will circulate agenda when we have one drafted
… let us know if you want to add anything specific to agenda

Dave Cramer: will try to tackle some of the bigger issues, e.g. HTML serialization
… okay, thanks everyone! Talk to you soon!

Dave Cramer: RRSAgent: bye

9. Resolutions