EPUB 3 Working Group Telco — Minutes

Date: 2021-04-09

See also the Agenda and the IRC Log

Attendees

Present: Tzviya Siegman, Deborah Kaplan, Avneesh Singh, Ivan Herman, Masakazu Kitahara, Toshiaki Koike, Wendy Reid, Ken Jones, Matthew Chan, Gregorio Pellegrino, Brady Duga, Matt Garrish, George Kerscher, Charles LaPierre, Dan Lazin, Bill Kasdorf, Teenya Franklin, (Apologies for tardiness), Ben Schroeter, Garth Conboy

Regrets:

Guests: Dave Cramer

Chair: Wendy Reid

Scribe(s): Matthew Chan

Content:

Wendy Reid: welcome

1. Overview of TFs

Wendy Reid: we’ve had 2 TF meetings
… FXL a11y TF, and virtual locators TF
… both TFs have figured out what they want to work on, and are starting up
… FXL a11y meeting every tuesday
… still working out timing of virtual locators TF, since it is more international
… more issues with timezones
… FXL a11y is focusing on updating Daisy KB info with problems that we see in the content today, write some best practices documentation, and experimentation with using more modern CSS (e.g. grid, flexbox) instead of hacking in functionality in spec
… virtual locators TF trying to figure out use-cases
… there is now a wiki if you have use cases to add
… still trying to figure out a date for the scripting meeting
… it will not currently be a TFs, but rather a series of a couple meetings
… please send Doodle to anyone interested in working on epub scripting

Wendy Reid: See Wiki for Virtual Locator use cases

Gregorio Pellegrino: can you please reshare Doodle for scripting?

Wendy Reid: See Doodle poll for the scripting TF meeting

2. Testing Update

Wendy Reid: See Google sheet for the tests

Dan Lazin: good morning, all. I’ve made a few first steps, and would like to talk about how you can contribute
… i’ve complied a spreadsheet, it is a catalogue of all the normative statements in the RS spec
… it is no longer exactly accurate, since we’ve been making modifications to the spec
… let’s just focus on the MUSTs for now
… there are ~186 normative statements in RS spec
… some might require multiple tests per line
… among these 105 MUSTs
… in the github tests repo, dauwhe has contributed some and I have written some
… currently organized according to the order of the spec
… I’ve started writing tests for the media types
… dauwhe has written a test template that anyone can use
… getting through 105 MUSTs will be a lot of work, so please contribute if you can
… put your name in the far right column to claim a particular statement if you’re writing a test for it
… please only claim one at a time

Ivan Herman: let’s say I put in an XHTML containing a jpg, then I make it an epub using my own machine?

Dan Lazin: there might be a script in the repo that does that, but I’ve just been using eCanCrusher

Ivan Herman: i think we should try to make a service online to help people create those epubs, or a set of instructions to help people figure out what they need to install on their machine

Dave Cramer: i tried to automate a bunch of stuff when I started testing, but the only thing that really saved time was that little testing template that is already up there in the repo

Dan Lazin: i’m happy to do a little introduction for people who are new to epub authoring

Ivan Herman: we eventually need a way to prepare a report of our testing
… makes sense to think about metadata about our testing now, rather than when we already have 200 tests…

Dan Lazin: can you take a look at the spreadsheet and call out what we are missing?
… we’d export the spreadsheet to JSON when we are done
… but yes, let’s set it up so that it contains all the metadata that we’ll need

3. WebIDL/epubReading System

See github issue #1610, #1420, #716.

Wendy Reid: See relevant section in the core spec

Ivan Herman: we have a separate section with a small webIDL describing the RSO
… i have two questions
… first, should it be normative? (it currently is)
… second, if normative, we may run into the problem that webIDL is considered by browser implementors as something they have to implement
… other specs I’ve worked on have used webIDL, and it has gotten us into trouble
… I’d prefer to avoid this if possible
… the spec also calls it a JS epubReadingSystem object, but webIDL is supposed to be language independent

Dave Cramer: is there something in W3C policy that says if you use webIDL then all browsers must implement it?

Ivan Herman: no, BUT i’d rather not get into this type of discussion about down the line
… some other people might disagree with me and say that implementation is required. We do not want this discussions with the AC at voting time.

Brady Duga: i think webIDL is for things intended to be implemented by browsers
… but it does seem to be a normative requirement because of statements that we make later on in the appendix

Wendy Reid: can someone please explain the importance of webIDL?

Brady Duga: we were just trying to describe the RSO stuff using webIDL

Tzviya Siegman: one of our goals is the define the role of the RS more clearly, and I’m not sure that this section does that?

Dave Cramer: I think it does, webIDL is the industry standard for describing APIs

Garth Conboy: maybe we can just describe it in JS?

Ivan Herman: I think yes

Garth Conboy: so webIDL might be fine to use, but if JS is also fine to use, then maybe we can resolve this small thing by just using JS

Matt Garrish: some time back there was also discussion about maybe dropping RSO entirely…

Ivan Herman: if we turn that section into informative only, then that allows us to bypass formal objections down the line?

Dan Lazin: are we currently just discussing the question of how to DOCUMENT RSO? And how widely implemented is it?

Dave Cramer: some do, some don’t

Garth Conboy: do we care about the requireness of this given that support isn’t unanimous

Brady Duga: not sure how common this is. We should write a test and try it in some RSes
… has anyone in this call implemented it?
… yes it is normative now, and there are MUST statements that point to this, but on the other hand we might spend a lot of time on this only to find out that no one really uses it
… if no one implements this, then we can decide whether to drop it or make it non-normative etc.
… and publishers should tell us if they use JS in their epubs, and if yes, then have they relied on this being available

Dave Cramer: we’ve used this because of the state of epub interoperability
… we use this to figure out which RS our epub is in
… e.g. UA sniffing

Dan Lazin: speaking of interop, one of the testing questions is: When we identify that not RS currently supports, e.g. Opus, does that mean that it ought not to be a core media type?
… my feeling is that giving guidance on where we want to go is a pathway towards future interop
… but when we mandate things that are not widely used, that leads RS implementors to not know what to trust
… and I’m happy to write a test about this

Ken Jones: a lot of FXLs with interactive content rely on scripting, so this is important

Dave Cramer: it is possible to support scripting without relying on epubReadingSystem Object

Ivan Herman: for now, do we say that this thing should be implemented by RS?
… the other possibility is that we keep as normative requirement, but flag as at risk

Avneesh Singh: +1 to ivan, flag at risk and keep as normative requirement for now

Ivan Herman: I’m leaning towards the second option, plus, rewording the section using JS

Proposed resolution: Flag appendix A as at-risk, keep as a normative requirement and test implementation, remove the WebIDL (Wendy Reid)

Garth Conboy: +1

Gregorio Pellegrino: +1

Brady Duga: +1

Matt Garrish: +1

Deborah Kaplan: +1

Masakazu Kitahara: +1

Avneesh Singh: +1

Dan Lazin: +1

Ben Schroeter: +1

Matthew Chan: +1

Ivan Herman: +1

Tzviya Siegman: +1

George Kerscher: +1

Charles LaPierre: +1

Resolution #1: Flag appendix A as at-risk, keep as a normative requirement and test implementation, remove the WebIDL

4. CSS Direction

See github issue #1614.

Ivan Herman: in the core spec, there is an item which says that RS must not use CSS features for direction and bidi:

Because HTML UAs can turn off CSS styling, we recommend HTML authors to use the HTML dir attribute and element to ensure correct bidirectional layout in the absence of a style sheet. Authors should not use direction in HTML documents.

Ivan Herman: in the CSS documentation this is advice based on the fact that certain browsers may not implement CSS
… core spec turns this into a MUST
… should we depart from CSS spec in this way?
… if we keep it as it is, then what should RS do if they do encounter CSS that uses these features?

Dave Cramer: epub says that you can’t use CSS direction since epub 3.0
… this is enforced in epubcheck
… CSS group is very adamant that this is the wrong way to provide info about text direction
… preferring use of HTML attribute dir
… everyone seems happy with this state of things
… understand that current language is slightly different from CSS, but i just don’t see the value of changing this right now
… there are other examples where epub spec has been more stringent than average
… in terms of what RS should do if they see it, I think they should just follow the CSS
… no special treatment necessary

Matt Garrish: RS interop is critical, part of the rationale for having these requirements

Brady Duga: this wasn’t just fantasai’s opinion, she was a representative of the CSS WG
… also, if you use epubcheck as part of your ingestion pipeline, you might reject an epub if you include this sort of CSS

Ivan Herman: currently the RS spec doesn’t say anything about this, even though we so strongly say this in core
… uncomfortable with the disconnect
… also, the language needs to be updated to account for SVG

Dave Cramer: comfortable with not putting any special requirements on RS when they see this

Garth Conboy: could we acknowledge this in RS spec, and specifically say that an RS is able to do whatever it feels is appropriate?

Dave Cramer: yes, I would agree

Proposed resolution: Amend the RS section to allow RSs to do whatever they “damn well” please with CSS direction (Wendy Reid)

Tzviya Siegman: +1

Garth Conboy: +1

Deborah Kaplan: +1

Ivan Herman: +1

Charles LaPierre: +1

Brady Duga: Damn well +1

Wendy Reid: +1

Matthew Chan: +1

Dan Lazin: +1

Bill Kasdorf: +1

Gregorio Pellegrino: +1

Ben Schroeter: +1

Resolution #2: Amend the RS section to allow RSs to do whatever they “damn well” please with CSS direction

5. AOB?

Wendy Reid: it is (virtual) F2F season
… thinking of making it similar to what we did with the TPAC one

George Kerscher: +1

Wendy Reid: i.e. 3 hour at JP time, followed next day by 3 hour at this time slot
… thinking of May 13/14 or May 27/28

Ivan Herman: May 13 may conflict with public holiday in some parts of EU
… some people may have holiday plans around that time

Gregorio Pellegrino: no, that’s not a problem for us

Dan Lazin: https://w3c.github.io/epub-specs/epub33/rs/#dc-creator

Dan Lazin: couple quick questions about testing philosophy
… that is a single para with 2 normative statements in it
… should that be one test, two tests?

Dave Cramer: i don’t think the division of the spec text should affect testing
… comfortable treating those as separate tests

Tzviya Siegman: +1 to dauwhe

Ivan Herman: very often text in spec is structured to increase readability
… in practice there are two tests, regardless of how the text is

Dan Lazin: we are driving towards more interop, so when we can’t find independent RS implementations, what do we do? Do we revisit the “mustness” of it?

Ivan Herman: yes

Dan Lazin: what about minor RS support?

Ivan Herman: it’s not up to us to make that minor/major distinction

Dave Cramer: also, we have a mandate to maintain backwards compat

6. Resolutions