WP rendering in non WP aware browsers

[avneeshsingh]

This concept would be attractive to different stake holders. I would like to put it forward from accessibility perspective.

I think that we are moving towards the world in which publications will be rendered by browsers natively, although we have not reached there yet.

The current approach still requires use of reading systems or a script embedded in the WP. The concerns are as follows:

• Looking at the experience in EPUB 3 world, EPUB 3 is mainly HTML content pages bundled with OPF. When the content is in HTML, it should work with browsers and many of these browsers already have good support for accessibility. But due to bundling we need to rely on n number of reading systems, and it is a massive task to ensure accessibility in such a huge list of reading systems. You can see the list of reading systems that we need to test on regular basis: http://www.epubtest.org/testsuite/accessibility/ ,and there are more that we need to start testing.
• The second approach of using scripts in publications or turning publication into its own reading system is scary from accessibility and usability perspective. It will be very very difficult to ensure accessibility in such a huge cluster of reading systems when each publication will carry its own reading system. And such scripts obviously raise security concerns.

I believe that we are quite close to having a publication that can be rendered by a browser. Two approaches that come to my mind are:

1. We have already touched upon some concepts in the direction of reading WP in non-WP aware browser for example placing TOC and PageList in entry page. I think we should leverage it to provide a WP that can be read in non-WP aware browser, and can be rendered in a much better way in WP aware user agent. One way to go is to develop a profile of WP that provides guidance for creating a WP for non-WP aware browser.

2. The other option is to develop some scripts that can be embedded in the publications, so that people use scripts developed by our WG instead of coming up with their own scripts that my not meet accessibility and usability requirements.

I am very much in favor of option 1. Because it provides a profile that can also be validated and is free from issues like security. Such a profile would provide great rendering in WP aware user agent, and would provide a basic interface in a non-WP aware browser. And because it is a profile, we do not need to make a major change in direction of the WP specifications.

I believe that such a profile will also be useful for reasons beyond accessibility, and our charter has provision of creating such a profile.

[BigBlueHat]

Great thoughts @avneeshsingh! I hope a profile isn't needed, however.

Non-WP aware browsers (i.e. all of them) should be usable now to experience a WP and without scripts. This could be made possible (as you noted) by simply requiring the ToC and/or PageList in the entry page. Requesting a publication address in a browser, then, would return something one could immediate use today to browse the publication.

Any scripts included would be focused on enhancing the existing in-browser reading experience and/or providing additional features such as offlining, searching, etc.

I'm new (sadly) to the accessibility space, but would this sort of change make WP's more accessible sooner?

[nruffilo]

Is it unreasonable to think of a server-side preprocessor or service that would be able to do this?

I'm not against having a fully linked TOC or something else that would let you navigate a document that was not WP aware - but what if basic nav and other features had to be added by a service provider - similar to how there are access controls provided by the web-server via apache or other web services.

I'm just thinking of ways that would make creating a WP as easy as possible. Plugins and server-side solutions will certainly spring up. The hope is you get at least one free/open source solution that allows the basics...

-Nick

On Thu, Aug 2, 2018 at 2:42 PM, BigBlueHat notifications@github.com wrote:

Great thoughts @avneeshsingh https://github.com/avneeshsingh! I hope a profile isn't needed, however.

Non-WP aware browsers (i.e. all of them) should be usable now to experience a WP and without scripts. This could be made possible (as you noted) by simply requiring the ToC and/or PageList in the entry page. Requesting a publication address in a browser, then, would return something one could immediate use today to browse the publication.

Any scripts included would be focused on enhancing the existing in-browser reading experience and/or providing additional features such as offlining, searching, etc.

I'm new (sadly) to the accessibility space, but would this sort of change make WP's more accessible sooner?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wpub/issues/271#issuecomment-410028149, or mute the thread https://github.com/notifications/unsubscribe-auth/ABM74ZJOnXBETlb0C4l2rTtU0GIrVGUjks5uM0gugaJpZM4VXgju .

--

• Nick Ruffilo @NickRuffilo Aer.io an INGRAM company

[TzviyaSiegman]

Thank you @avneeshsingh. I would love to see us take a progressive approach. How can a non-WP aware browser parse this effectively and accessibly? What needs to be added to make a browser WP-aware? How can we ensure that whatever needs to be added remains accessible?

[dauwhe]

The second approach of using scripts in publications or turning publication into its own reading system is scary from accessibility and usability perspective. It will be very very difficult to ensure accessibility in such a huge cluster of reading systems when each publication will carry its own reading system. And such scripts obviously raise security concerns.

Do you see problems beyond those already faced by the web? Essentially every web site uses scripting. Do we need to extend WAI-ARIA to deal with new situations created by web publications?

[avneeshsingh]

@dauwhe The difference is in the usage of the websites VS publications. Website surfing is mainly for getting some information while publication is used for extensive reading. For people with disabilities locating information on websites is an adventure. Even if a webpage is accessible, we need to use different techniques to locate the required information, because the information is structured in different way on different web pages. I am using screen readers since 2004, but still I sometimes need to use brain to quickly traverse a new webpage and find relevant information. And this becomes even a bigger issue for people with cognitive disabilities.

We can live with such an adventure on websites because we surf internet for getting some information. But if we have to face the same adventure for reading huge volume of text in textbooks, it would become an inefficient and exhausting experience. Further to it, the publications are also used by children in schools, who may not be as fluent with assistive technologies. Predictability of the user interface is essential when people with disabilities have to absorb huge volume of text from publications, so that the concentration remains on learning instead of finding out the way to operate the publications. Our experience in DAISY world informs us that people with disabilities keep on using the same model of DAISY book players for years and years, because of additional efforts required for learning new user interfaces.

[avneeshsingh]

@BigBlueHat It is possible to create a WP for non-WP aware browser by placing TOC and Page list in landing page. The profile is more of a guideline for creating such a publication in a proper way. It may not be normative specs, more of a set of guidelines. The purpose of putting these thought forward are:

1. To ensure that nothing in WP/PWP specifications blocks creating a WP for non-WP aware browsers, as the specifications evolve.
2. To develop a profile or set of guidelines for creating such a WP.

[avneeshsingh]

@TzviyaSiegman Indeed the plan mentioned by you is the ultimate objective. The approach proposed by me is the intermediate solution to facilitate people with disabilities till the ultimate objective is met.

[BigBlueHat]

To ensure that nothing in WP/PWP specifications blocks creating a WP for non-WP aware browsers, as the specifications evolve.

@avneeshsingh thank you for this conversation. I guess I'd like us to go a bit further and not make non-WP aware browser-friendly publications an afterthought, but rather make them the core of what we're building here. This is a Web specification after all. 😃

If we have to create a profile of the specification so that a WP may be created for a non-WP browser (i.e. all of them right now) to be able to render/read a WP, then we've failed.

[BigBlueHat]

@avneeshsingh here's a demo of a very slightly modified EPUB of Moby-Dick which is non-WP aware browser friendly: https://wileylabs.github.io/no-can-transclude/moby-dick-from-epub-samples/

It is not (by our current definition) a WP, but it is (by any other definition) a "web publication."

The changes I made were:

• rename nav.xhtml to index.xhtml
• add <script src="../dialog-reader.js"></script> to provide the "reading system"

The "reading system" only works in Chrome atm, but provides many of the experiences we've all been expecting for multi-document publications. Additionally, if you load the publication in Firefox, it still "just works"--though the experience is less "bookish" and more "web page-y."

Point being, that we can (if we want) spec something that builds up from where we are, can be progressively enhanced, and still be informative to non-Web-based reading systems (ala EPUB readers).

I'd be curious to know what this would need to be more accessible or to meet any other requirements you would have.

Cheers!

[avneeshsingh]

From reading experience point of view, it provides accessible reading experience on Chrome. The TOC, next and previous links also work fine. It would be good to have another link on each chapter which takes you back to entry page (that has TOC and pagelist). This will enable user to go to TOC anytime they need.

It would be great if this could also be achieved without use of script, because when we encourage people to create a reading system inside a publication then we get into the problems that I mentioned in my first post.

[GeorgeKerscher]

Agree with Avneesh. The TOC as the entry page is good, but the only way to get back to the TOC is to use the browser's bookmark feature. Also, page list would be good and essential in education.

[BigBlueHat]

The TOC, next and previous links also work fine. It would be good to have another link on each chapter which takes you back to entry page (that has TOC and pagelist). This will enable user to go to TOC anytime they need.

The page area outside of the <dialog> (i.e. the "backdrop") is click-able and removes the overlay/dialog showing the Table of Contents, but I'll add a specific link to make that more accessible. Thanks!

It would be great if this could also be achieved without use of script, because when we encourage people to create a reading system inside a publication then we get into the problems that I mentioned in my first post.

Agreed completely! The script is only there for the demo, but the "end game" would be browser support for this HTML binding document.

[BigBlueHat]

@avneeshsingh @GeorgeKerscher I've added a close link to the dialog reader with a title attribute of "Table of Contents": https://wileylabs.github.io/no-can-transclude/moby-dick-from-epub-samples/

Please let me know if that works for you, or if it needs more detail. Thanks!

My hope is to provide the shortest runway for an existing EPUB to be accessible (in all its meanings) on the Web via the fewest possible modifications. Easy peasy, right? 😃

[avneeshsingh]

Now 3 links are reported on a chapter: Next Close Previous

When I press "clos" link, Chrome returns to the TOC. So, the functionality is appropriate. A minor issue is that link says "Close" instead of "Table of Contents" or "TOC". But it is more of labeling thing and not a functionality issue.

[BigBlueHat]

A minor issue is that link says "Close" instead of "Table of Contents" or "TOC". But it is more of labeling thing and not a functionality issue.

Happy to change the labels as this is just a prototype anyhow.

Are there other things not currently offered in this demo that would be helpful to have from an accessibility perspective?

[avneeshsingh]

@BigBlueHat

"Are there other things not currently offered in this demo that would be helpful to have from an accessibility perspective?"

For demo purpose, it would be good to add a pagelist. The linking mechanism for pagelist is the same as TOC, but it would be good to have it in demo to emphasize this feature.

[TzviyaSiegman]

Issue summary What problem are you trying to solve? WPs might require special processing for all features to be usable, but they should be at least minimally usable and accessible when opened in a UA without special functionality. Beyond that, what needs to be added to make a browser WP-aware? How can we ensure that whatever needs to be added remains accessible?

What solution are you proposing? One proposed solution is using the TOC as entry page and links within each HTML document for next/previous/close. This is accessible and progressive.

Next steps Assess what progressive steps need to be taken to make a UA "WP-Aware"

[avneeshsingh]

Just one correction in minutes: captured statement: Avneesh Singh: offlining, accessibility, annotation, bookmarking, highlighting. these all go beyond today’s browsers

Actual statement: Avneesh Singh: packaging, offlining, accessibility enhancements like annotations, bookmarking, highlighting. these all go beyond today’s browsers. These can be identified from use case document.

With regards Avneesh From: Tzviya Sent: Monday, September 17, 2018 20:38 To: w3c/wpub Cc: Avneesh Singh ; Mention Subject: Re: [w3c/wpub] WP rendering in non WP aware browsers (#271)

Issue summary What problem are you trying to solve? WPs might require special processing for all features to be usable, but they should be at least minimally usable and accessible when opened in a UA without special functionality. Beyond that, what needs to be added to make a browser WP-aware? How can we ensure that whatever needs to be added remains accessible?

What solution are you proposing? One proposed solution is using the TOC as entry page and links within each HTML document for next/previous/close. This is accessible and progressive.

Next steps Assess what progressive steps need to be taken to make a UA "WP-Aware"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[BigBlueHat]

Sorry about that, @avneeshsingh! I was finding it hard to keep up with all the great things being said. 😃 I've posed the corrections in https://github.com/w3c/publ-wg/commit/99fa43914b6440313e0033c7c155dd30407b6b0f Cheers!

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions
  View the transcript

  Tzviya Siegman: Issue 271 - which we put off until we understood better what it means to be WP-aware as a user agent. Last week we decided to give us a week to wrap our heads around it
  Avneesh Singh: I proposed the concept only - but the consensus was that we should - we want a minimum viable WP that works on a non-WP aware user agent, and some additional functionality for a WP-aware user agent.
  … So we would need to make use cases that would be split into two buckets - WP-aware and non-WP-aware
  Ivan Herman: I’m not sure I fully understand the issue. If we have a non-WP-aware, then you see the landing page for the document, which will link to other important documents and parts of the document - and the user agent can do something with it. What else do we expect? Is it best-practices - to make the primary landing page to make sense to the browser (so having a table of contents)?
  … But from a browser side, i’m not sure what you expect
  Avneesh Singh: In a way, when we put TOC of page-list on the entry page, we are bypassing the manifest so things can be displayed. But - what is the functionality we want to work in the browser or reading system. For example, offlining or bookmarking - they could be added as a plugin. Or do we want more things in the minimum viable document.
  Ivan Herman: From my memory, the only thing still pending - and it’s a long discussion - is the fate of the title element, which is something that can be used to bypass the manifest and the manifest can make use of it if it’s WP-aware.
  … The page list, the TOC, and manifest are the things that could be picked up. Can we be more specific? I don’t know what the design principle is, but these are the only specific entries that I remember.
  Tzviya Siegman: I think this will come up in the discussion about boundaries - we have a 1-hour session to talk about boundaries, but we could probably talk all day
  Dave Cramer: We need to think about web publications as a progressive enhancements to web pages - we need to structure them so that all content is still available to a vanilla non-WP-aware browser.
  Luc Audrain: +1
  Ivan Herman: I understand, but I’m not sure what it means specifically as far as a spec goes - this is generic and general.
  Jeff Buehler: +1 Daves comment
  Matt Garrish: I wanted to +1 to Ivan. From an editing perspective and spec perspective, what are we hoping to achieve? This is authoring guidelines, not necessarily spec. What would happen if the user didn’t do these things? I don’t understand what we can spec out in this space. This seems best practices.
  Nick Ruffilo: +1
  Avneesh Singh: Ivan’s question is the main objective - we want to identify what we want to work in the reading system - for example, if we talk about page list, early the TOC was/were in the manifest, then we pushed it to the entry page, especially for accessibility reasons - you shouldn’t need a reading system…
  Benjamin Young: +1 to Avneesh
  Avneesh Singh: So are there more uses cases and features like this that need to also be non-WP-aware. Or things that are complex and need to move to the WP-aware section - and thats the objective.
  Brady Duga: I’m not sure how we solve this with best practices. Such as how do I make something display best in both WP-aware and non-WP-aware. So for non-WP-aware, I put a link to the next chapter, but I don’t want it installed in the WP-aware… That is the type of thing we can address in the spec, that I don’t think is addressed in best practices.
  … Thats one case where we would want different features/functionality in WP-aware and non-WP-aware.
  Dave Cramer: We can say things in the spec that give us some foundation - such as the TOC must appear in the main document, and the user can see the core of the publication despite the nature or core of the user agent. That sounds like a minimum standard. I want more time to think about brady’s proposal…
  Deborah Kaplan: I wanted to 100% agree with Brady, it is a place for the spec and not best practices - as soon as the chairs think we have the prerequisites for being a WP-aware browser, as soon as we have that, then coming up with what it does is solvable, but we have to put it in spec or we will have lots of aspirations and less results…
  Ivan Herman: 2 things - Administratively - I have the impression that having a design principle that we agree on, that would be good to have recorded as ourselves, but the specific issue should be close because that it doesn’t lead to something specific. For every feature we should look at it if it makes sense to determine if it should be interpreted by a non-WP-aware features…
  Ivan Herman: One thing Dave said is not true today. At the moment, the TOC is not required that it MUST be in the primary page. It can be - and may be advised to be, but it can be in any place, or a different file, or only linked from the manifest. This is one example where if we say MUST, we create a restriction. I am neutral but I don’t think this will get consensus.
  … lets not forget that the WP is the basis for EPUB4 in which this whole issue doesn’t come up. So this kind of restriction is unnecessary. We need to make sure we draw a line as to what is required and what is not.
  Tzviya Siegman: This is an important discussion, but is not the best time to have it.
  Ivan Herman: We do have a spec, and with the example of the TOC - we have to be careful that if we run in one direction, we have to back-pedal, which is never good.
  Tzviya Siegman: I just sent a message to Romain, to see if he proposed design principles in the past.
  Romain Deltour: https://github.com/w3c/wpub/wiki/General-Design-Principles
  Romain Deltour: (although I don’t think I was at the origin of that :-)
  Avneesh Singh: The original proposal is like a design principles about what goes into WP - if it’s important or useful, then it comes to the question of must/can. There is a possibility that we want flexibility about the TOC being in the manifest or entry page. This is why the proposal also mentions profiles, we may keep the flexibility of WP and create a profile that provides guidance for creating a WP that can be read in non-WP aware browser.
  Benjamin Young: I feel like there are two bugs in our approach that if we solve it will help. If we determine what user-agent web publications are for. With Web in the name, I assume browsers. 2) if we remove EPUB4 from the lineage, and say “we don’t know what EPUB4 looks like” then WP doesn’t need to pre-design itself as EPUB4
  … and ultimately EPUB4 would get addressed when it does, but for reading systems and likely also browsers. Having them backed up against each other is causing confusion.
  Ivan Herman: I think that’s exactly the problem why we need the discussion with the business group at TPAC. If we separate WPUB from EPUB4 - in some sense - then the questions from me - the purely technical guy - is whether this is something that makes sense for publishing. I am afraid the answer will not be positive. For me, WPUB is potentially the content for an EPUB4…
  … That my view of what can be implemented solves for the publishing industry. I do like the idea of profiling - which is a bit more formal way and more specific than the general best practices approach. If my profile is EPUB4, or “I don’t care about packaged” then we can make these distinctions about must/may
  … but I think we should keep both in mind. That way they both represent the industry
  Luc Audrain: The real issue is what you mean by separate. More precisely, what would make a difference that could not be reconcilable in a profile. EPUB4 is a profile of a web publication. In my feeling EPUB4 will be based on everything from the web publication but with constraints. We should be very careful about identifying something that would make a web publication not profileable
  Garth Conboy: I largely agree with Luc and Ivan. We had WP, PWP and EPUB4 and we dropped PWP out of the mix as EPUB4 would be the packaged version. I would come at this opposite from Ben in that I think the odds are that if we define EPUB4 sooner rather than later, it’s likely to get traction before WP unpackaged…
  Tzviya Siegman: https://docs.google.com/document/d/1Mt9PTcOdmrCwIsgfxbGMGjwHlUsySU01I0D4oBkSbcA/edit?usp=sharing
  Bill Kasdorf: +1 to Luc
  Tzviya Siegman: We have this as a discussion for TPAC. EPUB4 cannot come only a few months after EPUB 3.2 - even within a year, so we need to discuss who is likely to adapt and when. Lets take a look at the design principles and make sure those are what we’re applying
  … we need to figure out what that means - there’s lots of JSONLD, but in case of conflict, always consider the users, and we haven’t necessarily taking that into account.
  Bill Kasdorf: scholarly book publishers are doing EPUB
  Benjamin Young: I think Garth and I agree more than we disagree. If the major concern is EPUB, then WP as a name specifically would be best served in a community group of people who are not primarily using EPUB, and it be explored there for a lineage it doesn’t fit into.
  … I think we can overlap or merge, but lets not entangle WP and EPUB4…
  Bill Kasdorf: We need to be careful not to think of WP and EPUB as two distinct and separate things. As Luc said, EPUB 4 is a WP with constraints. It IS a WP, but a special kind of WP.
  

[mattgarrish]

Further to the comment I made yesterday, I still think we need to focus on implementable features that can enable publications that work regardless of user agent capabilities more than getting into best practices to do so within the specification.

Or to take up the example of links to the next page, what we probably need is a way of distinguishing any and all kinds of web site wrapper content so that it can be ignored (e.g., enclosing publication content in a main element as has been brought up before). But even such measures need to fit the web model (e.g., if a main element is detected ... otherwise present the full content of the body).

[HadrienGardeur]

I think we're taking the wrong approach with this issue. I see that some of us (@dauwhe and @BigBlueHat for example) keep repeating that basically putting everything (manifest, TOC, page list) in the entry page solves this issue. I'm sorry but I really don't think that's true.

For example, having the TOC in the entry page doesn't help with one of the most important affordance of a WP: reading sequentially resources from the reading order. If we only have a TOC in the entry page:

• we'll need to go constantly back and forth between resources from the reading order and the entry page
• the TOC might skip resources from the reading order

Instead of this approach (which I'll call the "everything in the entry page" approach), I think we should look back and define which progressive enhancements we'd like to work with non WP-aware browsers and prioritize them as well.

With the current requirements for an entry page, we already know that a non-WP aware UA will be able to reach the first resource in the reading order. From that point, we can list other affordances. My own prioritized take on this would be:

• being able to sequentially go through every resource in the reading order from the first to the last (without having to go back and forth in a separate document)
• saving my position in the reading order (which resource) and in the current resource (should work for HTML as well as timestamps for audio/video)
• having access to the TOC at all time (doesn't matter where I'm currently in the reading order)
• being able to use the publication offline

For each of those, we'll most likely require a mix of tweaks to the spec, best practices and polyfill.

[iherman]

There is another aspect that we seem to overlook at this discussion.

At this day and age there are less and less pages on the Web that would only rely on HTML+CSS. Try to switch javascript off in your browser and you will realize that the experience is way poorer than with javascript 'on'. To take one of our example, offlining of a document is done via service workers, but those are reachable exclusively via javascript. There is no declarative means that I know of to say "this should be offline". Just as we have to accept that publishing mathematics via MathML must go through the inclusion of MathJax, maybe the publishing of a Web Publication must go through some extra piece of javascript. The question is whether that programmatic piece is some standard library (like MathJax for MathML) or whether it has to be developed for each individual book separately; the goal is obviously the former. But, maybe, the time when a complex publication can be published without any javascript may be over...

I realize this raises (major) challenges, primarily in terms of accessibility. But maybe even accessibility may have to be addressed via some specific piece of software (do not ask me exactly how, I do not know...)

[avneeshsingh]

@iherman It is challenging if we intend to make large part of WP specifications readable with non-WP aware browser. But it is not so challenging if we work on concept of progressive enhancement. i.e. select the features of minimum viable WP that can be read in non-WP aware user agent, and use reading systems or scripts for other features. Infact some accessibility needs on non-WP UA are already met by allowing TOC and Pagelist in entry page, and it is possible to meet some more requirements also. And for rest of the rquirements, we can rely on Java Scripts, Reading systems etc.

[iherman]

@avneeshsingh I do not think we disagree, but I just want to be precise. When we talk about "non WP-aware browser" do we still allow providing polyfills or other javascript based extensions or not? Because if not, that this means that a minimal viable WP MUST NOT use MathML for mathematics, because it cannot be displayed on most (and for some level of mathematics, none) of the browsers... Do we want to go that far?

[avneeshsingh]

@iherman Indeed, we are on the same page regarding the concept. Coming to specifics, MathML is not something specific to WP, it is a part of usual web sites. I believe that for selecting non-WP UA vs WP aware UA features we should consider the items that are specific to WP for example sharable bookmarks, cover images, offlining etc.

[HadrienGardeur]

To further illustrate my point from https://github.com/w3c/wpub/issues/271#issuecomment-430203720 here's how things are currently implemented in the audiobook example:

being able to sequentially go through every resource in the reading order from the first to the last (without having to go back and forth in a separate document)

An <audio> element is used, once a specific audio resource is finished, JS loads the manifest and replaces the src attribute of the <audio> element with the next resource in the reading order.

Controls are also available to skip to the previous/next audio resource in the reading order, both are also using JS behind the scene.

saving my position in the reading order (which resource) and in the current resource (should work for HTML as well as timestamps for audio/video)

This is handled using JS and LocalStorage APIs. Every 10 seconds, the resource (URI) and a timestamp (expressed in seconds) are saved. If you close the UA and re-open the same URI, JS checks for a saved position and restores your current position if available.

having access to the TOC at all time (doesn't matter where I'm currently in the reading order)

I didn't cover that one because it's still unclear what UAs will be able to do with the TOC.

There's a link in the manifest as well as a link on the entry page.

We could go beyond once we've further discussed the TOC at TPAC and either:

• parse and display differently the content of the TOC
• open the TOC in an iframe or a modal view next to the audio controls

being able to use the publication offline

For audio, I couldn't find a good fit. Service Workers can't handle range requests in HTTP very well (necessary for the <audio> element to work properly) and audio resources are too large to be cached, even on such a basic example (most audiobooks are much longer and larger).

It's not pefect but all of this works currently in a non-WP aware UA. A WP-aware UA would just skip the entry page entirely and its associated JS and use its own UI for audiobooks instead (with potentially more affordances available, including offline reading). None of these affordances required having an embedded manifest or TOC on the entry page.

[avneeshsingh]

It is nice to see the implementation details of audio WP. Looking from content point of view, it is quite possible to have the following minimum functionality available in non-WP aware user agent, even if java script is not available. -Ability to display title and duration of the book to the user.

• Ability to play chapters defined in the book one after the other. It may not include end to end continuous reading of the book, but user should at least be able to play one chapter at a time and then play the next chapter.
• Ability to navigate to a chapter defined in the book and start playback from there.
• Ability to pause and resume.
• Ability to start playing from a page number or a time point defined in the book.
• Ability to forward and rewind by some time interval.

This is an example of minimum functionality that we can get in non-WP aware user agents, that I mentioned in the call. And we can extend this minimum functionality to features like continuous end to end playback by using java script. And WP aware browser can further enhance it by providing features like offlining, enhanced UI for TOC etc.

[iherman]

@avneeshsingh you are more familiar with what browsers can do with audio today. But are you sure all these can be achieved by browsers today without any additional, specialized javascript? I am thinking of, e.g., save the playback point and resume from there, for example.

(I would be happy if your answer was 'yes!' :-)

[avneeshsingh]

@iherman The list is mainly to show the concept, it is not a finalized list. Regarding play and pause, audio element provide controls for achieving it. But, it is a detail that we can revisit when we are finalizing the list of features.

I realized that your comment was regarding saving, closing and reopening. I removed it from list. I placed it in audio TF use cases for invoking discussion in group, if someone has ideas for making it happen. But it may be distracting item on this thread.