Digital Publishing Interest Group Teleconference

<trackbot> Date: 06 July 2015

<scribe> scribenick: NickRuffilo

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

<Bill_Kasdorf> I think Dave added a seventh agenda item, right?

<tzviya> http://www.w3.org/2015/06/29-dpub-minutes.html

Chris: "Hello! I'm Chris Lilly technical director of Interaction Domain - involved in CSS, web-fonts, SVG. In particular, I'm here because I want a closer liason with CSS working group and Houdini. And what DPUB wants. I was invited for this call - and expect to participate regularly."

Tzviya: "Anyone else new on the call? There are some new joiners of DPUB. Not sure if you're on the call or in IRC"

<ChrisL> congrats Alan!

Tzviya: "Adding a comment about DPUB and CSS -> the CSS Working group as identified new chairs - and Alan Sterns is one of the new chairs. Congratulations!"

<Karen> +1 Alan as new co-chair in October

Alan: "I will not be chair until october"

<Bill_Kasdorf> +1

<pkra> +1

<ivan> +1

CSS, Houdini Project, Pagination

Tzviya: "I believe there is only 1 thing on the agenda - discussing CSS with Chris. I've posted a bunch of links to CSS, our requirements, houdini. Dave has added many links to our priorities. Just the morning he added stuff to that. I'll turn this over to dave and chris"

<dauwhe> https://www.w3.org/dpub/IG/wiki/Functional_Requirements_for_Pagination

<dauwhe> https://docs.google.com/spreadsheets/d/15IsDMPwSXx197Iqe4I9xh7K8anmJ5c0-OFEG7w0LHYM/edit#gid=2138850308

<dauwhe> http://w3c.github.io/dpub-pagination/priorities.html

Dave: "We have been working on a couple of things - first was the wiki page that has functional requirements - based on early work by Brady - interacting with pages stuff. We're trying to collect our requirements there. The 2nd piece that we started working on is an explicit CSS priorities document which has been a google spreadsheet."

<ChrisL> oh, I hadn't seen that spreadsheet before

 Dave: "We will start to move it to a different format once it's more final and written up in a better format. There are tons of information and it's a challenge to figure out the best way to show it. But, it sort of feels useful to start collecting all these things 'in one place' that is really multiple places"

Chris: "Dave is on the CSS group - I've poked him about Latin Requirements. But then there are all these other things that have new things."

davE: "One of the core issues is - what is the reason for being for LatinReq... It didn't have anything to say about implementations and priorities."

Chris: "I wasn't suggesting that it need be the only doc, just the only place I was looking."

Dave: "Yes, LatinReq isn't enough - we need a W3C document that notes more information."

Tzviya: "We're hoping to get a bit of clarification of what is going on with houdini and how this fits it in."

Chris: "A feature of the web is using polyfills - so people don't have to wait for features to be added. This sort-of works but tends not to work if you use a bunch of them together. It ends up doing lots of re-implementation, which is pointless as the browser already knows how to do it. Also there are some things that are really hard to extend as it happens under the hood. The idea of houdini (and it's named after a magician) because it's trying to remove some of the hand-waving."

...: "It's a sub-group of CSS and the TAG, but it's more API based. I think this is a new focus on new APIs and new extensibility points. To make it less abstract - we plan on exposing the box tree - it's largely assumed that the boxes that are made follow the element tree (there are a bunch of differences - and many over time) especially when you go across a fragment. You also might want to have things like Pages in there as well - which belong in a box tree and not the DOM tree. That is how I see houdini fitting in."

<dauwhe> http://dev.w3.org/csswg/css-display/#intro

Dave: "In the CSS display spec there is a note about what it means to be in the box tree and DOM tree. This may end up being where we use these things - the display tree."

Karen: "That was one of the more articulate descriptions of houdini! Thank you! We really need to go to the next level of explaining 'what is this and how does it work together' so not only our members, but people interested have a clue. The next step would be to prepare a more plain-english 'for resources, for publishers, ...' think about how do we best communicate some of the work that we are doing to our community right now."

<Bill_Kasdorf> +1 to Karen

Chris: "I agree that it is needed - and many W3C working groups need to work on. For houdini it is still up in the air, but in the upcoming Paris meeting, I believe we will be tackling this, and in October that would be a good time to address this issue."

Karen: "I'll sync up with Nick on this."

Ivan: "What you describe is one end of the spectrum. The other end is the poor technical people who have to do something with pagination in the reading system. When we had a discussion at the NY meetup - we discussed having 'these and these' features that should be in the CSS declarative style. We noted what is missing and what we were trying to get. The reader should be able to handle pagination through a declaration."

...: "Now there is another side saying that some super-magic should be doing this through Houdini. Something that publishers & authors should be using. We ended up by saying we are unsure what line we need to be prepared for - and possibly both."

Chris: "I hear what you say let me try to address. Declarative is the way it's going and where it will continue to go. Most poly-fills use declarative syntax that isn't used them implement. From authoring - no need to touch that stuff. you should be able to get far without scripting. For an implementer POV—which is extends a browser, there will be a need—as you won't want each individual item bringing in the polyfills - you want the browser to be a 'browser ++'"

Brady: "I think that is where we left it - that's the conclusion in my head. Publishers should be using these CSS specs in a declarative way—the reading system NEEDS to be able to use these polyfills. As an implementer, I have to struggle with adding the polyfills in a cross-browser way."
...: "Pagination is the most horrible thing that has ever happened - there is multi-column that gets panned around. You can do it by breaking up the DOM - as you have no idea where things end, so you have to figure out where text ends... People have done it with scrolling and putting a gap between pages. None of them quite work—and you cannot do things on a page-level. You can't do widows and orphans well either with many of these concepts."

Tzviya: "Widow and orphan control and hyphenation are simple things that are very important—and difficult without the concept of a page."

ivan: "if this is the way it goes, then we as a group need to accept that Houdini is there, and the implementors do the polyfills. Then the question is: do we have everything in CSS that the publishers need to make the declaratives? Then we need to go back to the CSS working group to ask for certain things to be declared."

Tzviya: "A lot of scholarly publishing uses PDF is because of MATH - even though we have MathML and other things, it's either difficult or NOT supported at all, and that's keeping the STEM world away."

<pkra> same for education.

Ivan: "What is it that the CSS working group needs from us? To have pagination on the priority list?"

<tzviya> http://w3c.github.io/dpub-pagination/priorities.html

Chris: "There is a GAP analysis between what is specified and what browsers ACTUALLY do. What is the level of implementation? Also why - is there missing information?"
... "What is currently in use, what are the needs, and what isn't yet specified. having clear requirements and adequate detail - how it will be extended - how does it actually work - because CSS has suffered from multiple inconsistent implementations - we're trying to avoid doing that. Having multiple pagination requirements will be an issue. Demonstrating need with clarity and how it is additive and not breaking the model would be a high priority."

Ivan: "Ok that makes sense"

<ChrisL> yes, one way forward is to triage the existing specs and get agreements on which are the bad bits

Dave: "I agree with Chris. I think one thing we need to do is that—there are a lot of page related stuff in CSS specs. It's widely varying quality and in some cases there are things that have been that are described by the PDF formatters a long time ago and don't represent the modern consensus of how CSS should be designed. Even the CSS page-spec itself - and the margin boxes. At some point everyone needs to decide, do we go ahead with the older things and try to patch them up. Do we burn the village and rebuild with more modern concepts?"

Chris: "Figuring out what isn't implemented—because it's rubbish—and removing that will help us see where we are going."

Tzviya: "There are concerns & belief that this is used for print... This is—in some pockets—used for print, but all of our interests are beyond print. "

Chris: "The reason I raised that is that the CSS working group looks at it as 'well, who prints web pages anyways' and the common use cases - such as tabbed viewing, and apps that are using slideshows - those tend to get brushed off."

Ivan: "This pretty much relates to the other issue—the browser vendors. I see pagination as potentially pretty interesting from a user-interface point of view on the web. It's very long—then pagination as a find of user interface structure is something I would really love to have. And I must say that some of our own documents would benefit from such a use-case. Is this discussed at all by browsers? Do they see any argument about that at all?"

Chris: "They do tend to brush it away. This is a problem that is also faced by accessibility—we want these for blind, color blind. In the early days, they did the research and found that the market was low - so browsers wouldn't implement. But, as new information comes out, they realize that there are more people who would benefit from such features—such as accessibility. We want to have cross-references so you can say 'page 28' but equally we want to say 'section 5.3.2' if we solve one, we can solve the other one. Then, what we need gets implemented."

Ivan: "In a sense; would it also help if the publishing community put these kinds of arguments more explicitly the user interface for pagination."

<pkra> sliders?

Tzviya: "In the documents we're calling for - we should declaritively state that it works for slides, flashcards, cards, tiles."
...: "We should spell that out - so pagination isn't just for 'books'"

Tzviya: "Chris - do we need to clarify between CSS and Houdini when writing this document?"

Chris: "I suggest not - see it as a continuum. Some things are implemented, some are IN CSS but not implemented. Some can be easily polyfilled, and some are hard/impossible to polyfill without houdini."

<tzviya> http://w3c.github.io/dpub-pagination/priorities.html

Chris: "to clarify - the document is the wiki pages?"

Tzviya: "Nope - this is the text version of the CSS worksheet"

DavE: "this is evolving. I'm still fumbling a bit."

Tzviya: "Dave should get more help and input from others in the group. "

<ChrisL> yes, I commit to helping with this

Tzviya: "We could use help determining implementation. We know what we want, but we're not sure where things would happen. There are a list of where specs exist. We could use help in that section."

<ivan> ChrisL++

Chris: "I already committed to some GAP analysis on pagination - so i'm already working on that. So I'll commit here, because this will make the research a bit more public."

Tzviya: "OK."
... "Other comments? We have next-steps but I'll leave dave and chris."
...: "Everyone clear on next steps?"

describedAt

Deborah: "Ok - Should we call what I have 'final'? George sent some comments and I incorporated what he suggested."

Tzviya: "Just send the final version around."

Deborah: "I'll do that this morning. This in particular is PF - feels - uncomfortable - about the ARIA describedAT ARIA role in that they don't think there is alot of buyin yet from publishers to implement. Our note is an explanation of 'why we think it is INCREDIBLY useful"

<ChrisL> (discussion of aria described-at and aria 1.1 vs 2.0 staging)

Tzviya: "The reason they are considering deprecating it is because there is a new version. Deborah and Charles concluded - with lots of input - that now is not a good time to deprecate describedAT. They put together alot of examples of how it would be useful. So, we have this draft of the note. If any publisher in particular has strong feeling, they might as us as publishers to come to a PF

meeting."
...: "If anyone wants to see the text get in touch wtih deborah, charles, or I."

Deborah: "you can always conect me if you have suggestions or questions"

Tzviya: "Anything else before we close it for today?"

Ivan: "Worth noting as a heads-up that the document that Tzviya and Markus made with PF - the DPUB-ARIA document has gone through all the necessary hurdles - it will be published tomorrow! It has been accepted by Judy and michael is taking care of it.

<Karen> +1 interpretation for publishing community