Digital Publishing Interest Group Teleconference

23 May 2016



Karen Myers, Ayla Stein, Luc Audrain, Markus Gylling (mgylling), Dave Cramer (dauwhe), Charles LaPierre, Brady Duga, Heather Flanagan, Ivan Herman, Ben De Meester, Alan Stearns (astearns), Nick Ruffilo (Nickruffilo), Tzviya Siegman, Bert Bos, Bill Kasdorf, Vlad, Romain Deltour (rdeltour), Tim Cole, Peter Krautzberger, Chris Maden, Deborah Kaplan, Shane McCarron (ShaneM), Liam Quin
Charles McCathieNeville (chaals)
Nick Barreto
Markus, Tzviya
Nick Ruffilo, Karen


  1. Topics
    1. IDPF/W3C Plans
    2. Web Platform WG topics
      1. Packaging and manifests
      2. Service workers
      3. HTML Extensions, Custom Elements (e.g., <h> element)
  2. Summary of Action Items
  3. Summary of Resolutions

Markus: "Approving the last minutes?"

<mgylling> https://www.w3.org/2016/05/02-dpub-minutes.html

Markus: Previous meeting minutes, which was may 2nd - long time ago..."
... "Comments or objections? Otherwise approved... OK - minutes approved."
...: "Two topics - 2nd with second guest - Charles McCathieNeville


IDPF/W3C Plans

Markus: W3C IDPF Explorations. Some of you may have missed, but most have seen, two weeks ago (May 10) there is a press release on W3C and IDPF about the two exploring plans to combine

<Vlad> He (whose name is long to type) likes to be called Chaals
...: "We wanted to have thoughts - not sure we can give useful answers, but ask away."

<Karen> http://www.w3.org/2016/05/digpub.html.en

NickRuffilo: some folks are on read 2.0 mailing list


Nick: more positive than negative remarks

…main question got to what impact this will have on publishing

…more specifically that W3C was sounding like Tech entrepreneurs of early 2000s

…likely a wording and messaging issue

…be aware of publishing when we have those messages

...otherwise, it's being seem positively

Tzviya: "There was some concern about the messaging - and we need to be more clear."

...: "and let people know we're working towards a specification."

Markus: " We are trying to hold back on what exactly will be done. This is not a done deal... So we wanted to keep it abstract."

Karen: "I do know that Steven Shankland from CNET published an article that was more critical of the publishing industry - and it encouraged publishing to come to the plate. It's one articles that could be seen as tech-friendly than publishing friendly. I would love it if people could post to the public mailing list all the articles so we could continue to track and improve the messaging. We're walking a tight line of current state and vision and roadmap that we expect to be real - Post merger."

<Karen> http://www.cnet.com/news/e-books-why-so-old-fashioned-heres-a-web-wakeup-call-from-w3c/

<Karen> [article Karen referenced by CNET's Stephen Shankland]

Ivan: "I think another point that was missing - for obvious reasons - i try not to answer the emails because I am biased. The work on use-cases is an enormously important task. The fact that we are doing the use-cases are fundamental in the way the work was organized. Additionally, the PWP is not a done-deal as is. So we need to re-emphasis that we're working on building a more comprehensive use-case document that is something we need to communicate and is valuable.

Tzviya: "One thing I saw happening is people feeling a need to respond - we do not need to write just to write, but we need to make sure we have the right messaging."

Dave: "I know this is tricky, but I know there has been some large-scale concerns that so much discussion and what's going on is happening in private. That most of the initial discussions were among a small group of people. There's lots to be sensitive about, but any steps towards the decision making process may pay off in public perception."

<chaals> [+! to Dave]

Bill K: "We're trying to get discussion as open as possible. The reason it was a small group of people is that we wanted to see if there was a small chance before there was any decision made. Now that it's public, we want to encourage discussion."

Ivan: "What is the right forum? I've read several longer articles on the online journals, but I dont' know whether that's the best way to do it... Where else? What/how should we be doing?

Markus: "We do have Charles here, so lets make the best use of his time. Can we do item 2 now?"

+1 to webinars

<Bill_Kasdorf> +1

<ivan> 0

<mgylling> +1

Multiple Touchpoints - webinars, articles, etc

<AylaStein> +0 (neutral)

<ShaneM> +1 (and record them and make the recordings available)

<dkaplan3> +0

+1 to recordings

<astearns> +0

<laudrain> +1 for webinars

<dauwhe> -1, not wild about webinars in general

<rdeltour> 0

Web Platform WG topics

Packaging and manifests   

Tzviya: "Moving on to Charles. Do you want to introduce yourself?"

Charles: "Sure, I'm charles..."
... "I'm here because I'm one of the chairs of the web platform group, responsible for HTML. A deliverable called 'packaging' and you may have thoughts about that... I actually said to the chairs - it would be interesting to look at what the real-world does with packaging. The draft spec we have for packaging that's beautiful, but implemented by no one. We want something that is a nice idea, but also works. You may also want to do some other things to HTML... So i'm here to talk and open some lines of communication."

Tzviya: "There were a few specific items we thought we'd cover. packaging, service workers, H-element. We did look at the spec - I think it was called 'packaging for the web' and I remember correctly the 5.1 spec decided to put it to the side for now. Charles, you talked about how packaging has not been implemented. What happens when we talk about packaging from the DPUB spec, can we expect anyone to implement? Why was packaging spec put to the side?"

Charles: "From my perspective, packaging was put to the side because it was a bright idea, who wrote it up, and failed to get any traction. "
...: "Most browsers have an extension that uses a zip and a manifest. Chrome has had at least 1, Opera has had 2... It strikes me something based on ZIP and a manifest might get some traction. I would invite you to suggest to the web platform group that you have some interest in an approach like that."

Ivan: "In a sense, who is waiting for whom. I think that the general approach of this group goes, what the publishing community uses today which is based on zip + manifest. It works. If the browsers work with that, that's fine. If we look at the special document done by Jenny, is that it looks nice, and if the browsers implement it, the publishing community might like it. If the browsers don't take it up, publishers wouldn't care.... There really isn't investment to get to a new package/tools. The community fundamentally wanted to follow what the browsers do and whatever works. "

Ivan: "I am not a publisher so I may not reflect their entire views."

Dave: "Publishers have zip+ manifest, but both of them are far more complicated than they need to be. ZIP in epub requires an uncompressed MIME type, then complexities around that. Our Manifest is a custom XML that is a web of files. We have stuff, but stuff that doesn't seem particularly close to the web, or larger web use cases. Some of our goals - especially on the manifest side - especially since there is some movement - is that ... is there some way we can build on that for our needs."

Charles: "You might find that browsers want some crazy XML redirects... My bet would be - if you say: 'we're interested in what browsers do' and a slightly more simplified zip. The manifest we have is in JSON. Shifting from XML -> JSON does take some work, not sure how that will play in your world, but if you come to the web platform group, we might be able to make some progress. At the moment, it seems like everyone is waiting for everyone else to say something. Go to the group and speak up."

<ShaneM> chaals says "stop starting and start"

Dave: "What we have that the web doesn't have is that we need to talk about large groupings of files that creates a larger file. Sounds like a webapp to me, and the manifest sounds like a great starting point for that. I'm hoping there's some overlap here."

Charles: "The manifest guy did his PHD on widgets - so they look analogous - they look like publishing packages. I don't think there are fundamental differences here."

DavE: "We've already been doing here - and in Epub 3.1 - a fair amount of work looking at JSON manifests for publishing's use cases."

<tzviya> Web App Manifest https://www.w3.org/TR/appmanifest/

Ivan: "Additionally - we are shifting to the other agenda item on Manifest. By looking at Charles' document - it wasn't clear reading the spec, whether it was easy to add an extension that is relevant to a particular community. While there are more details I don't understand, when it comes to the publishing community, there are other information that must be in the manifest that are not part of general consumption. So I'm not sure if the current thinking is to have a general framework for manifest and then some more specific extensions for other cases."

Tzviya: "I think we talked about this a while ago - Manifest and it's members. There is so much we could go with. For this to work with a publication, we'd have to extend the scope member, or add new members. We might not want to be so specific today."

<dauwhe> funny that the manifest can't act as a ... manifest :)

CharleS: "I would encourage you to go to the github repo and file some questions as issues and I think that the closest I can say is that he wants everything on the web. They understand the large package application very well, and the question of weither or not things get ported.
...: "It would seem to me if you filed issues about enabling the things you wanted to do, it would be easier to have a rational discussion with rational answers. "

Tzviya: "Ok - homework. Write those."

Ivan: "Around the packaging - the manifest structure - not so much the package format."

<tzviya> Web Manifest GitHub: https://github.com/w3c/manifest

Charles: "We have this work item called 'packaging' that no one is working on and no one implementing. We have people who think it would be nice to use though. We should actively open up that work item and abandon temporarily the new glorious feature, but write down the clunky but usable future."

Ivan: "That would work for us. Not sure what other communities out there are looking at packaging."
...: "I don't want to find ourselves again in a situation where we are both waiting on each other. We are not in a position to go to the working group and say 'drop this item' that's what you have to do ."

charleS: "What you can say is 'the path you have is complicated. The path we currently have is broadly implemented, and we'd like to explore that one. Everyone who spoke up would agree with you."

<ShaneM> in particular given that no one is working on the current one now.

Tzviya: "What i'm going to do is volunteer myself and Dave to file an issue or two on github. I know the two of us had discussed this at length. Since we talk every day it should get out very quickly.

Ivan: "Me too."

<tzviya> action Tzviya to file issues on Web Manifest Issue Tracker regarding packaging

<trackbot> Created ACTION-57 - File issues on web manifest issue tracker regarding packaging [on Tzviya Siegman - due 2016-05-30].

Charles: "I think you are the number 1 use case for packaging. The other two groups are embedded devices/browsers on consumer devices, and on things like signage. So non-traditiional devices are far more likely than standard web-browsers. The whole question of how you do packaging is up for grabs. And that would be a good segue into service workers."

Service workers

Dave: "I have been playing around. A typical ebook reader needs to work online and offline. Offline reading is a primary work case and is easy to implement using service-workers. I've built a prototype or two which I'm quite excited about."

Ivan: "My worry and question charles is - what is really the situation of service workers?"
... "I've heard 'it's coming next week' and others saying 'it is going to be abandoned' Those are extremes, but where does it really lie?"
...: "As an implementation tool, service workers are fitting and useful to us as a tool."

<tzviya> https://jakearchibald.github.io/isserviceworkerready/

Charles: "Service workers are the brave new world that will be here soon but won't work very well..."
...: "People will say they don't work well, but do lots of neat things. Then there will be pressure to make them work well. If you expect them to be done and shipped and perfect, nah...."

<tzviya> http://caniuse.com/#search=service
...: "If you think people will use them, then that is a reasonable expectation..."
... "I expect they will appear, and by-and-by will work well."

Ivan: "Can I, today, using firefox and chrome, any workers? Microsoft is interested?"

Tim: "The trend we anticipate is publications becoming increasingly complex and dynamic...."
...: "One reason a service worker is practical is the potential ability to go offline/online and one reason why the zip-approach to packaging may have limitations if the service-workers are not there to help out. I'm thinking of a situation of annotations becoming part of a publications - which may have rights issues. If you want to read it offline, you may want to bring it all offline. We would need to figure out the connectedness of this."

Charles: "If you want to have complex set of annotations, that the sort of use-case that packaging will be hard to meet. Using service workers you will have more flexibility. Using service-workers it's a straightforward job. I think there will be a role for packaging that will go on. "
... "If you can explain all the things you're going to do, we can try to figure out how to best have those happen."
...: "Right now there' sa call to kill appCache - but there is some call to get rid of it from the spec... But we should stop telling people to use it as we don't want to document all the crazy things it does."

Ivan: "One minor thing, we've had informal meetings, and what we want has made them enthusiastic. If you need something more formal, we will be happy to document that we need service workers, but Jake does know we need it."

HTML Extensions, Custom Elements (e.g., <h> element)

Tzviya: "H element and HTML extensions... I hesitate to bring up the H element as it'll take more time..."

<dauwhe> https://discourse.wicg.io

Charles: "H element is a proposal for an HTML extension. What we've done in HTML is to toss out the H1 is an H element... There are all manners of things you can do to HTML. Which comes to a general approach we have. If you haven't got implementation proof, which doesn't necessarily mean one of the top-4 browsers, but it means really shipping products that people are using. If you have ebooks

that are running in reading systems, then that counts. If you have an idea bout something that SHOULD be in HTML - such as the H element, then you should write up a spec to the incubator group. There is a process of moving that into HTML."

Tzviya: "Reason I put this on was that the ARIA group was wondering if there was interest in supporting the H element, because it's similar to things in the past that have existed in publishing. "

Charles: "I thought there would be too. But 'hey we want this' is usually not how it works - we wait until there are people actually using it. Get your initial implementers there."

<tzviya> https://discourse.wicg.io/t/html5-h-custom-element/438

Ivan: "What is the status there? What is currently the situation?"

Charles: "It has no traction with implementers. There's no obvious push that it's getting shipped in browsers. We don't know of any implementation anywhere else. If we did, we'd be looking at it. There are other things we are looking at."

Ivan: "Implementation, that means using the HTML extension? "

Charles: "Custom Element. If we saw millions of the custom elements, then there's strong requests for it. If we saw lots of stuff using the H element - because it worked in popular e-readers, then we'd have a case that it looks like something real. We don't have any of that, so it's in waiting."

<ShaneM> custom elements are only supported in Chrome / Opera

<dauwhe> spec: https://github.com/ThePacielloGroup/html5-h#html5-h

Ivan: "I understand that. IN a sense, my more general question, is what is really happening in this sense with the custom element. Is that a stable thing - such as a footnote, H-element, is that a basis we can rely on?"

CharleS: "My read is that it's about as stable as service workers. It sort-of works, but if your market strategy relied on it, I wouldn't invest in it. As a solid experimental thing to play with, yes."

<tzviya> https://github.com/w3c/html/issues/160

Tzviya: "I mentioned in IRC - that I forgot REL on the agenda. If you want to talk about it, take a look at the 5.1 issues tracker. Feel free to comment on it. I'll open up the floor for additional questions for charles.

Charles: "Feel free to propose values that HTML should adopt for REL. There's a proposal in that item that all venues should accept all values, but we will write down all the widely used values and blessing them when there is a reason to do so. Given that there is an easy thing to do, any proposals based on that are easy to do."

Tzviya: "From what I understand on ARIA is that this doesn't make it into the API mappings, the APIs ignore them. Is there a way for these to have meaning for those using assistive technologies? "

Charles: "Seems reasonable to go to implementers and say: 'This is now part of HTML, so the implementation API gets it right.'"
... "If it's in the HTML specification, and browsers are supposed to handle, but it doesn't build the accessibility tree, that is a browser bug."

Ivan: "Charles - we should try to have a regular meeting, honestly from the outside, your working group is so utterly huge and unmanageable for us. We have so much respect that you know what's going on, but it's difficult for us to know where to go or whom to talk to. Can we have some regular touch-base with you or someone else from the group? We will need it in the future more and more."

Charles: "I'd be happy to try to set up something regular. "

Thank you charles!

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/05/24 09:46:49 $