Publishing Working Group Telco — Minutes

Date: 2018-08-27

See also the Agenda and the IRC Log

Attendees

Present: Deborah Kaplan, Avneesh Singh, Teenya Franklin, George Kerscher, Tzviya Siegman, Gregorio Pellegrino, Caitlin Gebhard, Dave Cramer, Ivan Herman, Matt Garrish, Rachel Comerford, Tim Cole, Romain Deltour, Ric Wright, Jeff Buehler, Derek Jackson, Garth Conboy, Marisa DeMeglio, Hadrien Gardeur, Ben Schroeter, Bill Kasdorf, Brady Duga, Charles LaPierre, Zheng Xu, Chris Maden, Juan Corona, Karen Myers

Regrets: Luc Audrain, Laurent Le Meur, Nick Ruffilo, Murata Makoto, Adam Sisco, Jean Kaplansky, Franco Alvarado, Benjamin Young, Josh Pyle

Guests:

Chair: Tzviya Siegman

Scribe(s): Matt Garrish

Content:

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-08-20-pwg.html

Resolution #1: last week’s minutes accepted

Tzviya Siegman: minutes approved

0.1. issue 291, TOC

Tzviya Siegman: take a look at Rachel’s summary style and please try to adopt it for issues

Tzviya Siegman: https://github.com/w3c/wpub/issues/291#issuecomment-415510019

Tzviya Siegman: Differing opinions about how to specify the ToC in WPUB. Some are of the opinion that a ToC can include anything as long as the HTML includes aria role=”doc-toc” to signal to the UA that it is the ToC. Some are of the opinion that the ToC must be more strictly defined so that the ToC can be processed in a standard way by UAs.

Garth Conboy: there is contingent of people who think we shouldn’t put substantial constraints on the toc to work with the web, but for reading systems we need a toc that can be machine processable. We ought to have the ability to provide a machine-readable toc similar to the epub 3 nav doc that can also be pointed to

George Kerscher: There would be 0 or 1 file with DocTOC?

Deborah Kaplan: when there is a toc that cannot be machine readable there should be the option for a nav doc

Dave Cramer: all html documents are machine readable because that’s what UAs do - the question is more are we trying to create something they will be happy with - a user agent can do something just by taking all the anchor elements, for many books that will be useful - may not get you nesting, but could look at placement in the dom - better to look at what machines can do than constrain authors

Tzviya Siegman: one of the things we’ve seen with epub is that the restrictions on epub table of contents are not awful - don’t restrict people too much - but when there are multiple tables of contents I use the machine one - I think the simplest way to consensus is to reduce the restrictions and still allow authors to include what they need - you can still have two tables of contents

Tzviya Siegman: the one that is processed by reading systems will be the one with somewhat restricted html

Deborah Kaplan: +1 tzviya

Garth Conboy: the epub restricted navigation document is successful but also need the option to allow more expansive tocs

Dave Cramer: i think styling is orthoganal to the issue - what css uses to make it look nice is independent of the markup

Bill Kasdorf: it’s not about making the toc look pretty but needing more flexibility - in education you need a longer table of contents with sidebars and other content

Tzviya Siegman: the proposal is not to restrict the number of tables of contents - only the markup for one

Deborah Kaplan: +1 dauwhe.

Tzviya Siegman: +1 to dauwhe

Dave Cramer: if we were to adopt something like epub 3’s restrictions we should look at whether we can relax the restrictions - like allowing either ul or ol as the root list element

Deborah Kaplan: But maybe allowing ul is one thing, but not allowing, say, sliders. :)

Dave Cramer: what will give us the most benefit instead of just demanding one way

Bill Kasdorf: +1 to both Tzviya and Dave

Tzviya Siegman: it sounds like we’re coming to consensus that restrictions should be placed on the referenced table of contents - #2 in the github issue

Romain Deltour: putting restrictions on the html would be a way to help implementers extract the toc data - goes against the priorities of constituencies - authors should have the flexibility and the implementer should have to figure out the algorithms to extract - i would rather come up with an algorithm to extract the toc in a predictable manner

Ivan Herman: i am trying to understand where we are - at this moment in the manifest we have a way to address the toc - are we saying that that element must have a structure we have to define - or is it required? if it is not required we can acknowledge the fact that there are two types we can provide - if the author doesn’t want to use one she can use a different kind of toc but don’t expect some

Matt Garrish: regularity in the reading system

Hadrien Gardeur: Edge has a native UI for ToC as well

Deborah Kaplan: I disagree, dauwhe: I think it’s arguably also AT centric

Dave Cramer: I agree with what romain said and this discussion is very epub-centric - we are expecting that the UA will want to process and display the toc in an entirely different way - does not normally happen on the web

Bill Kasdorf: +1 to Dave. This is an issue that should probably be a point of difference between a Web Publication and an EPUB.

Tzviya Siegman: unless we’re saying there is a way to structure the content, it makes it harder to trigger an algorithm

Tzviya Siegman: i like the idea of relaxing the restrictions, though

Garth Conboy: i don’t think authors need to worry about this because tools will handle - if user agents don’t do special things with WPs then I think we’re wasting our time - having two pointers to tocs might be the best solution

Deborah Kaplan: i don’t want a machine to have to compile a toc

Dave Cramer: i would like to require that everything in the linear reading order be in the table of contents - we need examples of tocs and see whether they can be machine processed and discover why not

Avneesh Singh: from accessibility point of view the hierarchy of the publication is what makes it different from the web general - beyond machine readability some kind of restriction would help

Romain Deltour: what happens when the author doesn’t respect the restrictions? we have to specify what a UA must do then. But when we specify that, and unless we tell the UA it can ignore the toc, why do we need to specify the restrictions in the first place?

Tzviya Siegman: in the real world we could get all kinds of tag soup in the toc

Brady Duga: are you looking for things that will break? that’s very easy - just include a picture of a table of contents

Dave Cramer: so a table of contents must have links

Tzviya Siegman: which is an example of a restriction

Garth Conboy: it needs to have structure - nesting - so list elements - we’ve learned this lesson in epub

Romain Deltour: I don’t see what kind of restriction would be useful - if the toc is useless that’s the author’s choice

Deborah Kaplan: I’d like to be able to tell AT how to navigate a wpub’s TOC

Tzviya Siegman: the concern comes from UAs - they will be required to generate some kind of navigation - we need to have accessibility and multiple ways to access the content - if the author provides an image it won’t help the UA

Romain Deltour: we don’t require accessibility - accessibility is something the author has to ensure - handling a toc that doesn’t respect the restrictions will have to be handled no matter what

Romain Deltour: so long as we define how to extract data why do we need restrictions

Avneesh Singh: wcag talks about multiple ways but it doesn’t define how the hierarchy must be presented - in epub we have lists - but if publisher is providing a toc that is clear to a sighted reader and not to blind then it is not accessible - having some rules ensure consistency

George Kerscher: having no doc-toc for a publication would be fine in some cases - if there is one pointed to in the manifest then it should be possible to evaluate what the UA is going to do with the markup

Tzviya Siegman: validators on the web are nice to use but the content has to work even if content isn’t validated

Ivan Herman: at the moment we have the concept of a toc in the manifest - it is in the reading order or resource list - has to point to an html document which contains an element marked with role=doc-toc - i propose that we have two: one with doc-toc and another with some other semantic

Hadrien Gardeur: +1 to what ivan said, but need to discuss if this is in the context of WP or EPUB4

Ivan Herman: the user agent has the option to put one or both tocs into the manifest - we then have the idea to play with restrictions - epub 4 might have stronger restrictions for reading systems

Hadrien Gardeur: also need to discuss if the second (optimized for machine readability) is HTML or directly in the manifest

Ivan Herman: both could be marked as doc-toc but one has a stricter structure

Garth Conboy: both would be possible in WP

Ivan Herman: in epub perhaps we only want the restricted one

Tzviya Siegman: what is the purpose of having two tables of contents?

Ivan Herman: the user agent could decide if the restricted version isn’t available if does nothing

Ivan Herman: we could have a different rel value for the loosely-structured toc

Hadrien Gardeur: I’m in favour of having two tocs, but what is the context - do we need two html nav elements or should the machine-readable one be purely in json

Tzviya Siegman: if authors want to create a separate toc that’s fine and it can be anywhere

Ivan Herman: authors still have choice to provide one, none or both of the toc types - I’m not in favour of putting the toc in json as putting it in html will be simpler for authoring

Deborah Kaplan: Hadrien, Tzviya wasn’t saying more confusing for UAs, but for authors

Hadrien Gardeur: having two documents shouldn’t make things more complex - with the current toc you can only provide a way to get to it - with a machine readable the UA can present it - not complicated for UAs

Garth Conboy: I tend to think having them both html leaves open the possibility of having a toc that is both displayable and machine-readable

Tzviya Siegman: so the proposal is to have two table of contents - one structured and one with an open structured - you can have any of these, including none

Garth Conboy: +1

Deborah Kaplan: +0

Hadrien Gardeur: +1

Tim Cole: +1

Bill Kasdorf: +1

Ivan Herman: +1

Jeff Buehler: +1

Caitlin Gebhard: +1

Romain Deltour: -0.1

Derek Jackson: +1

Garth Conboy: (max one structuredd, max one unstructuredd)

Avneesh Singh: +1

Ric Wright: +1

Marisa DeMeglio: -1

Zheng Xu: +1

EvanOwens: +1

Dave Cramer: -0

Deborah Kaplan: people are already confused by having too many choices in epub - worried that no one will get it right or understand why the possibilities exist

Romain Deltour: don’t understand why the structured one when an algorithm can process the html

Ivan Herman: outlining algorithms are a bottomless pit

Romain Deltour: not to compile an outline but only to process the toc markup

Tzviya Siegman: need to consider in the future that validation cannot be expected

Garth Conboy: a pull request to match the the proposal would be useful

1. Resolutions