Digital Publishing Interest Group Teleconference

<trackbot> Date: 31 August 2015

<tzviya> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Aug/0173.html

<pkra> +present Peter Krautzberger

<ivan> scribenick: pkra

<tzviya> http://www.w3.org/2015/08/24-dpub-minutes.html

tzviya: re last week's minutes.
... any comments?
... minutes are approved
... CSSWG was busy last week.

Report of the CSS WG Meeting

dauwhe: fair amount of discussion about issues of interest to DPUB
... esp. pagination

<laudrain> present Luc

dauwhe: several results.
... first) missing pieces to get from document to displaying stuff in a viewport / page.
... work has started on new spec to bridge that gap.
... esp. for multiple streams of contents flowing into different templates
... seems to be missing part of the conceptual model of CSS.
... also a sense from browser vendors that pagination is more an application feature, not platform feature.
... esp. one specific vendor took this position despite having region etc in their engine.

tzviya: popularity contest?

dauwhe: recurring theme: interests of people who don't work for browsers seem different to those of people at browsers cos
... also related to Houdini features.

<pbelfanti> And if other platform developers jumped off the George Washington Bridge, would they do that too?

dauwhe: browser vendors quite different as compared to present non-browser folks.

<pbelfanti> As my mother used to say…

Bill_Kasdorf: curious re interests from browser vs non-browsers. Maybe some more info? How many non-browser devs etc.
... not really publishers, correct?

dauwhe: yes, not many people from publishing sphere
... most non-browser people were representing web developers.

Alan: agreeing with dauwhe.
... also talked about custom layout.
... agreement about spec is sketchy so far and does little for fragmentation, hence pagination

Chris: Agreement with that. They run into this all over the place

dauwhe: agreed. Example from Johannes Wilm, mentioning repeatedly how detecting fragmentation would make his work infinitely simpler.

Ivan: what's the difference between fragmentation (vs pagination)

Chris: other fragments are columns.

dauwhe: fragmentation is splitting up content between container.
... so more advanced on the "splitting up" part then the container part.

Bill_Kasdorf: are fragments seen as things that are created dynamically during rendering or inherent in the structure of the document?

Chris: the former.

mgylling: we noted a while back that we didn't even know which part will fix pagination (Houdini, existing modules, something else).
... is this more clear? Do we know where to put our efforts?

dauwhe: "slightly less fuzzy"
... pagination split between overflow spec and not-yet-started specs described above.
... on the implementation side, we'll be depending on Houdini to give us the tools to do this ourselves.

Alan: we talked explicitly about what's in layout and what's done as API
... the layout part will probably solve the first 70%. Then Houdini for the rest.

Ivan: where is the cut?

Alan: very simple pagination that interacts with the viewport spec.

dauwhe: will give us base pagination. But not more complex like side-by-side, footnotes etc.
... probably won't.

tzviya: that cuts out all I'm working on ;-)

Alan: maybe a sign of the representation of the group.

tzviya: what's the next step? No recognition or too complex?
... do we revise the great documents that dauwhe has worked on.

dauwhe: lots of interested people who want to push things forward.
... maybe subgroups should have calls/meetings to work on such items to hash this out far enough to bring it back to the CSSWG.
... that way main group has less noise, and interested people can push things forward.

Ivan: coming back to "browser vendors regard pagination as application feature". So their view is this should be done via Houdini?

Chris: Basically: just not interested in pagination.
... keep in mind that the JS might pick up on markup.

Ivan: so we need to agree on library/common work. How do we create a library?

Brady: there are already a few people doing this.

Ivan: are they just built in deeply into reading systems?

Brady: deep, e.g., in Readium.

Alan: some libraries could provide a basis for specialized library.
... e.g., bookjs, FT(?)

Ivan: is it worth doing though?

Nick: fully worth showing a proof of concept. But it's already out there in most reading systems.
... having a better tool would be great though.
... reach out to anyone doing open source (Readium etc).
... ask them if they can compartmentalize this.

Ivan: right. In the future, some of the features might be taken up by the browser, some of them better be done via Houdini. So in that new environment, let's look for a new basis.

Nick: agreed, reach out to people like Readium.

dauwhe: we should get Readium folks to talk to implementers to provide feedback on APIs etc.

<astearns> +1

brady: +1 to Ivan. We should reach out to implementers such as Readium.
... right now we have implementations but if you ask implementers, you'll find they would like (very much) to have a better solution.
... will reach out to other Googlers on the task force.

Ivan: is this progressing ok? Do we need more?

dauwhe: some discussion about exceeding the mandate.
... started to change the document quite a bit.

Chris: I didn't see it as about mandate but about features mixed together.
... e.g., OpenType MATH tables are not related to any spec.

<tzviya> document under discussion http://www.w3.org/TR/2015/WD-dpub-css-priorities-20150820/

dauwhe: agreed. I already updated the document to reflect input.
... e.g., math is such a large topic, it might warrant a separate doc

who'd have thunk.

scribe: feedback regarding math. Requirements so complex that they need to be addressed specifically.

Ivan: should we set up a joint meeting with CSSWG in Sapporo?

dauwhe: meeting with very clear, precise agenda would be good.

<ChrisLilley> +1 to a specific agenda rather than general discussion

Alan: enabling some of the broader/fuzzier items, it would help if people could go through the schedule and plan dial-in as much as possible.
... CSSWG could always benefit from more diverse perspective.

tzviya: Alan, could you share details?

Alan: will do.

tzviya: Would it be helpful to provide more precise examples?

Alan: often the need is acknowledged. E.g., footnote is clear but without pagination it's not possible to discus.

tzviya: maybe a little collaboration on how approach the agenda will help.

pkra: will bring up the discussion on next MathWG call

tzviya: more comments?

dauwhe: other topics are interesting for DPUB.
... e.g., the paint API could help a lot.

<ChrisLilley> custom paint is going to fpwd soon

dauwhe: e.g., CSS borders are not very powerful right now. the API could help a lot.
... similarly acknowledgement for font API (even if implementation not happening soon).

(yay on both)

Ivan: not sure how to convince browser vendors that to more seriously consider use cases from this community.

with pitchforks?

Heather: not sure about application vs layout level.
... the browser often is the application.

Alan: people read in browsers. Scrolling is dominant. People read paginated in reading systems. We argue that this is a standard way of reading. Browsers take the view: the web developer should do the heavy lifting.

Heather: so we should go somewhere else to read?

Ivan: more: write complex web app.

Jeff: problem is also demand from web app vs ebooks is different.
... for ebooks this is strong.
... so the question is the additional layer.

dauwhe: like a plugin?

<astearns> what I was trying to get across that pagination is a recognized need, but that most browsers don't see enough need to justify the implementation/standardization costs

Jeff: browser-based application. Like Chrome is an application using Chromium.

Ivan: as a user, I should not be forced to import a special tool (plugin etc) to have this facility.

dauwhe: also many ebook reading system out there. Part of our mission is to make the more interoperable.

<Bill_Kasdorf> +1

<ChrisLilley> I disagree, lots of people make code and let others ride on it

Nick: from a business perspective: pagination is something all books need. Pushback: no-one wants to create code that others will benefit from.
... at least business people usually don't want to give their stuff way.

<ChrisLilley> yes, they do it for another reason like growing the market

Nick: so if we can make pagination a generic feature, to have compatible implementations, will help us drive this forward.

Ivan: have their been usability studies on reading long form (e.g., thousands of pages) is pagination better compared to scrollable reading.
... with real data.
... collecting such studies would help.

<Bill_Kasdorf> it's even true of short document like journal articles, which are overwhelmingly preferred in paginated form (which now means PDFs not HTML are what are overwhelmingly used even when both are available.

dauwhe: the market has spoken though. All reading systems do it.

tzviya: but is it for real reasons? To turn around: many reading systems have introduced scrolling view

Bill_Kasdorf: many studies on journal articles being preferred in PDF

tzviya: but is it about pagination or page numbers or other factors?

<HeatherF> This might be of interest: http://www.nngroup.com/articles/infinite-scrolling/

<NickRuffilo> not a full "study" but a start: http://www.nngroup.com/articles/infinite-scrolling/

<NickRuffilo> ahaha

<HeatherF> high-five, Nick!

pkra: caution: remember studyt about negative effects from reading system UIs (voiding pagination).

New Charter

<ivan> http://www.w3.org/2015/09/digpubig

<Karen_> +1 charter approved!

Ivan: charter has been approved.

... administratively people will auto-stay due to rechartering.
... but time for reflection: what's worked, what hasn't, where to focus.
... maybe in Sapporo
... passed with flying colors.

karen: also growing interest from other regions in the world. Japan, China, Latin America. We can improve onboarding.
... address regional interests.

tzviya: no meeting Sept 7.

bye

<NickRuffilo> thanks!

<dauwhe> thanks pkra for scribing!!