Skip to content
This repository has been archived by the owner on Apr 26, 2022. It is now read-only.

Maintaining EPUB 3.X: Versioning, Dating, Living Standards, etc. #97

Open
dauwhe opened this issue Aug 7, 2019 · 4 comments
Open

Maintaining EPUB 3.X: Versioning, Dating, Living Standards, etc. #97

dauwhe opened this issue Aug 7, 2019 · 4 comments

Comments

@dauwhe
Copy link
Contributor

dauwhe commented Aug 7, 2019

The very mention of the phrase "living standard" has raised some eyebrows. How best can we maintain EPUB 3.X? Is it helpful to anyone to keep creating new versions of EPUB? And, most importantly, can we take any steps closer to our original goal, where the spec represents a contract between the content author and the reading system, an assurance that if your content follows the spec the reading system will render according to the spec.

Let's look at an example. The biggest recent question has been about spine order vs nav order. What happens if we decide to relax this restriction in the spec? Do we have to publish EPUB 3.2.1 or something, even though the change will not affect any existing EPUB or any reading system?

Actual EPUBs are not strictly tied to versions. Most of what my employer produces probably validates as EPUB 3.0, EPUB 3.0.1, and EPUB 3.2. But what if I embed a WOFF 2.0 font in my EPUB? That would be invalid in 3.0.1 but valid in 3.2. That still doesn't tell us if the underlying rendering engine supports WOFF 2. CSS, of course, is designed to fall back gracefully if it sees a font format it doesn't understand. MathML is another example. Can I actually use it in my EPUB? Maybe.

To be continued…

@artbyrt
Copy link
Collaborator

artbyrt commented Aug 7, 2019 via email

@laudrain
Copy link
Collaborator

laudrain commented Aug 7, 2019 via email

@dauwhe
Copy link
Contributor Author

dauwhe commented Aug 7, 2019

There is a lot to do, like for instance in accessibility where “born accessible EPUBs” are not rendered properly to VIP.

What does "VIP" mean in this context?

@mattgarrish
Copy link
Member

VIP = visually impaired persons.

On a practical level, in a world with dozens and dozens of "reading systems", how many implementations do you need before you can really consider a feature supported? What market share qualifies? In whose region?

The one concern I have with a "living" standard is that without revisions the decision making process may get watered down. There's always been a noticeable uptick in participation in the past when we've focused people on completing a revision and had a set timeline to get things done. If we just expect people to stay constantly tuned in to every change we likely won't get the same attention to what's going on.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants