Digital Publishing Interest Group Teleconference

<trackbot> Date: 16 June 2014

<pkra1> I'm 617-858.aadd

<pkra1> ah, I have a bad nick.

<ivan> scribenick: benjaminsko

mgylling: minutes approved
... Main Topic: update on latinReq draft status from dave, Proposed changes to task force names,
... Peter to cover scope, what's in and out of scope for our work here

<pkra> thanks.

clapierre2: returning employee at benatech. interested in accessibility and metadata for epublishing.

<azaroth> gcapiel: Best of luck in your new position! You'll be very much missed

<Bill_Kasdorf> you will be missed, Gerardo!

dauwhe: MAIN TOPIC: want to first talk about what's going in CSS working group that dpub is interested in

<dauwhe> http://dauwhe.tumblr.com/

<gcapiel> Thanks! It's been an amazing experience collaborating with you all.

dauwhe: earlier identified two priority areas-drop cap and footnote. esp with drop caps, there has been intense action in CSS working group. Drop caps on web and in ebooks are broken. i created a tumblr showing how broken they are
... cant be relied on to maintain as font size changes. this is an area that the web should be able to do these correctly. it turns out there was a proposal in the CSS line layout module in 2002. (have theory that everything already exists in an abandoned CSS draft)
... there was a misunderstanding in their model and examples. brought this up in a CSS conf call. some expressed interest in working on this--how text sits in boxes, inline processing...added as a co-editor to the spec specifically to work on drop caps
... added to agenda for face to face meeting in Korea. gave presentation, which led to a really good discussion that lasted close to 90 minutes that everyone in room was interested in (including google, mozilla). this is something that would be relatively easy to implement

<dauwhe> http://lists.w3.org/Archives/Public/www-style/2014Jun/0108.html

<dauwhe> http://dev.w3.org/csswg/css-inline/#DropInitial

dauwhe: based on results of that discussion, dave wrote up a new proposal for CSS dropcaps, which is now in an updated editor's draft. much simpler than what was there before, but is more powerful than what is in indesign (which adobe team found amusing)
... at this point we have a skeleton of a workable proposal. lot of work to be done esp in internalization. how does this work for arabic, japanese, etc. when flying back from korea, couldnt find any examples, so perhaps not an issue in all languages..
... optimistic that someone is going to want to implement this so that it will trickle down to the epub reading systems that are based on web rendering engines
... i think we're in a good place with this one

mgylling: Questions?

dauwhe: this is a good example of how things work with CSS. when we have a clearly identified problem, it becomes a matter of doing the research and writing on the spec. advocacy and diplomatic work that this is important and will solve problems for lots of web users

<astearns> identifying a minimal first step towards a full solution is also extremely helpful

<mgylling> http://dauwhe.github.io/dropcaps/Overview.html, http://dev.w3.org/csswg/css-inline/#DropInitial

mgylling: googling, found linelayout module and inline layout that seemed to have the same section about dropcaps...

dauwhe: one was where i was sketching things out before i entered it in the editors' draft
... the latter link is the correct one

Bill_Kasdorf: bravo to dave, wonderful work, thanks so much
... can drop cap issue be resolved without being tied up w/resolution of a bunch of other CSS issues? is there a timeline?

dauwhe: what matters is implementation, getting people interested in implementing
... there are people with the ability to drive implementation who are interested in this. i don
... i think this is something that will move forward
... will it be split out or remain part of line layout? for now it will be left as part of line layout. i dont see a problem with it not being split out.
... i don't see there being an implementation issue with regards to rest of the line layout spec

pkra: any chance of ...polyfill

dauwhe: someone is working on that now

<astearns> I have a person on my team at Adobe investigating a polyfill - no promises, though

pkra: things like polyfill and mathml could help us enormously

dauwhe: with some lobbying the line layout is now a high priority for the CSS working group

mgylling: the editor's draft is there, someone working on a polyfill, browser vendors are interested. is there anything that the IG can do to help you out?

dauwhe: no
... the most valuable thing in the world is attention from interested people, any sort of attention or comments to www-style are really helpful
... if you happen to work for browser companies, lobbying is appreciated too

mgylling: test cases?

dauwhe: haven't thought about that yet. we're in editor's draft stage, still trying to sort out what the features are. once that settles down we'll be thinking about test cases

mgylling: alan?

astearns: in terms of helping out, if you use ibooks or has ibookss contacts, lobbying there will help convince webkit to implement more quickly

dauwhe: exactly
... other high priority was footnotes. status is murkier. antenna house and prince support footnotes with similar syntax. CSS module for paged content discusses footnotes, but there really hasn't been much support for those concepts in wider world
... they require a lot of magic to drive without identifying a fundamental mechanism...they dont feel a part of the open web platform as it exists today. and so, want to find the visual effects we want based on tools that are being created for modern CSS

<pbelfanti> Apologies, I must drop for another meeting

dauwhe: esp the idea of regions. you can take some content and flow it into a region and you can style that region. was wondering if we can get a more robust definition of footnotes if we can base it on regions. was playing around with this, wrote up some sample syntax. discussed it ast the face to face meeting at Seoul.
... using ideas from regions and various page template proposals, addresses what we want but more firmly grounded in CSS as it is evolving today
... result of discussions. start a level 4 of the GCM spec. this will serve as an experimental draft to see if we can work out a good def. of footnotes based on regions and other template ideas. it hasn't been created yet. will be co-editor. daniel g? is also co-editor.
... will give us better definition for running headers and footers, greater flexibility and power. planning to start working on that soon.
... that's footnotes

Luc: agree w/dave about footnotes. kind of item we need to define more conceptually.
... in digital we can render it differently, need to define the item it via semantics vs rendering structure. footnote is complementary content. way it can be rendered can have different actions from print.

dauwhe: i would agree with that. a footnote is a particular visual rendition of a certain kind of semantic content. being able to do this with CSS because with media queries or print style sheet and allows you to treat print and digital differntly
... my goal is we want to have this display option as one of our choices, but it is not the onlt choice.

Bill_Kasdorf: my comments are along the same line. could this also apply to marginal notes? key is to get rid of concept of "foot"

<Luc> +1

dauwhe: nice thing with footnotes as regions is you get sidenotes for free

you can have multiple footnote areas, you get sidenotes, in what seems to be a natural way

ivan: footnotes are close to annotation. need way to avoid too many parallel discussions. we already have use cases defined for annotations. may be useful to review annotation with a footnote glass on yr nose (?)
... we are at point where in a few weeks the charter for the annotation working group will go to AC. work will begin in earnest

<fjh> +1 to considering annotations; CSS also relevant so a bit to coordinate

ivan: try to bind things together for synergy

dauwhe: that's a good idea. i will look to see how this fits w/the proposed annotations.

ivan: the two proposed co-chairs are on the call right now

azaroth: happy to answer questions

dauwhe: what's come up today - can this concept be useful annotations - is useful.

ivan: is it still useful to think about footnote-specific use cases? publishers know the footnote use cases the best. is there still a possibility to chase for more of those

dauwhe: that leads to something that is happening with footnotes and dropcaps, there is tension between creating a feature that can address every possible use case and a feature that is relatively easy to specify and implement
... being getting lots of examples of dropcaps from books that are hundreds of years old, something that is woven in to the entire page. i love seeing them, i don't think we can implement a spec that can support everything that was done in the last 800 years [did i get his right -ben]
... we aim for 80-90% not 99.9%

<astearns> perhaps even 60%, as long as what we expose can be extended to another 20-40%

mgylling: with 15 minutes to go what else do you have for us?

dauwhe: trying to find out what our are priorities as far as layout goes, where can we put effort and get the greatest payback. would love to hear are there 1 or 2 other areas that we should focus on to try and get something going

mgylling: anyone?

dauwhe: at the idpf convention ran into will mannis(sp?), had problems with inline module of CSS. he was doing some work to get PDFs into ebook form and the baseline handling of CSS was preventing him from doing what he wanted

mgylling: keep this question open for awhile. it's obviously an excellent strategy to identify the highest priority and go for them. question about the latin req document. how does that evolve now in relation to yr other activities?

dauwhe: latin req doc has certainly taken a back seat to the work going on in CSS.
... can move stuff back into latin req based on some examples and illustrations created for CSS working group
... if the group can identify priority areas in latin req, we can. looking at it as a whole is overwhelming. in practice, adding to it has been difficult since there are not a lot of other people working on it right now

<Bill_Kasdorf> +1 on running headers and footers

Luc: re:priorities in latin req. after drop cap and footnotes, question of running headers and footers because when we use ??? we had difficult question of large books that are ??? couldn't be read..
... we re facing this problem...dictionaries, large volumes of very precise information.... would like this to be examined for the future [i wasn't able to capture the exact nature of the prob - ben]

Bill_Kasdorf: being able to maintain header and footer around long sections is very useful

<Luc> without running headers and footers, large books cannot be made avalaible in EPUB

dauwhe: it's a navigation aid in keeping yr bearings in a vast expanse. from phonebooks to indexes that have headers showing
... highly evolved solutions that came up through print, the need for them has been shown, how do we meet that same need in a digital environment

mgylling: running headers and footers might be addressed by the footnote work

dauwhe: we're talking about content that is being copied elsewhere in the document to serve as a visual marker
... it gets awkwards as the content of running heads gets more complex. or as you want to display that content in an unusual palce

mgylling: is chapter 8 solid enough to be reference for CSS working group?

dauwhe: not sure what state is in right now

mgylling: chapter 8 could be another focus area
... ...return in 2 weeks to discuss this. some of the others may come from the STEM area. we deviate a bit from the agenda re:task force names to talk about STEM. Peter to discuss.

pkra: my question what is scope of the interest group. progressive enhancements (responsive tables), user agent suggestions, and new standards (e.g., scientific notation)
... maybe this is off the mark because i am new to this so looking for input

mgylling: so is your question is "are new standards out of scope?

pkra: yes

is it out of scope to pick new standards (e.g., chemml) as winners to move to w3c?

mgylling: to me the answer is not out of scope, charter of working group is to identify needs of the publishing community. we can have luxury during use case definition to not worry about difficulty of use case.
... if the scientific pub community that cannot be met by existing specs of open web platform, then we should document that fallacy(?).
... do not hold back in terms of this stuff. we are not proposing solutions in this IG. we are only providing use cases and motivations for forthcoming solutions. ivan?

ivan: fully agree
... if we identeify as specific area--e.g., chemical markup--and we think ahead to see if this can be standardized, we not only name the standard but give an idea about the size the importance of the market, the main players as much as we can
... fully agree with markus. one other thing i was wondering about--this came up in the past--some of STEM's problems (e.g., chemistry)--i've heard that components at W3C may be a good general solution.
... don't know if that is true or not. we should look at how the web components evolved....last question is--mathml is defined to be k12 but was not meant to be the tool for theoretical physicists.
... isn't it also true that use cases may reveal holes in the existing standards

<gcapiel> +q

pkra: i'd say it is the opposite (from implementation). problem is parts of the mathml specification there are no way to implement [?]

<Bill_Kasdorf> K-12 math wasn't introduced in MathML until MathML 3.0. It was originally for the mathematicians and scientists

<Julie> I have to sign off now-- thanks for the meeting!

gcapiel: as to missing use cases, presentation matjml which is what is being used on the web, there are a lot of missing semantics to make it more usable from an accessiiblity standpoint
... gap between prsentation mathml nd content mathml

mgylling: at next call start with STEM discussion sorry too short today
... talk next monday

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/??/polyfill/
Succeeded: s/drop book/ibooks/
Succeeded: s/two/two proposed/
Succeeded: s/correlate/coordinate/
Succeeded: s/??/azaroth/
Succeeded: s/wright/right/
Found ScribeNick: benjaminsko
Inferring Scribes: benjaminsko

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: Bill_Kasdorf IPcaller Ivan Julie Luc P15 P17 P22 P26 Stearns TimCole Vlad aaaa aabb aacc aadd aaee aaff aagg aahh aaii aajj aakk aall aamm astearns azaroth azaroth42 benjaminsko brady_duga clapierre2 dauwhe david_stroup dentist dkaplan3 dpub duga fjh gcapiel gcapiel1 joined liam mgylling murakami pbelfanti philm pkra pkra1 plinss scribenick tmichel trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/public-digipub-ig/2014Jun/0031.html
Found Date: 16 Jun 2014
Guessing minutes URL: http://www.w3.org/2014/06/16-dpub-minutes.html
People with action items: 

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