EPUB 3 Working Group Telco — Minutes

Date: 2021-12-03

See also the Agenda and the IRC Log

Attendees

Present: Masakazu Kitahara, Ivan Herman, Dave Cramer, Avneesh Singh, George Kerscher, Ben Schroeter, Wendy Reid, Toshiaki Koike, Matthew Chan, Aimee Ubbink, Jen Goulden, Matt Garrish, Brady Duga, Charles LaPierre, Bill Kasdorf, Dan Lazin

Regrets: Tzviya Siegman, Rick Johnson, Romain Deltour

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

1. Custom elements and remote resources (issue epub-specs#1913)

See github issue epub-specs#1913.

Dave Cramer: first few issues are about remote resources.

See github pull request epub-specs#1949.

See github pull request epub-specs#1943.

Dave Cramer: all of our previous conclusions are complicated by custom elements in HTML.
… mgarrish tries to phrase our existing requirements in a way that fits with custom elements.
… but this makes things impossible for epubcheck, which won’t know what is actually there until scripts have run.

Matt Garrish: right, there are 2 PRs, this one tries to find language that still works with our past intent, the other PR more specifically address the existence of custom elements.
… there is really little we can do to check for this, people will try to work around it. It will ultimately be down to RS to decide whether to even support custom elements.

Dave Cramer: i made a test book for this, it worked in Apple and ADE, Kindle previewer failed because it doesn’t support js, didn’t work in Thorium.

Ivan Herman: what you tested tells me that custom elements are here, it would be foolish of us to try to restrict them. They are part of the element that we have to deal with.
… I’m in favor of the first PR, which removes restrictions. The second PR which tries to keep restrictions is harder to check anyway.

Ivan Herman: +1 to matt.

Matt Garrish: the simpler solution might be just to say that RS should not render remote resources in iframes.

Dave Cramer: worried that people would then work around that by using a custom element to effectively make an iframe.

Matt Garrish: there’s more awareness of how to handle that at the RS level than at checking, because you have the DOM.

Brady Duga: when it comes to scripting, it kind of the wild west. It’ll be impossible to test whether scripts are being used to do something malicious.
… there’s utility to having everything be in the package (interop, archival), and if people don’t care about that then there’s little we can do.
… our main concern in making these exceptions for resources are for size.
… should the restriction be based on size then.

Ivan Herman: to be clear, custom elements mostly means scripting. As soon as RS allows scripting, any restriction on custom elements is meaningless. The real restriction is on scripting.
… the first PR simplifies that.

Dave Cramer: there are 2 types of custom elements. First inherents from existing HTML element (i.e. “is” attribute). This type doesn’t work in webkit, and will probably be limited in epub world..
… this is a can of worms that we can’t really do much about.

Proposed resolution: Merge PR 1943 and not 1949. (Wendy Reid)

Dave Cramer: +1.

Ivan Herman: +1.

Ben Schroeter: +1.

Brady Duga: +1.

Wendy Reid: +1.

Matthew Chan: +1.

Toshiaki Koike: +1.

Matt Garrish: +1.

Masakazu Kitahara: +1.

Charles LaPierre: .

Charles LaPierre: ].

George Kerscher: +1.

Dan Lazin: +1.

Charles LaPierre: +1.

Resolution #1: Merge PR 1943 and not 1949.

Bill Kasdorf: +1.

Proposed resolution: Close issue 1913 once PR 1943 is merged.. (Wendy Reid)

Ben Schroeter: +1.

Brady Duga: +1.

Wendy Reid: +1.

Matthew Chan: +1.

Masakazu Kitahara: +1.

Ivan Herman: +1.

Bill Kasdorf: +1.

Dave Cramer: +1.

Dan Lazin: +1.

Matt Garrish: +1.

Charles LaPierre: +1.

Resolution #2: Close issue 1913 once PR 1943 is merged..

Dave Cramer: I would warn everyone to be wary of custom elements, because it’s easy to miss things related to a11y. HTML elements take care of a lot of that thinking for you.

Ivan Herman: that’s not really our fight, leave for WHAT WG.

Dan Lazin: we use custom elements quite a bit in my day job, and there are more a11y friendly ways of doing it, but yes, beware.

2. What happens to issues that don’t have enough implementations?.

2.1. What happens to features that do not get enough implementation in CR? (issue epub-specs#1944)

See github issue epub-specs#1944.

Dave Cramer: the point of the W3C process is to show that features are implementable by writing tests and showing that that test can be passed by more than 1 independent implementation.
… so, where we don’t find implementations, what then?.
… and how do we balance against our need for backwards compatibility.

Ivan Herman: the usual approach is to say that in a normative statement doesn’t have enough implementations it is removed from spec.
… we cannot do this because of backwards compatibility.
… we have to resolve this before we go to CR.
… there are 2 categories already used for features that are not entirely okay. 1) “Legacy” (e.g. NCX) which are there in the spec because people may still want to use EPUB2. These are not defined in our spec..
… currently we say RS MUST NOT implement them, and users MAY use them.
… so no error or warning if found in an epub.
… “Deprecated” features are ones that were in earlier versions of epub3, but were not implemented. Authors are discouraged from using them (“SHOULD NOT” use), and RS MAY implement them.
… I think none of the two are a good fit for answering this issue.
… the feeling is that legacy features may disappear from future versions of epub.
… deprecated is saying that we are discouraging users from using them, and this may be a strong statement because we may still hope that some of the features that lack implementation today may find implementations in the near future.
… I think we should introduce a 3rd option, yet to be defined, maybe “Optional”. Something that authors may use, and RS should implement..
… i.e., they are not normative, but maybe in a later version of spec they may become normative.
… (and we’d remove the optional classification at that point).

Matt Garrish: generally agree, but wanted to clarify that we’re not going to start labelling new things as legacy.
… only epub 2 things can be legacy.
… and agree that we’re not going to start deprecating things that we still want to keep alive.

Dave Cramer: its hard to talk about this in the abstract.
… so using fallback as an example, my understanding is that the feature as described is not implemented anywhere, yet it affects rendering of epubs today.
… i don’t like the idea of Optional because it gives the wrong impression; if a feature isn’t implemented, then it doesn’t work, and you shouldn’t use it.
… not sure what we should do, but I don’t want to leave things in the spec without discouraging people from using them.

Brady Duga: Google Play supports fallbacks btw.
… but maybe “At Risk”?.

Ivan Herman: “At Risk” has a specific meaning within W3C process.

Brady Duga: okay, then something at suggests the risk of using those features that have not received implementations then.

Dan Lazin: I think Optional and May have the same normative meaning, but May implies “you can do this” while Optional implies “you can do this, but not sure why you would”.
… so can we just use May instead?.

Ivan Herman: the exact word we use to label these sorts of features is kind of an editorial question, we need to decide whether we need a category for these.

Dave Cramer: and what would epubcheck do with these?.

Bill Kasdorf: How about simply “strongly discouraged”?.

Dave Cramer: i think we should continue to align with epubcheck on these issues. So if we introduce a new category, there should be a corresponding category of flag in epubcheck.
… based on the tests we’ve done so far, what else might end up in this category?.

Wendy Reid: the reading system object.

Dave Cramer: i think ibooks does something with that?

Brady Duga: i thought it was implemented among RS that support scripting.

Wendy Reid: some of the FXL properties, like mixed layouts (i.e. where a single book has fixed and reflow content).

Ivan Herman: we have to specify what happens to these features in advance of CR.

Dave Cramer: we will be influenced in our decision based on what sorts of features will fall into this bucket, as determined by testing results.

Ivan Herman: that’s kind of chicken and egg.
… and are we sure that all package metadata are used by enough publishers?.
… today there are some properties that are deprecated, might be the case with some of the properties we still have.

Dave Cramer: given that this is about CR exit criteria, this depends on the judgement of the Director.
… do we have any sense of what the feeling is, especially given all the history of epub.

Ivan Herman: I have a weekly meeting with that level of the W3C, so the channel of communication is open.
… to be specific, I think we should add a 3rd category in appendix A (beside legacy and deprecated), and make it clear that this category is meant for features that we don’t want to deprecate, but authors must use with care due to their risky status.
… I can present this to the Director.

Matt Garrish: is there a timeline for this? When is the classification determined?.

Ivan Herman: when we leave CR.
… so the classification will be valid for the next recommendation.

Matt Garrish: so should we say that these features have been given a pass for this version, but that they might be deprecated in the next version if we don’t find additional support?.

Dave Cramer: we’ve gotten into trouble with this sort of thing in the past. Don’t want to say what will happen in future..

George Kerscher: are these experimental features we’d like to see implemented? Or is this something that we want to get rid of?.

Dave Cramer: unclear, the testing would answer those questions. There won’t necessarily be any sort of pattern. Obviously we thought all the features were good ideas at the time we wrote them.

Charles LaPierre: what is the difference between “risky” and “at risk” if we’re applying these labels at the point we go into Rec?.

Dave Cramer: at risk is a term of art in W3C, could cause backwards compatibility issues.

Ivan Herman: if we label something “at risk”, then the usual view is that we’re required to remove that feature from spec before Rec, and we cannot do this because of the backwards compat mandate.
… if something is simply “risky”, then its up to us whether to remove it.

Dave Cramer: seems to be consensus that we need 3rd category, though the language is to be determined, it would be tied to epubcheck with a flag that is something less severe than a warning.

Proposed resolution: Label “risky” features in the spec with a name TBD, would correspond to a flag in EPUBCheck, close issue 1944. (Wendy Reid)

Wendy Reid: +1.

Proposed resolution: Label “risky” features in the spec with a name TBD, would correspond to a flag in EPUBCheck. (Wendy Reid)

Dave Cramer: +1.

Ben Schroeter: +1.

Wendy Reid: +1.

Toshiaki Koike: +1.

Charles LaPierre: +1.

Masakazu Kitahara: +1.

Avneesh Singh: +1.

Matt Garrish: +1.

Matthew Chan: +1.

Brady Duga: +1.

Bill Kasdorf: +1.

George Kerscher: +1.

Resolution #3: Label “risky” features in the spec with a name TBD, would correspond to a flag in EPUBCheck.

Ivan Herman: who has the action on #1944?.

Matt Garrish: I can take it, starting with the name “risky”.

2.2. Aligning EPUB terminology on outdated features with HTML5? (issue epub-specs#1942)

See github issue epub-specs#1942.

Proposed resolution: We will not be adopting the HTML terminology for risky features, close issue 1942. (Wendy Reid)

Dave Cramer: +1.

Ivan Herman: +1.

Matt Garrish: +1.

Matthew Chan: +1.

Ben Schroeter: +1.

Brady Duga: +1.

Wendy Reid: +1.

Toshiaki Koike: +1.

Masakazu Kitahara: +1.

Bill Kasdorf: +1.

Avneesh Singh: +1.

Resolution #4: We will not be adopting the HTML terminology for risky features, close issue 1942.

3. AOB.

Wendy Reid: there’s only one more meeting this year before we go on break.

Avneesh Singh: When we think we would go to CR?.

Ivan Herman: we still have security review issues.

Dave Cramer: TAG may have issues.

Ivan Herman: I think CR before March is not realistic, though I would be happy to be proven wrong.

4. Resolutions