EPUB 3 Working Group Telco — Minutes

Date: 2021-12-09

See also the Agenda and the IRC Log

Attendees

Present: Masakazu Kitahara, Wendy Reid, Toshiaki Koike, Brady Duga, Shinya Takami (高見真也), Matthew Chan, Dave Cramer, John Roque, Murata Makoto, Theresa O’Connor, Victor Lopes, Victoria Lee

Regrets: Ben Schroeter, George Kerscher, John Foliot, Rick Johnson

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

1. Invalid file name characters (issue epub-specs#1921)

See github issue epub-specs#1921.

Dave Cramer: there has been some back and forth with the i18n folks about our restrictions on file naming.
… mgarrish suggested that we change MUST NOT on list of forbidden chars in file names to SHOULD NOT.

Murata Makoto: +1, but why did Matt propose this?

Dave Cramer: i don’t agree, a lot of chars are on that list for a good reason, e.g. to allow for moving epubs across OS.
… file called “?.html” could not be linked to, for example, because of interaction with URL parser.
… also, not aware of any authors asking to use these characters in epub content.
… also note that we are not restricting any language in these forbidden chars.

Brady Duga: did i18n specify which countries would be impacted by not allowing these chars?.

Dave Cramer: i think this came from mgarrish wondering whether we should just make the whole list a should rather than selectively taking things out of the forbidden list.
… e.g. emoji combining chars.

Brady Duga: agree that there is not a reason to add these, plus, these restrictions are applicable to file names - opaque to the reader.

Proposed resolution: Close issue 1921 with no change. (Wendy Reid)

Murata Makoto: +1.

Toshiaki Koike: +1.

John Roque: +1.

Shinya Takami (高見真也): +1.

Wendy Reid: +1.

Dave Cramer: +1.

Brady Duga: +1.

Matthew Chan: +1.

John Roque: +1.

Shinya Takami (高見真也): +1.

Murata Makoto: +1, again.

Masakazu Kitahara: +1.

Resolution #1: Close issue 1921 with no change.

2. Is page-spread-center a synthetic spread or not? (issue epub-specs#1929)

See github issue epub-specs#1929.

See github pull request epub-specs#1950.

Wendy Reid: i just got through writing the tests for all the FXL rendition properties, which lead to a question about page-spread-center.
… this is a spine property that is not meant to override spread behaviour, but that the page should be centered in the viewport.
… but this doesn’t seem to be what is happening in practice.
… rather, the observed behaviour seems to be identical to spread none.
… we’ve discussed in the issue, and mgarrish came up with the idea of making page-spread-center an alias of spread none.
… and not to deprecate page-spread-center.

Brady Duga: not sure why page-spread-center is confusing. Imagine you are doing a synthetic spread, but you want one specific page centered in the middle of the screen. That’s how you would tell the RS to do that..
… spread none sounds like you’ve turned off spreads completely.

Wendy Reid: an additional level of oddness was finding out that you can put page spread properties on spine level items as well.

Brady Duga: spread none and spread center mean different things, because spread none doesn’t tell you where to put the page.
… and yes, it is confusing that you can put this on a spine item (you can also alternate portrait and landscape on spine level items as another weird way of interacting with spreads).

Dave Cramer: is there a concern that this could affect the relative size of pages as you go from spread, to non-spread, and back to spread?.

Brady Duga: i can’t see people really doing this.
… one potential use case is if one of your content documents is already a spread, so you want to disable synthetic spreads for that one only.

Shinya Takami (高見真也): in Japan we use spread-center for the cover pages in many many cases, so making spread-center a depreciated feature would not be acceptable.
… aliasing it to spread none is okay.

Wendy Reid: right, so we won’t deprecate page-spread-center.
… this might be the sort of thing we need to test out.
… when the page appears in the center of the viewport, i think there is a change in the page size.

Dave Cramer: i’m not comfortable deciding this until we have more info on whether we need to better define how a RS should position the viewport when you use page-spread-center or spread none as an override of a synthetic spread epub.

Wendy Reid: agree that the FXL properties section could use some visual aides.
… we can put this off for tonight.

Brady Duga: if we end up keeping page spread then we need to fix this definition.

Wendy Reid: yeah, definitions in that section are not very good.

Dave Cramer: it was a long time ago that we wrote those, we were balancing against implementations that already existed at the time (amazon, apple).

3. Normatizing the fixed layout property statements (issue epub-specs#1936)

See github issue epub-specs#1936.

Wendy Reid: i noticed that in RS spec we say in rendition:layout that the default value is a MUST.
… but for the other 2 FXL properties even though we also define default behaviour, we don’t make those statements normative.

Dave Cramer: there are a couple instances where we say that the default value MUST be assumed, but i didn’t know how that would be testable.

Wendy Reid: the default behaviour is auto, and that means to respect what the RS is doing.
… so the test would pass if the epub appears in way that would respect the app settings or the user settings.
… which is essentially what auto is meant to do.

Brady Duga: you could not specify in one case and specify in another case, and if the result is the same then the RS passes?.

Wendy Reid: my proposal was to turn the 2x non-normative default behaviour statements into normative MUSTs.
… i’ve already made the tests for both of them.

Dave Cramer: so we just ask mgarrish to made the change, then.

Proposed resolution: Elevate the default behaviour statements for rendition:orientation and rendition:spread to MUSTs. (Wendy Reid)

Brady Duga: +1.

Shinya Takami (高見真也): +1.

Wendy Reid: +1.

John Roque: +1.

Matthew Chan: +1.

Toshiaki Koike: +1.

Theresa O’Connor: +1.

Murata Makoto: +1.

Dave Cramer: +1.

Masakazu Kitahara: +1.

Resolution #2: Elevate the default behaviour statements for rendition:orientation and rendition:spread to MUSTs.

4. Should the RS spec include something about layout overrides? (issue epub-specs#1941)

See github issue epub-specs#1941.

See github pull request epub-specs#1947.

Wendy Reid: we have a statement in content spec that it is possible to override the global layout value, but nothing is said about it in the RS requirements.
… and some of the associated behaviours are SHOULD in the RS spec.

Wendy Reid: See Statement in the content document.

Wendy Reid: these overrides theoretically make mixed modality content (fixed + reflow) possible, but its underspecified.

Dave Cramer: i’m aware of some uses, e.g. in educational content, there might be reflow text on one side, and fixed layout reference material on the other side.

Brady Duga: i’d hate to lose this feature to a lack of implementations. We don’t support it, but I think we should.

Wendy Reid: mgarrish has made a PR where he he proposes language.

Shinya Takami (高見真也): in Japan we do use partially fixed layout.

Dave Cramer: does that give us enough implementations to get this feature through?.

Wendy Reid: we might also have a partial implementation of this - specifically for covers for reflow books.

Dave Cramer: we do seem to have consensus that its necessary to have an RS conformance statement for these overrides.
… the fact that its missing might just be an artefact from when we split out RS requirements from core.

Proposed resolution: Merge PR 1947 and close issue 1941. (Wendy Reid)

Brady Duga: +1.

Shinya Takami (高見真也): +1.

Wendy Reid: +1.

Matthew Chan: +1.

Murata Makoto: +1.

Toshiaki Koike: +1.

Dave Cramer: +1.

Masakazu Kitahara: +1.

Resolution #3: Merge PR 1947 and close issue 1941.

5. Bikeshedding – what to call features without enough implementation?

See github issue epub-specs#1944.

Wendy Reid: continuing our discussion from last week - what do we call the features that don’t get enough implementation?.
… we’ve used deprecated in the past (not what HTML spec goes by), and we’ve also used legacy.

Dave Cramer: legacy features are holdovers from EPUB2 that are still useful, e.g. for making EPUB3 backwards compatible with EPUB2 RS.
… this is a different situation.
… this is a collision between W3C process whereby we need demonstrable implementation of features (i.e. tests), but we also have a charter where we can’t invalidate existing content.
… so what if there’s something in the spec where we don’t have 2 passing tests now, but the implementations could exist in the future.

Theresa O’Connor: i don’t know the details of the charter restriction. If epubcheck would have said “this is fine” before, then it needs to keep saying that? Even if no one had implemented the feature?.

Dave Cramer: yes, that’s basically my understanding, since we live in an ecosystem where even a warning from epubcheck will block content from reaching users.
… and we can’t rely on people updating content.

Theresa O’Connor: in HTML we might call a feature obsolete, and then obsolete features can itself be conforming or non-conforming.
… i think it would be fine to call your features obsolete, but the spec needs to have specific text directed to conformance checkers asking them not to throw warnings.
… like obsolete but conforming.
… in the W3C process when you reach CR you have to list features at risk, and typically those are the ones where you don’t have enough implementations, but where you hope to get those implementations during CR.
… so, actually, yeah… if you don’t want to maybe end up dropping those features at the end of CR, then i’d go back to my first suggestion.

Dave Cramer: epubcheck already has an informative level of alert below warning.
… we could say to use this level.

Theresa O’Connor: typically things in W3C are less tied to a specific conformance checker, but clearly epubcheck is the reality for epubs.
… you want to make your spec a little more general, but you can have a specific statement about epubcheck.

Dave Cramer: we also don’t want to send false messages about what is and is not well supported.

Theresa O’Connor: one of the ways that HTML handles that for obsolete features, is that in the main text of the spec it doesn’t even mention them.
… they’re defined in a separate obsolete features section at the end.
… if a feature like that is presented right in the main text and not visually distinct, then people will of course believe that those features are just as sound.
… so maybe consolidate them and make them visually distinct.

Brady Duga: i liked at risk, but ivan didn’t like it because at risk had a specific meaning in W3C process.
… deprecated doesn’t seem to fit. Maybe something scarier like imperilled..
… and we should make sure that conformance checkers can fail epubs that contain these at the user’s option.
… even if it isn’t the checker’s default behaviour.

Theresa O’Connor: imperiled is a bit obscure for non-native speakers.
… obsolete and deprecated are more recognizable in the world of spec writing.
… but I see duga’s point that at risk scares people off more effectively than either of the other terms.

Brady Duga: also these features might actually become used some day, where as deprecated feels almost like the opposite.

Theresa O’Connor: right, if you get more implementations they could just become regular features.
… reminds me of speculative features for browsers, where you have one good implementation, but then it just gets stuck in feature limbo for a while.
… might be worth reaching out to YCG chairs to ask what they’re doing.

Brady Duga: we could do something like “experimental” (but it would be weird to have manifest fallbacks become experimental).

Wendy Reid: i like experimental, but I also like the idea of reaching out to YCG chairs to ask for advice.

Dave Cramer: also incubating, unproven, or unstable - but i’m not wild about these.

Theresa O’Connor: aside from the question of naming, it sounds like everyone is on the same page about how to describe these types of features, and what the behavior of conformance checkers should be, so it seems like you’re in a pretty good place.

Dave Cramer: i think we a lot more good info on our goals, and how HTML has handled this.
… we’ll ask around for advice about naming.

Brady Duga: maybe we could go for a Japanese name?.

Murata Makoto: no specific ideas right now.

6. AOB

Dave Cramer: just a reminder that this was the last meeting of 2021, we will resume in 2022.
… thank you all, see you next year!

6. Resolutions