See also: IRC log
<bjdmeest> Preesent+ Ben_De_Meester
<scribe> scribenick: nickruffilo
<tzviya> https://www.w3.org/2016/11/07-dpub-minutes.html
Tzviya: "Any comments on last-week's meeting? OK - minutes approved."
<tzviya> http://w3c.github.io/dpub-pwp-ucr/index.html
Tzviya: "Next item, we have - at least for now - a final
use-cases document - until we get comments... Link above."
...: "There were some people in this group that will be adding comments,
and others, but if there are others you want to solicit feedback from -
please let them know. "
..: "any comments before we move forward?"
Ivan: "Don't be shy - Reply!" ... "(to the items on GitHub, and comments)"
<tzviya> https://rawgit.com/w3c/dpub-pwp/sync-with-ucr/TODO.md
Tzviya: "This is just the beginning to yet another document - the original PWP document. That started as "epub-web" and has evolved a few times. The current iteration is PWP - something along those lines. Ivan has taken a stab at editing it. We have a revised TOC - please take a look at it. This is the direction that this document is headed in - and we'd like to hear your thoughts on it."
Ivan: "What I will do if you agree on the overall structure
is that I will make a first re-ordering as if the documents were to be
done from scratch and then there may be areas where i will need further
input. I don't want to be the only person writing this."
... "I am away this week - so i can't do too much this week. If someone
wants to use this week to work on things - that'd be great."
Tzviya: "Your assignment for next week - please take a look and comment - GitHub or email for comments. please post a link in chat to it..."
<bigbluehat> http://github.com/w3c/dpub-pwp
Ivan: "There is a separate git-hub branch. Should it be merged with the main branch to avoid versions?"
Tzviya: "Fine with me."
<tzviya> https://rawgit.com/w3c/aria/dpub-cr/aria/dpub.html
Tzviya: "we'll revisit next week. Thank you Ivan - next item, we need to have a call for consensus for the DPUB ARIA document. Leonard asked we do this over email. You've all seen this document several times - about why one particular role was lacking - why there was no title role. If you want to learn more, I'll send you a link to the IDPF email list. We had this discussion a year ago, but
if you have any significant concerns, open up int he ARIA github tracker. Since we've discussed this several times - i don't see any concerns. I'll send out the call for consensus after this call..."
Ivan: "Easier and cleaner if by email..."
Tzviya: "Ok - i'll send after this call."
Hadrien: "Since I provided links - no need for screen share."
<tzviya> https://github.com/HadrienGardeur/webpub-manifest
Hadrien: "The number of months - i've been working with Dave on this project. Initially this project started for the both of us within the efforts to create a browser friendly format for epub 3.1 -> the main difference between the first manifest, dave probably showed - and in his examples, it was a spine and resources. More of a webapp manifest. For this , it's meant to be a separate document. The design is mostly the same - because we worked on it together."
...: "The idea is to have a manifest that provides a number of information & metadata. And then a context document that provides information as to how things work. Only one link is required - the self link - also the 'canonical link' to the publication. We then have collections - the spine is one. The spine is resources orded by a reading order. the HTML resources as you go through a publication. As you go through one resource, you move to the next. The resources are a seperate collection - items useful to render the publication, but not part of the reading order. Such as images, CSS, fonts, etc."...: "Basically metadata and 3 collections. The collections all use the same way to define a link, HREF, media type, and some slightly more advanced things like a URI template - so you can provide a number of services, search, annotation. "
<tzviya> live demo of Progressive enhancement: https://hadriengardeur.github.io/webpub-manifest/examples/progressive-enhancements/index.html
...: "All the prototypes I've built are using this document/manifest.
Since this was started as an epub 3.1 project, the goal was to have
something fully round-trip-able. So it's fairly feature complete with a
few exceptions - there are a number of events/features in epub that are
a bit complex and not covered by this. This document i've created a few
examples/prototypes. The first is a prototype for progressive
enhancements. A majority of publications on the web fall into this
use-case. Each resource is accessible through a URI and either the
browser or the JS embedded in those resources are responsible for a
number of enhancements. Those could cover moving from one resource to
another. It could also cover pagination, displaying some styles
associated to a publication, media overlay, annotations..."
<tzviya> progressive enhancement code: https://github.com/HadrienGardeur/webpub-js
...: "Handled by the browser or JS. The only thing that publication
needs to indicate - in addition to the JS for progressive enhancements,
is a link to the manifest. The first way is to ahve a simple link
element in the header of the HTML rel='manifest' it detects that it is a
manifest and also the media type. That is one way to discover this web
publication manifest in JSON. The other way would be HTTP headers. Those
would be the two most obvious ways to discover. The other thing that is
supported - is that it's also possible to provide a link to the web-app
manifest. You can also provide a publication key - which would point to
the location of the web publication. The reason I did that - is after
looking at the web-app manifest spec, there were a few elements we could
reuse the title, some metata, but most of what is specified in the
web-app manifest is either not relevant or not sufficiently complex in
what can be expressed. For example, the metadata available is much more
simplified."
...: "The other reason for that is that we could also have situations
where the progressive enhancements itself can be done by the webapp and
the document itself does not need to support any JS. So if your browser
can support web publications, then you don't need to include antyhing.
But if you're using something that does not, you can use the web-app
manifest. It's one approach, not necessarily good or bad, but a
different approach. This simple example does a few things. Once it has
discovered the manfiest, it caches the resources - using a service
worker. Then it injects a very basic navigation - at the bottom of the
page, with next elements. It's very minimal in what it does, but a very
simple way to enhance. A link to the manifest and then the JS. And it
could do a list of progressive enhancements. "
...: "While browsers lack the ability to read these documents, this is a
good intermediary."
<Zakim> tzviya, you wanted to ask if H has considered web app manifest extensions
Tzviya: "I was wondering - you mentioned you were concerned that web-app manifest was too-limited or too-robust in the specific metadata. Have you considered that you don't need to include items? And that it was meant to be extensible?"
Hadrien: "Most are not really relevant. it is extensible, but lacks a good extension model. There is no clearly defined extension mechanism. The extension model is very weak - as it doesn't say expressly how they should be handled."
Ivan: "I would pick up on the manifest issue, as it will
become one of the main discussions as we get closer. Your argument that
the reader/application compared to the document itself is very
compelling. That's an argument we should store because it will come
back. It's actually raises another question - but let me come back to
that later. The relationship to the web manifest. At least 50% of the
issues are not necessarily technical but an approach of reconciling the
items of different parties. Whether you link to a manifest or the
document, they are more-or-less identical things. Would we get an easier
deployment with browsers if we do a web-app manifest first. Then we add
to that the discussion we had a few months ago showing that the web-app
manifest is being developed but not finalized. So the problem with the
extensions can possibly be pushed back and signal to the web-app
manifest people that we need extensions and it's crucial."
...: "These are discussions we have to have at some point - there may be
some consensus building. The other thing may be different in your other
app - so i'll come back later."
Hadrien: "You're right - the proposed extension mechanism here, there are multiple models for that. One is collections identified by role - another model is the fact that it relies on JSON LD - so it's a pretty strong model for extending metadata. It's also possible that since the manifest heavily relies on the LINK method - you get extensions through the use of Media Types and REL values. It's very similar to what you see with an API documentation. It seems to hold with what I see in the API world."
Bert: "I was wondering if - instead of linking to JSON file - why not put it in the HTML file? Why not do-away with the manifest file?"
<liam> [+1 to using HTML instead of JSON if it works, e.g. make it the TOC]
Hadrien: "It has been considered, but you want to be able to link to the manifest from every resource. I want to be able to link - which avoids duplication, and it allows the manifest to be 100% JSON and not mixed with HTML. It has been discussed before."
Dave: "I just wanted to mention that there are some useful features for web-application manifest that we can carry over. The ability to save to homescreen for certain types of books. It provides a way to deal with icons. I think the display mode information. The general philosophy is to build on things that already exist. The same information in the same format. I think we have a lot of agreement on what information needs to be included."
Hadrien: "When you're using a JS viewer with an iframe - that would be the first. The first resource of a publication might be the cover page. There is value in those being separate. Not saying they aren't useful, but I don't think you can replace one with the other."
Tzviya: "If you could just tell me which links - i'll make sure they are in IRC."
Nick: "I think it's best if we don't overload what is in each document - manifest should remain itself."
<tzviya> Web Publication links: Code: https://github.com/HadrienGardeur/webpub-viewer
<tzviya> Live demo: https://hadriengardeur.github.io/webpub-manifest/examples/viewer/
<Garth> +1 to Nick's last.
<pkra> Regrets, I have to leave early.
Hadrien: "The second one is similar to what Dave showed
last week. The idea is - what can I do if I cannot - for whatever reason
- inject JS into the web publication. The idea here is building a very
simple JS application that displays the content of a web-publication in
an iFrmae. It uses the same manifest, so there is a way to define what
the manifest is as a parameter of the URi. Based on the resources in the
manifest, it will cache what is necessary, and determine reading orders.
It was interesting to see what works and doesn't work with services
workers. Initially I started working on a prototype - if I use a sandbox
iFrame, then everything cached in your service worker will be ignored by
the browser. Using a sandbox - which would be a good thing - it has a
big impact, as Service Workers do not work. I know it's something
Leonard has noted before. It's a bit problematic for the web-app
use-case."
...: "Instead of a situation where you're browsing the web, see a
publication, and read it. The web-app use-case is that you have a bunch
of books and want to read them all in a web-app."
Ivan: "What is the technical issue?"
Hadrien: "If you're using a sandbox iframe, the service workers cannot access the cache, so it cannot serve up the content. That's the biggest issue i've encountered with that prototype. Another issue - in a traditional reading system we want to keep track of where the user is - the problem with an iframe is that if the web-app and on a different domain, due to CORS, the page cannot determine what is happening within the IFRAME. The app cannot update the next/previous button. As soon as you start using inline navigation or JS links - if you're on different domains (which would be useful) you lose control and don't know where the reader is. That use-case is interesting, but it could be that i cannot figure out a way to do it."
Ivan: "Is this a limitation somewhere in the specification
- or is it a limitation in the implementation."
... "these things are still in the making - so issues with specific
use-cases should be raised and documented. "
<tzviya> file an issues https://github.com/w3c/ServiceWorker/issues
Hadrien: "It's true for service worker, but not for navigation."
Brady: "These are issues - but these are issues we have today. it's a PITA but we can do it. One frame with communication, the other frame uses display. Sure - all navigation is through POST, it breaks Javascript, etc. But there is a workaround. Not certain it's optimal, but it doesn't seem like service workers are adding... that doesn't seem to be the problem. You have 2 domains - your app and your content, and you'll have to do work to solve it. It's hard because it should be."
Hadrien: "The first version does not inject JS, although the second one only inserts a small amount of JS. mainly for navigation."
Nick: "Service workers could be used to chance content that was affected by CORS - but for location - not sure."
tzviya: "Hadrien - are you trying to solve an issue of Epub 3.1 for web - or. One of the fundamental issues is trying to show what can be done today? With the demonstration Dave did, it was 'this might work or be helpful in a few months'? Is that an accurate description?"
<danielweck> Re. SW + sandboxed iframe, also see (I posted another link above): https://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/serviceworker/chromium/sandboxed-iframe-fetch-event.html
Hadrien: "I'm not just finding what does and does not work - it started as 'what can we do to put epub on the web' As we've worked on it, it was 'how can we make epub better' By building prototypes, I've learned alot about service workers, and what is relevant to other projects - such as readium. Building such prototypes is useful to learn - not just about limits - but about creative solutions. There are many places where I did things different from Dave - such as metadata. One thing I've been testing is building something specifically for comics and audiobooks. i believe there are value in having comics & audiobooks. IDPF hasn't really worked on them. There are people very interested in doing more for these two types of books. That was actually easier to do. There are multiple goals - what can we do to make a better version of epub, and what can we learn, not just for epub, but for readium, pagination, etc. The 3rd goal - what can we do for publication types that have largely been ignored."
Tzviya: "One other thing within the W3C - how can we contribute to the specs we are building off of."
Ivan: "There is one big choice to be made - and this is whether the javascript that does the heavy lifting - is it something deployed as part of the publication, or external to a publication. Dave did the latter, and it seems there are some major technical difficulties. It's also true that some of the discussion on GitHub seems to indicate that the choice of the web-developer crowd is more the webapp model - where the JS deploys with the publication itself."
...: "For publishers to be forced to include a JS with a publication - would be a hurdle. So the issue will come back to haunt us. I would love to see something else. We should contact the web service workers and let them know whenever we see issues. Many people in that community take our plans and work with web publication people. They understand something needs to be done there, although they seem to underestimate the issues that our industry has. We'll have a 2nd wave of discussion starting tomorrow."
Hadrien: "Most of these exists as GitHub issues."
Tzviya: "Lets talk about next week quickly. Who's around?"
<dauwhe> I'm around
<astearns> will be available
Tzviya: "We will talk the 21st
bye