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
- Resolution #1: last week’s minutes approved