WP rendering in non WP aware browsers #271
Comments
|
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? |
|
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 ***@***.***> 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
<#271 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABM74ZJOnXBETlb0C4l2rTtU0GIrVGUjks5uM0gugaJpZM4VXgju>
.
--
- Nick Ruffilo
@NickRuffilo
Aer.io an *INGRAM* company
|
|
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? |
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? |
|
@dauwhe 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. |
|
@BigBlueHat
|
|
@TzviyaSiegman |
@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. |
|
@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:
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! |
|
From reading experience point of view, it provides accessible reading experience on Chrome. 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. |
|
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. |
The page area outside of the
Agreed completely! The script is only there for the demo, but the "end game" would be browser support for this HTML binding document. |
|
@avneeshsingh @GeorgeKerscher I've added a 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? 😃 |
|
Now 3 links are reported on a chapter: When I press "clos" link, Chrome returns to the TOC. So, the functionality is appropriate. |
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? |
|
"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. |
|
Issue summary What solution are you proposing? Next steps |
|
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.
|
|
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 w3c/publ-wg@99fa439 Cheers! |
|
This issue was discussed in a meeting.
View the transcriptTzviya 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 itAvneesh 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. |
|
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 |
|
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.
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:
For each of those, we'll most likely require a mix of tweaks to the spec, best practices and polyfill. |
|
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...) |
|
@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? |
|
@iherman |
|
To further illustrate my point from #271 (comment) here's how things are currently implemented in the audiobook example:
An Controls are also available to skip to the previous/next audio resource in the reading order, both are also using JS behind the scene.
This is handled using JS and LocalStorage APIs. Every 10 seconds, the resource (URI) and a timestamp (expressed in seconds) are saved.
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:
For audio, I couldn't find a good fit. Service Workers can't handle range requests in HTTP very well (necessary for the 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). |
|
It is nice to see the implementation details of audio WP.
This is an example of minimum functionality that we can get in non-WP aware user agents, that I mentioned in the call. |
|
@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!' :-) |
|
@iherman 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. |
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:
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:
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.
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.
The text was updated successfully, but these errors were encountered: