16:38:58 RRSAgent has joined #dpub 16:38:58 logging to http://www.w3.org/2016/11/14-dpub-irc 16:39:00 RRSAgent, make logs public 16:39:00 Zakim has joined #dpub 16:39:02 Zakim, this will be dpub 16:39:02 ok, trackbot 16:39:03 Meeting: Digital Publishing Interest Group Teleconference 16:39:03 Date: 14 November 2016 16:39:09 Chair: Tzviya 16:41:32 Agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2016Nov/0012.html 16:41:42 ivan has changed the topic to: Agenda 2016-11-14: https://lists.w3.org/Archives/Public/public-digipub-ig/2016Nov/0012.html 16:42:55 Regrets: Leonard, George, Avneesh, Heather, Luc, Romain 16:50:27 liam has joined #dpub 16:57:08 present+ dauwhe 16:58:16 Present+ Ivan 16:59:04 present+ Tzviya 17:00:08 cmaden2 has joined #dpub 17:00:32 Florian has joined #dpub 17:00:55 clapierre has joined #DPUB 17:00:58 bjdmeest has joined #dpub 17:01:17 Garth has joined #dpub 17:01:24 Preesent+ Ben_De_Meester 17:01:27 Present+ Ben_De_Meester 17:01:31 Present+ Garth 17:01:50 present+ Chris_Maden 17:01:52 present+ Charles_LaPierre 17:02:29 present+ 17:02:56 Hadrien has joined #dpub 17:02:59 NickRuffilo has joined #dpub 17:03:08 scribenick: nickruffilo 17:03:21 pkra has joined #dpub 17:03:26 https://www.w3.org/2016/11/07-dpub-minutes.html 17:03:34 present+ Peter Krautzberger 17:03:39 Tzviya: "Any comments on last-week's meeting? OK - minutes approved." 17:04:00 http://w3c.github.io/dpub-pwp-ucr/index.html 17:04:19 Tzviya: "Next item, we have - at least for now - a final use-cases document - until we get comments... Link above." 17:05:26 ...: "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. " 17:05:36 q? 17:06:20 ..: "any comments before we move forward?" 17:06:39 Ivan: "Don't be shy - Reply!" ... "(to the items on GitHub, and comments)" 17:07:30 brady_duga has joined #dpub 17:07:31 https://rawgit.com/w3c/dpub-pwp/sync-with-ucr/TODO.md 17:07:43 present+ duga 17:07:53 q+ 17:07:56 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." 17:07:58 ack iv 17:08:49 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." 17:09:36 Ivan: "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." 17:10:29 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..." 17:10:32 q+ 17:10:36 http://github.com/w3c/dpub-pwp 17:10:38 that it? 17:10:59 s/that it?// 17:11:02 ack iv 17:11:48 Ivan: "There is a separate git-hub branch. Should it be merged with the main branch to avoid versions?" 17:11:58 Tzviya: "Fine with me." 17:12:53 https://rawgit.com/w3c/aria/dpub-cr/aria/dpub.html 17:14:14 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 17:14:14 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 concesus after this call..." 17:14:27 Ivan: "Easier and cleaner if by email..." 17:14:33 Tzviya: "Ok - i'll send after this call." 17:15:06 ...: "No to follow up on the last-week's demo on manifest and service workers. A number of links in the agend that Hadrien provided." 17:15:18 danielweck has joined #dpub 17:15:27 Hadrien: "Since I provided links - no need for screen share." 17:15:29 present+ 17:17:06 present+ 17:17:10 https://github.com/HadrienGardeur/webpub-manifest 17:17:12 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 17:17:12 . The design is mostly the same - because we worked on it together." 17:19:06 ...: "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 17:19:06 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." 17:19:16 liam has joined #dpub 17:19:45 present+ 17:19:46 ...: "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. " 17:21:54 live demo of Progressive enhancement: https://hadriengardeur.github.io/webpub-manifest/examples/progressive-enhancements/index.html 17:21:59 ...: "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 17:21:59 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, 17:21:59 media overlay, annotations..." 17:22:40 progressive enhancement code: https://github.com/HadrienGardeur/webpub-js 17:23:33 q? 17:24:36 liam has joined #dpub 17:24:49 ...: "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 17:24:49 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 17:24:50 - 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." 17:25:36 q+ to ask if H has considered web app manifest extensions 17:26:48 ...: "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 17:26:48 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 17:26:49 progressive enhancements. " 17:26:53 q+ 17:27:11 ack q 17:27:12 ...: "While browsers lack the ability to read these documents, this is a good intermediary." 17:27:18 ack tz 17:27:18 tzviya, you wanted to ask if H has considered web app manifest extensions 17:27:53 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?" 17:28:31 ack iv 17:28:35 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." 17:28:39 q+ to ask if, rather than HTTP headers or a JSON file, it couldn't be , and elements directly in the first of the HTML files. 17:28:41 q+ 17:30:55 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 releationship to the web manifest. At least 50% 17:30:55 of the issues are nto necessarily technical but an approach of reconciling the items of different partys. 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 17:30:56 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." 17:31:26 ...: "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." 17:32:11 q+ 17:32:43 q- 17:32:47 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. 17:32:47 It's very similar to what you see with an API documentation. It seems to hold with what I see in the API world." 17:32:55 ack Be 17:32:55 Bert, you wanted to ask if, rather than HTTP headers or a JSON file, it couldn't be , and elements directly in the first of the HTML files. 17:33:25 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?" 17:33:55 q? 17:33:58 [+1 to using HTML instead of JSON if it works, e.g. make it the TOC] 17:34:47 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." 17:34:52 q+ 17:34:54 ack da 17:35:09 q? 17:36:23 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 17:36:23 agreement on what information needs to be included." 17:37:18 ack ni 17:37:18 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." 17:37:26 q? 17:39:38 Tzviya: "If you could just tell me which links - i'll make sure they are in IRC." 17:40:04 Nick: "I think it's best if we don't overload what is in each document - manifest should remain itself." 17:40:23 Web Publication links: Code: https://github.com/HadrienGardeur/webpub-viewer 17:40:23 Live demo: https://hadriengardeur.github.io/webpub-manifest/examples/viewer/ 17:40:42 +1 to Nick's last. 17:40:43 laurentlemeur has joined #dpub 17:41:00 Regrets, I have to leave early. 17:41:05 pkra has left #dpub 17:42:47 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 17:42:47 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 17:42:48 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." 17:43:16 ...: "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." 17:43:21 Ivan: "Waht is the technical issue?" 17:44:52 https://chromium.googlesource.com/external/w3c/web-platform-tests/+/master/service-workers/cache-storage/window/sandboxed-iframes.https.html 17:45:21 q+ 17:45:30 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 17:45:30 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." 17:45:33 q? 17:45:54 q+ 17:45:56 ack iv 17:46:36 Ivan: "Is this a limitation somewhere in the specification - or is it a limitation in the implimentation." 17:46:55 Ivan: "these things are still in the making - so issues with specific use-cases should be raised and documented. " 17:46:57 file an issues https://github.com/w3c/ServiceWorker/issues 17:47:09 Hadrien: "It's true for service worker, but not for navigation." 17:47:19 ack br 17:49:06 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 17:49:06 app and your content, and you'll have to do work to solve it. It's hard because it should be." 17:49:07 q+ 17:50:02 Hadrien: "The first version does not inject JS, although the second one only inserts a small amount of JS. mainly for navigation." 17:50:03 ack ni 17:51:22 Nick: "Service workers could be used to chance content that was affected by CORS - but for location - not sure." 17:52:28 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?" 17:53:41 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 17:54:33 q? 17:54:39 q+ 17:55:06 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 17:55:06 . 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 17:55:07 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." 17:55:27 ack iv 17:55:29 Tzviya: "One other thing within the W3C - how can we contribute to the specs we are building off of." 17:56:46 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 17:56:46 webapp model - where the JS deploys with the publication itself." 17:56:47 q+ 17:58:25 ...: "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 17:58:25 they seem to underestimate the issues that our industry has. We'll have a 2nd wave of discussion starting tomorrow." 17:58:42 Hadrien: "Most of these exists as GitHub issues." 17:58:58 Tzviya: "Lets talk about next week quickly. Who's around?" 17:59:00 I'm around 17:59:37 will be available 18:01:34 Tzviya: "We will talk the 21st 18:01:38 q- 18:01:40 bye 18:01:44 cmaden2 has left #dpub 18:01:45 clapierre has left #dpub 18:02:10 rrsagent, draft minutes 18:02:10 I have made the request to generate http://www.w3.org/2016/11/14-dpub-minutes.html ivan 18:02:17 trackbot, end telcon 18:02:17 Zakim, list attendees 18:02:17 As of this point the attendees have been dauwhe, Ivan, Tzviya, Ben_De_Meester, Garth, Chris_Maden, Charles_LaPierre, astearns, Peter, Krautzberger, duga, danielweck, Bert, liam 18:02:25 RRSAgent, please draft minutes 18:02:25 I have made the request to generate http://www.w3.org/2016/11/14-dpub-minutes.html trackbot 18:02:26 RRSAgent, bye 18:02:26 I see no action items