Digital Publishing Interest Group Teleconference -- 12 Jan 2015

<mgylling> trackbot, start telecon

<trackbot> Date: 12 January 2015

<HeatherF> I'm usually IP_Caller (or some such thing) to start - not sure how to fix it since I came on before the trackbot?

<azaroth> Morning :)

<scribe> scribenick: tzviya

<aylaStein> That's Ayla Stein

<kwkbtr> Thank you!

kwbtr: joining from Vivliostyle for first time

<mgylling> * Approval of last week's minutes [1]

<mgylling> * Cancel call next week? (MLK day in US)

<mgylling> * Move to public wiki: https://www.w3.org/dpub/IG/wiki/W3C_specs_for_DPUB

<mgylling> * Houdini project: digital publishing requirements

<kwkbtr> This is Toru Kawakubo from Vivliostyle

Welcome Vivliostyle!

last week's minutes: http://www.w3.org/2014/12/22-dpub-minutes.html

approved

<aylaStein> Yes

<liza> Safari's off

<HeatherF> No preference on my part.

<azaroth> sadly, Stanford is open

<Karen> MIT is closed

<aylaStein> UIUC is closed

<Vlad> Monotype is closed

MLK day in USA: cancel meeting

W3C publications relevant to publishing

Markus: Thierry and Ivan recommend moving https://www.w3.org/dpub/IG/wiki/W3C_specs_for_DPUB to public wiki

tmichel: currently, the document is on DPUB IG wiki, question is whether to move this to public wiki that is editable by anyone with an account
... or should we keep it restricted to W3C/DPUB IG members, as currently?
... and, is DPUB-IG satisfied with content fo this doc?

markus: if one of us would like to update, we can edit in the wiki

tmichel: we will keep an eye on it, if it is a public space

<tmichel> review the document until the next call

<tmichel> +1

<aylaStein> +1

<bjdmeest> +1

<liza> +1

<tmichel> next call in two weeks

markus: homework for IG to review/edit the document until next call, at which point we will make public

<liza> I'll volunteer to explicitly review it

<tmichel> People should also voice if they are not satisfied with moving the document to a public wiki.

project Houdini

<liza> (I'd like to write a blog post with some narrative around it when it's public anyway, so this will be good homework)

dauwhe: Project Houdini is very technical
... initial meeting is in Australia 7-8 Feb
... joint meeting between CSS WG and TAG
... objective of task force is to explain the magic of layout on the web
... people are starting to look for ways of extending CSS in the same way that HTML can be extended via ShadowDOM, JS, etc
... to date this has been impossible

<mgylling> +regrets Frederick Hirsch

dauwhe: one aspect of this is the BoxTree API
... people have been creating numerous nested boxes and positioning them
... Boxtree provides a model for that

<mgylling> +regrets David Stroup

,,,Another part is a method of manipulating the CSS Object Model (CSSOM)

scribe: there is interest in rewriting the CSSOM from scratch as the existing model is difficult
... one thought for this meeting is to get an idea of what people want from this effort
... one example that came up last week is font metrics

<pkra> darn I want to dial in now...

<dauwhe_> wiki https://wiki.css-houdini.org/main

<dauwhe_> mailing list: https://lists.w3.org/Archives/Public/public-houdini/

markus: when is the meeting?

dauwhe: 7 - 8 Feb, adjacent but separate from CSS WG

<Karen> Tzviya: I am wondering from DigPub perspective, is there anything you need from us?

<Karen> …Our most pressing issue is Fragmentation issues

<Karen> …Brady wrote something up

<Karen> …Ivan is concerned things not get lost in the shuffle

<Karen> …What is it that we should be doing?

<Karen> Dave: I am not sure on that

<Karen> …I will be there, Peter there

<Karen> …This use case is definitely going to get some attentoion

<Karen> …not sure yet what direction

Dauwhe: some of information is coming from Google
... there will be some loud voices making sure that pagination is address

markus: help me understand scope of Houdini
... accessing a refreshed CSS with JS is one thing, boxtree is another
... would a fundamental issue such as pagination be scripted, not declarative?

dauwhe: some of ideas are heavily influenced by extensible web manifesto
... which advoactes for experimenting

<mgylling> Brady’s pagination requirements page: https://www.w3.org/dpub/IG/wiki/Pagination_Requirements

dauwhe: and polyfilling. The polyfills can evolve into standars

extensible web manifesto https://extensiblewebmanifesto.org/

<dauwhe_> TabAtkins: We'll nail things down more explicitly in the first meeting, but the idea is that our current approach of delivering a new layout mode every 5 years or so isn't sustainable; they're too complex and the whole thing is too slow. Beyond core "layout modes" (like Flexbox, etc) there's a lot of other stuff that generally falls under the rubric of "box-tree manipulation" (like Regions, and the constellation of functionality surrounding their

<dauwhe_> core concept, like running headers, footnotes, etc.) which, again, takes a long time to go from "idea" to "usable on mass-market websites".

<dauwhe_> TabAtkins: While there's still value in finding the highest-impact stuff in this realm and standardizing it with CSS syntax, we feel that for CSS to continue to be viable in the future, we need to open up these sorts of APIs to developers more directly, allowing them to define their own layout managers/etc with lower-level box-creation/manipulation primitives. This TF's goal is to figure out how to do this in a way that's compatible with the perf

<dauwhe_> concerns of today's and tomorrow's browsers.

markus: we have dave, alan, peter linss, vivliostyle. is it correct to assume then that we do not need to worry about publishing being dropped on the floor? Do we need to rally?

dauwhe: for now, we are OK. We may need to rally in the future

markus: Brady's use cases (https://www.w3.org/dpub/IG/wiki/Pagination_Requirements) are applicable use cases
... at the very least, we need to get Brady and other contributors to flesh out the use cases

action markus talk to Brady about fleshing out the pagination use cases

<trackbot> Created ACTION-44 - Talk to brady about fleshing out the pagination use cases [on Markus Gylling - due 2015-01-19].

markus: are there any other items that we should prepare to have ready for Houdini?

dauwhe: we might get a lot more capability to intercept and process CSS, which might offer reading systems processing power
... for things like user style sheets

markus: it might be a good idea to break the personalization use cases out of brady's use cases and present them separately

https://www.w3.org/dpub/IG/wiki/Accessibility_and_Personalization

tzviya: we have use cases related to personalization as regards to accessibility
... we should try to consolidate the 2 sets of use cases

markus: other topics?

dauwhe: there might be smaller categories
... math layout for example
... how does one display chemML in a browser? There might be several things required for polyfills
... If we started to have access to layout primitives, new things might be possible

Tzviya: Peter Krautzberger probably will have something to add in the area

,,,issues in STEM often involve extending table rendering, fonts for chemistry, etc

markus: what is a good term?
... maybe the best place to start is with Peter K and STEM use cases
... it does not sound STEM-specific

tzviya: another area that can be difficult is infographics

markus: that might be solved with SVG
... we have a meanwhile plan to collect use cases
... brady on pagination, consolidate personalization, and talk to Peter K about STEM
... and Dave will be our conduit to CSS WG :)

karen: is anyone going to Digital Book World?

<mgylling> +regrets Brady

Digital Publishing Interest Group Teleconference

12 Jan 2015

Attendees

Contents

W3C publications relevant to publishing

project Houdini

Summary of Action Items

Scribe.perl diagnostic output