See also: IRC log
<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.
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).
<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!!