- From: Thierry MICHEL <tmichel@w3.org>
- Date: Mon, 31 Aug 2015 21:23:25 +0200
- To: "public-digipub-ig@w3.org >> W3C Digital Publishing IG" <public-digipub-ig@w3.org>
Hi all,
The minutes of the Digital Publishing Interest Group Teleconference
dated 2015-08-31 are now available at
http://www.w3.org/2015/08/31-dpub-minutes.html
These public minutes are also linked from the dpub wiki
http://www.w3.org/dpub/IG/wiki/Meetings
Also find these minutes in a text version following, for your convenience.
Best,
Thierry Michel
----------------------------
[1]W3C
[1] http://www.w3.org/
Digital Publishing Interest Group Teleconference
31 Aug 2015
[2]Agenda
[2]
http://www.w3.org/mid/3ef7300e473f4bceb360a7453e5acb75@CAR-WNMBP-006.wiley.com
See also: [3]IRC log
[3] http://www.w3.org/2015/08/31-dpub-irc
Attendees
Present
Dave Cramer, Tzviya Siegman, Michael Miller,
Deborah_Kaplan, Heather Flanagan, Luc Audrain, Charles,
Alan Stearns, Vlad, Markus Gylling, Julie Morris, Paul
Belfanti, Tim Cole, Bill Kasdorf, Chris Lilley, Karen
Meyers, Thierry Michel, Nick, Zheng_Xu, Bert Bos, duga.
Regrets
Ben, Ayla
Chair
Tzviya Siegman
Scribe
peter, pkra
Contents
* [4]Topics
* [5]Summary of Action Items
__________________________________________________________
<trackbot> Date: 31 August 2015
<tzviya> agenda:
[6]https://lists.w3.org/Archives/Public/public-digipub-ig/2015A
ug/0173.html
[6]
https://lists.w3.org/Archives/Public/public-digipub-ig/2015Aug/0173.html
<pkra> +present Peter Krautzberger
<HeatherF> Noooo! Scribing is scary!
<pkra> I could scribe.
<pkra> noise?
<HeatherF> That was Vladimir
<pkra> brady?
<pkra> ah
<astearns> vladimir's line is noisy
<brady_duga> Not me
<brady_duga> I am muted
<Vlad> I am on mute now
<tzviya> scribenick: peter
<Vlad> Are you still getting noise from my line?
<ivan> scribenick: pkra
<tzviya> [7]http://www.w3.org/2015/08/24-dpub-minutes.html
[7] 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 hte
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,s omething
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
spec descirbed 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 implementors to
provide feedback on APIs etc.
<astearns> +1
brady: +1 to Ivan. We should reach out to implementors such as
Readium.
... right now we have implementations but if you ask
implementors, 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
[8]http://www.w3.org/TR/2015/WD-dpub-css-priorities-20150820/
[8] 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:
[9]http://www.nngroup.com/articles/infinite-scrolling/
[9] http://www.nngroup.com/articles/infinite-scrolling/
<NickRuffilo> not a full "study" but a start:
[10]http://www.nngroup.com/articles/infinite-scrolling/
[10] http://www.nngroup.com/articles/infinite-scrolling/
<NickRuffilo> ahaha
<HeatherF> high-five, Nick!
<ivan> [11]http://www.w3.org/2015/09/digpubig
[11] http://www.w3.org/2015/09/digpubig
<Karen_> +1 charter approved!
pkra: caution: remember studyt about negative effects from
reading system UIs (voiding pagination).
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.
<NickRuffilo> -1
<clapierre> -1
<Karen_> -1 7 Sept
<dauwhe> -1
<HeatherF> +1
<tzviya> -1
<mgylling> -1
tzviya: no meeting Sept 7.
bye
<NickRuffilo> thanks!
<dauwhe> thanks pkra for scribing!!
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [12]scribe.perl version
1.140 ([13]CVS log)
$Date: 2015/08/31 16:07:04 $
__________________________________________________________
[12] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[13] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30
Check for newer version at [14]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[14] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/???/Alan/
Succeeded: s/representatives/representation/
Succeeded: s/???/Brady/
Succeeded: s/???/Brady/
Succeeded: s/FS/FT/
Found ScribeNick: peter
WARNING: No scribe lines found matching ScribeNick pattern: <peter> ...
Found ScribeNick: pkra
Inferring Scribes: peter, pkra
Scribes: peter, pkra
ScribeNicks: peter, pkra
WARNING: No "Topic:" lines found.
Present: Dave_Cramer Tzviya_Siegman Michael_Miller duga Heather Deborah_
Kaplan Heather_Flanagan Luc_Audrain Charles Alan_Stearns Vlad Markus Gyl
ling Julie Julie_Morris Paul Paul_Belfanti Tim_Cole Bill_Kasdorf Chris L
uc Karen Thierry Nick Zheng_Xu Bert
Regrets: Ben Ayla
Agenda: [15]http://www.w3.org/mid/3ef7300e473f4bceb360a7453e5acb75@CAR-W
NMBP-006.wiley.com
Found Date: 31 Aug 2015
Guessing minutes URL: [16]http://www.w3.org/2015/08/31-dpub-minutes.html
People with action items:
[15]
http://www.w3.org/mid/3ef7300e473f4bceb360a7453e5acb75@CAR-WNMBP-006.wiley.com
[16] http://www.w3.org/2015/08/31-dpub-minutes.html
WARNING: No "Topic: ..." lines found!
Resulting HTML may have an empty (invalid) <ol>...</ol>.
Explanation: "Topic: ..." lines are used to indicate the start of
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report
[End of [17]scribe.perl diagnostic output]
[17] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
Received on Monday, 31 August 2015 19:23:36 UTC