Publishing Working Group Telco — Minutes

Date: 2018-03-05

See also the Agenda and the IRC Log

Attendees

Present: Chris Maden, Avneesh Singh, Tzviya Siegman, George Kerscher, Jeff Buehler, Laura Brady, Teenya Franklin, Deborah Kaplan, Ivan Herman, Wolfgang Schindler, Mateus Teixeira, Wendy Reid, Toshiaki Koike, Jun Gamou, Joshua Pyle, Gregorio Pellegrino, Nick Ruffilo, Luc Audrain, Matt Garrish, Benjamin Young, Charles LaPierre, Lillian Sullam, Bill Kasdorf, Hadrien Gardeur, Rachel Comerford, Franco Alvarado, Tim Cole, Marisa DeMeglio, Jasmine Mulliken, Laurent Le Meur, Ben Walters, Garth Conboy, Peter Krautzberger, Mustapha Lazrek

Regrets: Romain Deltour, Vladimir Levantovsky, Ric Wright, Dave Cramer

Guests:

Chair: Tzviya Siegman, Garth Conboy

Scribe(s): Mateus Teixeira

Content:


Tzviya Siegman: new recruits?

Franco Alvarado: Hi, I’m from the Content Standards team at Macmillan

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-02-26-minutes

Tzviya Siegman: comments on minutes from last week?
… [none] ok, minutes approved

Resolution #1: last week’s minutes approved

1. DPUB-ARIA

Tzviya Siegman: next item on agenda is DPUB ARIA and the work moving forward
… at this point it’s listed in our PWG charter as a full deliverable (DPUB ARIA 2.0)
… ivan, garth, and I have been discussing this
… considering what it actually means to be in the ARIA spec, and which EPUB vocabulary terms are relevant

Matt Garrish: https://github.com/w3c/dpub-aria

Matt Garrish: https://github.com/w3c/dpub-aria/issues/8

Tzviya Siegman: when we opened up this issue, it was in the dpub 2.0 repository, but it’s now in the general dpub-aria repository
… we need to figure out a home for the things that are in epub:type, but we may not have any additions for DPUB-ARIA, other than errata… do people agree?

George Kerscher: I was looking at “aside”, “head”, and “listhead”—they don’t seem to be publishing-specific, maybe should be in HTML?

Tzviya Siegman: I tried, didn’t work out

Tzviya Siegman: https://discourse.wicg.io/t/proposal-list-head-caption-title/1832

Ivan Herman: it’s not killed, just pending for now

Tzviya Siegman: people thought it was a good idea, and the conclusion was “here’s a polyfill and we’ll add it if people use it”

George Kerscher: I’ve asked about a template, have made some improvements, and can send it to the email list
… the problem is when people add a heading to a list that intrudes in the structure of the document
… these problems might be solved for free if they’re in the vocabulary

Tzviya Siegman: maybe not for free, because it all goes back to ARIA

Luc Audrain: we will need something in a web publication to describe a superstructure(?) for the publication, but this is probably not a vocabulary addition
… I was also wondering why there is no mapping for “title”, and is there a good reason for that? We have mappings for “subtitle” and “doc-subtitle”

Matt Garrish: It was removed at request from ARIA group; titles are elements that more definitely belong in HTML—it’s a non-structural label, at least how we’ve done it in EPUB (it’s not the title of the publication)
… “subtitle” was addressing the case for grouping headings, for which there wasn’t an existing semantic

Tzviya Siegman: we had to avoid confusion with https://www.w3.org/TR/html5/dom.html#the-title-attribute

Matt Garrish: there wasn’t such a case for “title” specifically

Luc Audrain: H1 to H6 have a heading role by default, and in HTML there are pending discussions about subheadings, because subheads have been proposed to HTML but not yet accepted

Matt Garrish: right, but we need to define what we want from “title”—the title of the publication or the title of a component in the publication?
… as soon as we need to map it to a heading, it becomes structural
… this is an open conversation, and we still need to define a proper vocabulary for it, but “title” is probably not it
… need to continue working closely with these groups

Deborah Kaplan: when we work with HTML and other groups, we can accept “no”, but should not accept polyfills for accessibility requirements
… polyfills are not an answer to the problem

Luc Audrain: +1

Tzviya Siegman: yes, and “list-head” was not only an accessibility need, it was a publishing need too
… mattg is right that we proposed “title”, but the basic point from the ARIA WG was that the elements in HTML should be sufficient in most cases, so “title” and “list-head” would need to be done in HTML
… but other than errata, let’s identify—what would need to go into ARIA 1.1?
… if you’re interested in contributing to the conversation, e.g., on “list-head”, comment on the WICG thread: https://discourse.wicg.io/t/proposal-list-head-caption-title/1832

Bill Kasdorf: is there a reason why we specifically advocate for something so specific like “list-head”? Isn’t there a need for a heading that does not just apply to a list, but, e.g., blockquotes?

Tzviya Siegman: this is part of a larger conversation, including whether headings should be numbered

Bill Kasdorf: yes, but do we not need to define a heading that does not affect structure but describes its elements?

Matt Garrish: yes, and this is that never-ending discussion with ARIA; you can have many headings that describe different elements but do not define document structure

Ivan Herman: I think at the moment there is and will be a lot of pushback from browser vendors to add any new element to HTML
… without having any clear statement here, but HTML5 has become so huge that the cost of adding new elements is significant
… the answer seems to be to use custom elements before anything is added to the specification… there is a strange limbo; it’s unfortunate, but it is the way it is.

Deborah Kaplan: this is not about any particular element, but if we as a WG determine that something needs to be in HTML and we can make a good use case (e.g., a11y), we can do 3 things: make a fantastic case to HTML WG and why workarounds are bad; we can drop it; or we can do bad workarounds that will never help people
… because if we’re suggesting workarounds and polyfills that don’t end up happening in practice, we’re just blowing smoke
… we’re a W3C WG, it’s our job to come up with these things and make proposals; if they don’t listen to us, they don’t listen to us; but we should at least push our ideas, otherwise there’s no reason to continue this work if nobody will implement it.

Bill Kasdorf: I was advocating for DPUB-ARIA, recognizing the difficulties of adding new HTML elements.

George Kerscher: making sure the a11y card isn’t played incorrectly—regardless of knowledge that something is a “list-head” or whatever… in publishing, describing elements with specific markup is important

Ivan Herman: the reality of the world is such that the group we have to convince is not only the HTML WG, but WHATWG as well… it’s a whole different ball game, a lot more difficult.
… Coming back to custom elements, there may be a fourth alternative to dkaplan3’s: that a working group like ours does define a custom element and its behavior in HTML, that we produce implementations showing it in context of the DOM tree, and that we make it a part of our specification.
… The practicality is that people can use that element as if it were a bona fide HTML element, but that there has to be a link to a JS in the header, which for the end user is immaterial.
… it raises the question—why does that kind of deployment create problems for a11y more than for any other usage?
… the tendency in the HTML community is to say that we cannot solve all problems, so we have to distribute the development of Web core engines, and custom element is one emergent way of doing this, defining shadow DOMs, etc…

Tzviya Siegman: there are other items in the agenda; we should continue this conversation later, but we can’t solve this problem today

Deborah Kaplan: Ivan, As long as anything we propose has actual chances of being implemented by reading systems and used by content producers. I argue that in the real world, content producers don’t use one central, acceptable, ubiquitous polyfill. Every website implements drop-down menus differently, for example. And most of them are inaccessible.

Tzviya Siegman: the main discussion is the shift from DPUB-ARIA 2.0 to 1.1, because there doesn’t seem to be enough to add to the vocabulary

Avneesh Singh: couple of things—1, there are definitely things we can add for a11y, such as support for existing DPUB role implementation in assistive tech; and 2, re custom elements, which browsers can expose, but how will assistive tech recognize them?

Ivan Herman: the issue is more general; what we have to do somehow is identify if there is some way for a standards community like ours to formally extend HTML
… this does not really exist today, and I’ve been trying to get this discussion happening in W3C, but this community might be in the perfect position to lobby for this more general approach

Bill Kasdorf: Rachel: an item for your best practices work in the CG: how to mark up non-structural headings.

Ivan Herman: whether a11y engines accept custom elements is a different subject that comes later on, if an element is recognized, e.g., in HTML or an extension

Deborah Kaplan: Ivan, agreed

Tzviya Siegman: the fun never ends

Matt Garrish: quick comment—what would be good is to focus 1.1 on purely the errata so we don’t get dragged down by these conversations… get the pressing issues done for now

Tzviya Siegman: the biggest errata issues need to be solved by ARIA, otherwise we can solve the rest in a day

Ivan Herman: yes, but keep in mind we therefore reduce our charter and should have a formal resolution to go with that

Matt Garrish: is there not still a 2.0 we do later?

Tzviya Siegman: I’d need to talk to joanmarie and michael first

2. Epub 3.2

Garth Conboy: taking a few minutes to update this group on the “classic epub world”
… and how we might want to proceed into epub 4

Garth Conboy: https://docs.google.com/document/d/1r2RbLipc5VY3vUp_iuPak3oaNxI5BF9gJ5s-98qsmEY/edit#

Garth Conboy: this is a proposal for EPUB 3.2 that Makoto and I put together
… there was a lot of discussion on whether it should be 3.0.2 or 3.2; 3.2 won
… the end result is that we need to acknowledge that 3.1 had no adoption largely because EpubCheck had not caught up to it, but also because it has no backward compatibility with 3.0.1
… there is a movement now toward recasting 3.1 as 3.2, but have it be b-c with 3.0.1, and at time of publication of 3.2 as a community group note, we would withdraw 3.1
… 3.2 would have the same weight as a previous IDPF spec
… it would retain most of what was in 3.1, including its new features (specifically those handling encrypted content)
… the goal is to reduce the cost of 3.1 with the idea that 3.2 would be backward compatible in a way that, I assume, epub 4 would not be
… could take 3.2 through ISO standardization process (important for communities, e.g., in Japan, Korea, etc.)
… this has been presented to the business group, and the hope is that the BG will make a formal request next week for the CG to proceed in this direction with all due haste
… and hoping that by the May F2F in Toronto, we’ll have some progress to share and discuss

Garth Conboy: as we have thoughts toward EPUB 4, we should keep in mind that these efforts might inform those decisions

Hadrien Gardeur: it’s very important that we’re able to reference a Web Publication manifest or something like it, as we’ve been able to do in 3.1 with “rel”
… could enable EPUB files that provide some compatibility across different versions of EPUB
… right now, in the infoset, there’s no way of determining that there is an equivalent, alternative fall-back option to a WP

Tzviya Siegman: let’s open a Github issue, but we’re not discussing details of 3.2 in this group; that goes in the CG

Garth Conboy: that’s the EPUB 3.2 update…

3. F2F logistics

Garth Conboy: now moving back to Web Publications and our F2F in Toronto
… please RSVP if you can come (and don’t remove names of people you don’t want to come)
… there are some reasonable hotel rates, courtesy of Kobo, but there are limited spots (up to 30 rooms)
… we’ll try to support remote participation as much as possible, but please RSVP for that as well if you need remote access
… most importantly, breaks and lunch are scheduled, but please suggest agenda items under the meeting schedule

Garth Conboy: https://docs.google.com/document/d/1Qe8Q8wMC1LKy_-JO-UCy8bFw4D4VN0si1Q5EPW9c-rY/edit#

Bill Kasdorf: I would suggest using Suggesting mode rather than Editing mode for agenda suggestions

Wendy Reid: quick update on the hotel—tomorrow I should be given a link that you can use to book at the Kobo group rate
… there are also good Airbnb options around the Kobo office (Liberty Village region)
… I’ll share the booking link as soon as I have it

4. deliverables for the TF-s

Tzviya Siegman: emails went out from Romain on WAM TF and Mateus on Affordances TF… both should have a lot of work to share and discuss by the F2F dates
… please consider joining those conversations

George Kerscher: North America has a time change next week.

Ivan Herman: question to bigbluehat–is there a request to set up a webex for the WAM TF?

Benjamin Young: not yet

5. Misc

Ivan Herman: I also created a new “proposed for closure” label that we can use to identify issues that can be closed without need for a meeting; we can use thumbs up/down or discuss in the issue itself

Tzviya Siegman: next week we will meet at 12:00 US EST - the time changes the US

Tzviya Siegman: Europe changes the clock a few weeks later

Tzviya Siegman: heads up for the change in time next week–does not affect US, but Europe will be an hour earlier

Hadrien Gardeur: Laurent has left

Tzviya Siegman: meeting will be 12 US EDT daylight time; Europe changes two weeks later

Garth Conboy: these details will be on the next agendas


6. Resolutions