EPUB 3 Community Group Telecon -- 23 Jan 2020

scribe+

dauwhe: do we have anyone new who would like to introduce themselves?

WayneD: Hi I'm Wayne Dick, first off I'm mainly a user
... I love EPUB
... it's made reading so wonderful so I wanted to be a part of this committee
... I've worked with the w3c since around 2000 in accessibility
... I'm a mathematician and understand science books
... consulted with Pearson for a long time
... coordinated accessibility initiative with Cal State U for a while

dauwhe: Welcome!
... anyone else?

George: Wayne has contributed a whole lot to low-vision users and complained a lot about reading systems that force you to pan around
... he spot the problems in our spec with that

dauwhe: Our topic for today is to continue discussing the draft charter

<dauwhe> https://docs.google.com/document/d/1CTwQIhmsyXh0tpS6RLmLLeGDkO5JKHV1FdaXoh3CdXI/edit#

dauwhe: we did the first half last week
... today we focus on deliverables
... thanks to everyone for commenting
... I have been answering some comments this morning
... let's go through

Deliverables

dauwhe: Let's discuss

garth: I guess I should start with the first sentence
... I don't know if it was one of the goals of WP
... We know what happened there
... I don't think alignment with the web platform for the sake of alignment is a main goal
... it would be a result of other goals
... the survey will help with this
... I would rather focus on addressing industry needs

dauwhe: I would mention that this has been a goal for a long time
... lack of alignment has made it difficult to implement
... many of the complaints about EPUB are things like "I can do this in a browser but not in EPUB"
... it's one of the biggest challenges
... it's possibly more about implementation than the spec, but I think it's a good goal

<George> wendyreid: q

garth: I don't really disagree with what you said
... we did get in trouble when we invented things from whole cloth
... I would like to see this resolved by addressing industry needs by improving alignment with the web platform
... I don't see it as primary
... an implementation strategy
... if we look further in the spec, we've stated that new serializations are out of scope
... we are concerned with compatibility
... we should focus on industry need and then alignment

Avneesh: I feel that web alignment is quite broad as a goal
... what does it mean? We could replace it with more specific goals
... which may help get people on board
... does it mean getting EPUB into the browser or more

dauwhe: I will try to work on that
... I think that looking at the EPUB Content Document spec itself, we have all these things "we support MathML" but this bit and not that
... we interpret this a certain way
... I would like to see this get smaller, fewer exceptions
... fewer landmines for those who want to use web technologies in EPUB
... to Garth, addressing industry needs is key
... but perhaps not specific enough
... maybe if we convert them to goal statements
... any other thoughts?

George: My question was the same as Avneesh 's are we talking about including HTML and not just XHTML

dauwhe: Yes, thats in the bullet list in the next section
... we've been talking about it for a long time
... I've certainly seen it discussed
... it creates friction
... its making author's lives more difficult for the convenience of existing implementations

<CharlesL> +1

dauwhe: I would like to discuss changing it

garth: There's been various opinions on this
... there's some redrafting to do
... EPUB3.Next will be strongly backward compatible
... does that fight with allowing HTML serialization

dauwhe: We make the tent bigger not smaller
... existing EPUB3.2 would be valid EPUB3.next
... but all EPUB3.next may not be EPUB3.2
... this was changed based on feedback from Romain and others
... I am concerned that maybe are technically valid but not implemented
... I don't want to demand that we retain compatibility will all of the satellite specs
... especially ones with little or no implementation

<Avneesh> +1 Dave, objective is backward compatibility with EPUB 3 eco system

dauwhe: any comments on backwards comaptibility?
... We can move on

<Dale> It should follow current web standards

dauwhe: I have some broader categories for ideas
... HTML serialization
... epub:type and ARIA roles
... semantic enhancements
... can't use epub:type in HTML serialization
... a long history of uncertainty with scripting and local storage
... the continuing evolution of new media types
... there's a lot there

<Dale> What are readers doing currently?

dauwhe: any comments or questions?

Dale: I am wondering: we can specify something, getting a vendor to implement is another thing entirely
... what are the current vendors are doing?
... amazon has it's own way, EPUB has its
... for the readers that are EPUB compatible, what are they using

dauwhe: to the best of my knowledge, epub:type is to enable pop-up footnotes
... a lot of people use them for internal workflows
... not exposed to end users

Bill_Kasdorf: Should we say all the HTML serializations, not just HTML5
... just say HTML since it is the spec

dauwhe: I want to refer to the current best practice

<dauwhe> we

<garth> Wendy: Kobo dosn’t use epub:type too much, beyond footnote pop-ups

<garth> … Need better documentation on what should be done with such metadata

<Bill_Kasdorf> To clarify, I don't mean all past HTML serializations, I mean "HTML" as the now-current spec.

<garth> … could explain the lack of adoption.

<garth> dkaplan: Re HTML5/HTML — should follow best practices. Maybe tie to a time?

scribe+ garth

<garth> … Living standard issues.

<garth> … version tie-in issues.

<garth> dauwhe: Post EPUB the whole WhatWG thing happened, and we need to update

<garth> mgarrish: Need to move to WhatWG version. Hands tied. Current ref is non-specific.

<garth> … epub:type problem comes back to Nav Doc — will be interesting.

<garth> CharlesL: Footnotes w/ epub:type — could doc-footnote be used?

<garth> wendyreid: Currently using only epub:type — plus some heuristics.

<garth> … likely need to support for backward compatibility.

<garth> mgarrish: Be careful not to overload ARIA roles and do it in a web-friendly way.

<garth> dauwhe: These pop-ups aren’t really part of the spec at this point.

<garth> wendyreid: Agree. Features may have leveraged stuff in the spec to implement features (pop-ups, running headers/footers)

<garth> … but aren’t really speced. Maybe that should be part of our mission — spec-ing said behavior.

<garth> dauwhe: Like that idea.

<garth> scibenic Garth

<garth> duga: For EPUB foot-notes are really divering from the Web platform — in this case, a good thing.

<garth> dauwhe: Maybe we can drag the Web to the declarative path.

<garth> duga: Not clear that will — browser folks will happen just say “write JS."

<garth> WayneD: A11Y section; I don’t use Reader where possible; just strip out content and read in browser.

<garth> … most folks can effectively do that.

<garth> s/cancan’t’t/

<garth> … EPUB being close to the Web is the way I read.

<garth> … Need to depart early today. Thanks!

<garth> Avneesh: I read the name way. Sometimes RS’ actually reduce A11Y.

<garth> George: Understand those comments. Test first in browser; if it won’t won’t there it would work in RS’.

<garth> … Normal students won’t do such gymnastics.

<garth> … Need to be able to read in RS’.

<garth> … Long form is generally more optimal (e.g., Nav) in an RS.

<garth> dauwhe: A11Y; new versiosn of specs; are these reasonable goals?

<garth> Avneesh: Need new version of EPUB A11Y doc. Discussions ongoing.

<garth> … More documents coming. Deliverables in Doc are on track.

<garth> gpellegrino: Should have Doc for assistive technology developers.

<dkaplan3> not just for blind people, gpellegrino! also for other AT users.

<gpellegrino> right dkaplan3, thanks!

<Dale> How do get on the speaker queue? I raised my hand in Zoom.

<garth> Avneesh: One of pieces; unclear how it will shape up. ARIA role behavior being spec-ed for RS’ is an issue.

<garth> Dale: Should the details of codification be defined in the Charter? Should it be more detailed?

<garth> dauwhe: Charter should be broad outline of what the CG should work on.

<garth> … To-do list for next two years.

<garth> dauwhe: Codification could be an area we expect to work on, and be in the Charter.

<dauwhe> https://www.w3.org/publishing/epub3/

<garth> … but not the detail.

<garth> Dale: How EPUB RS uses a feature versus how an A11Y RS may behave, may conflict.

<garth> dkaplan: An EPUB RS SHOULD follow ARIA (not just A11Y RS’). No divergence.

<mgarrish> q

<garth> … There is some confusion around expectations of behaviors of ARIA roles.

<garth> Dale: An ARIA role of “chapter” — would that be different for EPUB RS versus a A11Y focused RS.

<garth> dkaplan: Spec drives how/where metadata is applied, but less so behavior.

<garth> mgarrish: ARIA aspect is well defined.

<garth> … We can provide guidelines for how such roles are authored.

<garth> dauwhe: AAMs are out of scope for EPUB?

<garth> mgarrish: Yes.

<garth> dauwhe: Any other comments?

<garth> … (on A11Y deliverables)

<garth> … Spec Quality — make it easier to find RS conformance statements.

<garth> … may be somewhat underspecified in RS behavior.

<garth> … Could be tied to more RS-focused tests.

<garth> … Maybe we’re done?

<garth> George: Agree on better expectations for RS’.

<garth> … Publishing CG and BG should be considered by us and should be in scope, right?

<garth> dauwhe: Right!\

<garth> s.\..

<dauwhe> RRSAgent: draft minutes

<garth> … Please keep commenting.

<dauwhe> RRSAgent: draft minutes

- DRAFT -

EPUB 3 Community Group Telecon

23 Jan 2020

Attendees

Contents

Deliverables

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output