EPUB 3 Working Group Telco — Minutes

Date: 2022-02-25

See also the Agenda and the IRC Log

Attendees

Present: Avneesh Singh, Masakazu Kitahara, Toshiaki Koike, Matthew Chan, Dave Cramer, Ivan Herman, Dan Lazin, Wendy Reid, Murata Makoto, Ben Schroeter, Matt Garrish, Brady Duga, George Kerscher, Charles LaPierre, GeorgeK, Jen Goulden, Zheng Xu (徐征), Bill Kasdorf

Regrets: Tzviya Siegman

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

1. Fate of the prefixed CSS properties? (issue epub-specs#2003)

See github issue epub-specs#2003.

Dave Cramer: ivan wondered if we should label these as deprecated.
… i will remind the wg of the definition. Deprecated feature is one which is not recommended for use in this version of spec. Generally have no support in RS. Authors should not use in epubs, RS may support. Validators should alert when encountered in epubs..
… i would argue that is not the case here.
… these are widely used and somewhat widely supported. I’m also not sure what benefit we get from deprecating them..
… also, the behaviour of prefixed properties in css is pretty well defined, and its common web dev practice to have both prefixed and non-prefixed version of property for widest compatibility.

Ivan Herman: we have lets say 15 of those prefixed properties, quite a large number.
… at the moment they are required features, i.e. every RS must implement.
… if we agree with that, then we need to create tests for each of those.

Dave Cramer: one way to phrase this is that these are epub specific features which don’t yet have tests.

Ivan Herman: yes.
… and before we start making tests, we should ask whether it is worth the trouble of doing that work.
… agree that the term ‘deprecated’ may not be correct here.

Dan Lazin: is the reason that we want to deal with this that the testing status is unclear?.
… this is motivated mostly by testing?.

Murata Makoto: I’m surprised to see “MUST support all prefixed properties defined”.

Ivan Herman: there are appendices in testing for vocabs, including for this, and i’m not sure what to do with it.

Dan Lazin: seems like we just need to write tests for this, rather than consider deprecation/under-implemented status.

Brady Duga: might be embarrassing to include these in the spec, but we can’t really get rid of them because there is content that uses these.
… in reality, I see content that uses all possible prefixes, and other content that uses none of the prefixes.
… toshiaki koike did essentially write some tests for these already, they are in the bug report.

Dave Cramer: i’m not embarrassed by these, we needed them back in the day, there was no alternative.

Ivan Herman: is it correct that each of those prefixed CSS attribute have now a regular CSS attribute?.
… if ‘yes’, then having it as a required feature in Core seems not a good thing.
… we could say ‘for reasons of backwards compatibility, then RS should implement as well’, but we can also say that new epubs created today should not use these.
… they should use the CSS ones instead.
… the same way that new content should not use mozilla and chrome specific prefixes today.

Dan Lazin: yes, they all have non-prefixed versions. At least this is what the documentation currently implies.

Brady Duga: they all have non-prefixed versions, but the function isn’t 1-to-1.

Dave Cramer: also, given the nature of epub RSes, we often need to author content that needs to work in RS that have not been updated in a while.
… there might be cases where there are good reasons to do this.
… CSS accounts for this by allowing authors to use both prefixed and non-prefixed.

Dan Lazin: don’t old RS implicitly not support epub 3.3?.

Wendy Reid: no, because epub 3.3 is a valid epub 3.2, etc. etc. backwards compatibility.

Dave Cramer: i think we just write some tests here.

Brady Duga: do we point people to the right way to deal with pre-fixed properties (i.e. also state the non-prefixed properties)?.

Dave Cramer: this is just an appendix, we’re not necessarily calling attention to the right way to do things in this section.

Brady Duga: i was thinking just a pointer, but okay, this is pretty easy to test.

Wendy Reid: i think we might want to add text that says “we’re in a different place now, these css properties are supported in modern web, we recommend that you use both prefixed and non-prefixed”.

Murata Makoto: -epub-text-combine: horizontal 3 cannot be rewritten without using prefixes.

Ivan Herman: the fact that it is an appendix does not mean that it is non-normative, let’s not conflate these.
… for the time being this is a normative section.
… my proposal would be, in the content document, both entries should be marked ‘should not be used’, and in the RS doc, we say ‘should implement’.
… and if they are ‘should’, then we should write tests.

Matt Garrish: it does strike me as strange that RS says you must support all of these properties, but we’re also talking about how these are being phased out.

Dave Cramer: we do have a note about this, but it’s in the main section rather than the appendix.
… i’ll post a link.

Dave Cramer: See Section on prefixed CSS properties in the core document.

Ivan Herman: i propose to put this in the main text, as normative text.

Dave Cramer: i’m opposed to that. I think what we have is good enough. Given how CSS works, and that people have legitimate reason to use these prefixes, I don’t think we make a SHOULD NOT statement.

Bill Kasdorf: Is “as the Working Group does not anticipate supporting them in the next major version of EPUB” still the case? Probably, because of “major version”?.

Brady Duga: i’m now worried that even the should in the note is too strong.
… older RS exist that don’t support the unprefixed properties, and we’re telling authors not to use the prefixes. So are we asking authors to have knowledge of which RS will work with their epub, and which won’t?.
… are we telling authors that they need to do their own research, when they already have a way of making it work everywhere?.

Dave Cramer: we say that they SHOULD use the unprefixed ones, but we don’t say they SHOULD NOT use the prefixed one….

Charles LaPierre: sounds like the unprefixed is a must, but authors may add in these prefixes for backwards compat with older RS, right?.

Dave Cramer: right now RS spec says RS MUST support these, right?.

Matt Garrish: yes.

Dave Cramer: and for the reasons we’ve mentioned I don’t think this should change.
… in general, stuff like this is easy. You’re just aliasing something. Browsers know how to do this, do it all the time..
… no real burden on RS.
… and i’m uncomfortable saying RS must support, but authors must not use it.

Brady Duga: i don’t think that’s the situation.
… if i were to advise someone writing an epub now to get their epub to work on the widest range of RS, i would say include both prefixed and non-prefixed.
… unless you really want to do the work to limit which RS your epub will be compatible with, or you want to do the analysis on different RS.

Ivan Herman: i see the must support in RS, and grudgingly I agree. For content, we say you may use the prefixed properties..
… right now I read the content doc to say that you MUST use the prefixes, and I think that is too much.

Dave Cramer: so this would be a normative MAY?.

Ivan Herman: yes.
… you may use prefixed properties in so and so situation.

Brady Duga: i almost feel like if we are giving advice to content authors, then we should make it a SHOULD.

Matt Garrish: going back to the CSS section, we are saying that you MUST support these properties, but you aren’t required to support the CSS modules that they are part of?.
… is this inconsistent?.

Ivan Herman: ouch.

Dave Cramer: looking at snapshot 2021, writing modes is in core.
… i’d have a difficult time telling RS they don’t have to support CSS text 3.

Brady Duga: i know we cannot remove these properties, we need them to support vertical texts.

Dave Cramer: okay, so consensus is that we need tests, that these aren’t going away.
… no consensus yet on what advice/statement should be in the core spec.
… do we want to have someone propose different text for 3.3.1.3?.
… can we do this working out of the language in the issue?.

Wendy Reid: writing the tests will probably help.
… if the person who writes the tests sees that the properties are more or less supported it will inform what we say.

Ivan Herman: so do we have a test writer?.

Wendy Reid: i can do it.

Dave Cramer: okay, sounds like we have a plan to make progress.

Ivan Herman: sorry to have raised this so late in the process.

2. Add reporting document for package metadata (pr epub-specs#2002)

See github pull request epub-specs#2002.

Matt Garrish: coming out of last meeting, we said we needed to report on all the metadata vocab we define in the authoring spec.
… basically same issue we had with DPUB ARIA vocab.
… I created a table that maps each property to the publishers that use them.
… its just a placeholder so far, needs to be filled out.

Dave Cramer: how would this work? Will we merge this, and then publishers who use the property would add their name via PR?.

Matt Garrish: we ask people to open PR, or they send them lists of which properties they are using, and we can add them.
… also question of if we need to have links from the spec to this table, and how that would work.
… not sure if we need to tackle that now.

Charles LaPierre: if we need to have any properties that are being used, I can go through the completed CGA reports from publishers and find all the accessibility metadata in there if that’s helpful.

Matt Garrish: i’m hoping you can take a look at the a11y document.
… you’d just put the name of the publishers in there.
… i’ve pre-populated some names based on CGA certification.

Ivan Herman: my proposal is to merge this because what mgarrish referred to about linking.

Ben Schroeter: just a word of caution that we’re not violating any NDAs when we’re pulling stuff from GCA reports.

Charles LaPierre: absolutely, i’ll talk to the publishers first.
… mgarrish when you mention the certifier report, I actually spoke with folks at Benetech about creating separate reports for publishers who have passed certification, and creating report pages for each publisher.
… the page could be customized for each publisher, to include their support email address, etc..

Matt Garrish: if you want I can take out the changes to the a11y report and make it a separate PR.
… give you time to talk to publishers.

Charles LaPierre: okay, thanks.

Ivan Herman: we also need the same thing for all the vocab in the package document.
… maybe its already somewhere, but we need to collect that too.

Charles LaPierre: i was just referring the a11y properties.

Dave Cramer: sounds like there is broad consensus about merging these.
… also caution that just because a publisher uses some of these properties, it doesn’t mean that it works anywhere.
… e.g. “file as”.
… and just because a publisher uses a property, doesn’t mean they are using it properly.
… in some cases (e.g. dc:rights), not clear how these are to be used.

Charles LaPierre: not just RS, but libraries and bookstores as well can expose this metadata, as a secondary source for examples of use.

Matt Garrish: we just need to show that these aren’t completely fanciful.

Dave Cramer: right, that people want to use these metadata.

Proposed resolution: Merge PR 2002. (Wendy Reid)

Ivan Herman: +1.

Wendy Reid: +1.

Matthew Chan: +1.

Matt Garrish: +1.

Bill Kasdorf: +1.

Ben Schroeter: +1.

Masakazu Kitahara: +1.

Dave Cramer: +1.

Toshiaki Koike: +1.

Resolution #1: Merge PR 2002.

Dave Cramer: mgarrish you were going to split out some of the stuff for CharlesL before you merge it?.

Matt Garrish: yes, i will.

3. How do you allow EPUBs in CORS / CSP / iframe origin policy? (issue epub-specs#1843)

See github issue epub-specs#1843.

Dave Cramer: this is issue about external iframe resources, and CORS headers about having this in epub.

Dan Lazin: we were talking a few months ago about whether external resources are good idea, and how there are legit cases for them..
… say you are an educational publisher, and you have a demo that you want to embed, but only in your website and your epubs.
… normally you do this by setting X-frame or CSP in your server.
… not sure how you would do this in epub, since it doesn’t have URL.
… the internal browser core may have a URL that it uses to refer to the epub, but as an RS developer, I don’t know what that is.

Ivan Herman: i played with this URL area in the spec in Nov, and your supposition is correct.
… an epub document has its own fancy URL which is different from one RS to another.
… there is no way a 3rd party setting up a website could refer to it in a security policy.
… we don’t define what the root URL of the package is, we only define it in a behavioural way.
… earlier today I saw in Apple Books and Thorium that some of them use URLs that are non-standard, etc..
… simply put, you can’t do it. And not sure how you would do it..

Dan Lazin: might be okay for us not to implement it, but it might not be our call whether we implement it or not.
… security horizontal review might take issue with it.
… should we note this in our security document?.

Matt Garrish: it’s not that it’s not supported, but as you say, you can’t rely on it or it might work.
… it’s the same with any web scenario where you can’t set the header.

Brady Duga: the way you describe CORS is almost like a DRM mechanism, but it’s more like, a script is only allow to request resources from a place that would allow that origin.
… this is only for scripting and a few other places.
… we support CORS, but it might not work. You can use wildcards to set the origins.
… we haven’t created a security hole, it’s more like our security is very restrictive/tight.

Ivan Herman: +1 for Brady’s formulation.

Dan Lazin: so I would have to allow my server to be iframed by anyone, can’t limit to only my own books.
… say you had a sign-in page that i wanted to control iframing of, I couldn’t do that.

Ivan Herman: only change I can see is to explicitly add this to the security document somewhere.
… it’s otherwise an unsolvable problem.

Dan Lazin: duga’s point about wildcards means there might be a solution.
… could we for example say that epub origins must always have epub: protocol?.

Ivan Herman: we’d have to define the protocol, and no current RS uses it.

Dan Lazin: at a future point, if we could create some limits on the epub origin that are easily wildcardable, we could make CORS/CSP work in epub.

Ivan Herman: we can think about this in epub 4.

Dave Cramer: not sure what solution we can implement in 3.3.

Dan Lazin: i propose that we add something about this in the security note.

Ivan Herman: dlazin, you should….

Dave Cramer: okay, good bye for now, thank you for all the interesting discussion!.

4. Resolutions