Digital Publishing Interest Group Teleconference

<mgylling> https://www.w3.org/2016/06/06-dpub-minutes.html

Markus: "Any issues with minutes from last week? No - approved"

2nd Virtual F2F meeting

... "The next topic is another virtual face-to-face. It was on the agenda last week, but use-cases took up time. We were thinking we should have some kind of frequency with virtual face-to-face. The general concensus was that the last one was worth-while and we go alot done, and the video was a nice touch. We're tossing out the week of the 4th of July. There were 2 days that we want to propose. Since the agenda was sent, Tuesday was shot down but Thursday the 7th is a potential date for the meeting?"

<dauwhe> +1

<mgylling> +1

<ivan> July 7 is fine with me

<d> July 7 OK for George

<clapierre> +1

+1

<rdeltour> -1

<Bill_Kasdorf> +1

<bigbluehat> +1

<brady_duga> +1

<pkra> +1

<laudrain> +1

<dkaplan3> +1

Markus: "Same time as last - 8am Eastern to 12am Eastern. For europeans 2pm in the afternoon until 6pm. 5am for west-coasters..."

Markus: "For the west coaster people we will shift an hour so the NEW time will be 9am eastern to 1pm Eastern - 4hours total. 6am West coast start, 3pm European start..."

<mgylling> http://www.timeanddate.com/worldclock/fixedtime.html?msg=DPUB+IG+Meeting&iso=20160707T09&p1=43

Meeting with IDPF BFF Group

Markus: "Moving on. An additional call... We said for a while that we wanted a joint call with BFF group in IDPF and the general IG. This because there is a potentially large overlap in what the groups are doing. BFF is a spinoff of the epub revision is to do a browser-based JSON version of things. It's a separate project without a deadline. We thought we'd set up a call just to meet and greet with those people - one being dave cramer and hadrien to talk about BFF and whta has been going on. We want to discuss short-term and longer-term things that ensures that the way they evolve is useful in the future. The date is June 27. Ivan - you have set up a webex line for this, right? "

{ Forever: { Friends: Best }}

Markus: "Should we firm up an agenda?"

Dave: "Someone will create an agenda, but we should probably have one of our own."

CSS F2F meeting report

Markus: "Next up are two items relating to CSS - the first is about the F2F in San Francisco. It struck us last week, but we didn't get a recap. Is there anything that we need to be aware of?"

Dave: "As far as some of the big things - flexbox and grid. I think Flexbox is really close to done, and it's in CR. Grid isn't as far along but they've been continuing to make progress on it. Another big thing for us is generated content in CSS. The existing working draft of that is from May 2003. I took over the spec with someone else and we removed 13 years of stuff - and then updated it to more relevant things. We talked about that in advanced of what will be the first public working draft. The most exciting bits around that is that the print processors seem to allow generated contents on elements and not just pseudo elements - yet there is controversy around those ideas. The browsers - at least chrome - allows you to use an image, but not a text-string as user-generated content. The working group resolved to continue what browsers do, that you cannot have arbitrary elements, so you could replace a URL with an image or a video.

Ivan: "What is the generated content on elements?"

<laudrain> generated content is a must have in text composition

Dave: "You could say: h1: content {"this is a head"} which would replace the DOM content with what you state. There are situations where it is handy, but you can work around most of those situations. The other big thing with generated content is accessibility. When I was working on the spec with fantasai, we talked about building in an alternate text within the content itself. So you could use the content property, then a trailing slash and alternate text if needed. One nice thing about this is that you can use all the existing techniques for alt-text, such as having an empty string for alt-text if the content is purely decorative. We know we have lots of more work to do with the accessibility. We know there is alot to do and it's very buggy with all the implementations. I know we need to do an AAM."

<d> Q: Does this break separation of presentation and content?

<astearns> ivan: .chapter-title::before { content: "Book Name: "}

Ivan: "How would that be used with alternate text?"

<clapierre> Great to hear alttext was added to generated CSS content!

<dauwhe> h1:before { content: url(icon.png) / "alt text for an icon" }

Dave: " there is a grey area here - this has been part of CSS from the beginning. There are good uses for generated content with respect to accessibility. One example from the epub accessibility guidelines are thought/expression breaks where there may be three blank lines, etc. We asked in epub to use HR to define that sort of interruption. For generated content, that ornament can be added to that HR while maintaining accessibility. "

Ivan: "Back to your example, I get the syntax, but does it mean that the browser is expected to use the alt-text, popping it up in a small yellow box? "

Dave: "That I don't know."

Ivan: "In the case of an alt-text for an image, the alt-text is processed - and the CSS can be ignored but the processor can still see it. But for this, the processor would still need to go through the CSS. "

Dave: "Yes."
...: "This is where things get complicated - it will need to get inserted into the render tree - and this is the question of how things get inserted into the accessibility tree. So we need generated text to be searchable and selectable. The goal here is to provide the information that AT would need to do something helpful here. Much more would need to be done to determine how that would happen."

Markus: " OK - that's interesting stuff. Lets move on to next things. Dave - anything else from the meeting?"

Dave: "A couple of other things - the working group has been interested in things around baseline grids - in order to control alignment of stuff across pages and columns. This is something that CSS doesn't do hardly at all. Adobe had been working on a baseline grid spec. Kojii did something called a step sizing spec, which was supposed to solve some of these issues. We talked about that spec, but we don't think it may meet all the use-cases that we have. Another fun thing is hanging punctuation. Apple has implemented this in webkit, and we talked about it a bit. We'll keep it in CSS text-level 3 but I've been tasked to learn it out. We know better what should happen in CJK languages than Latin languages."

...: "The final thing I'll say about the CSS meeting, Florian brought up a somewhat rare situation with page numbers and odd indexing - you don't know how wide something will be, as it might be on page 99 or page 100 - so you risk getting into a cycle of renumbering. It was probably not the best thing to bring up, but it brought up a rant by some developers: "why are we wasting time on book/publishing stuff, when I only want to talk about what [my browser] will implement in the next 6 months?" There were words exchanged... There were then discussions as to if we should care about all these different groups/topics."

Markus: "We are talking about Priorities next. Before we dive in, is there anything the IG should be doing to help you out there?

Dave: "What I really need is input from fine-art typographers. "

George: "Are there sufficient numbers in the CSS group?"

Dave: "There are never enough. I'm not sure if it makes sense for more people to join. But only if you are really interested."

<astearns> raising issues on github and commenting on issues is always welcome

Nick: "Which is more important to - studies showing things are valuable to users - or business drivers?"

Dave: "Most likely business driven."

Ivan: "If there is real business - in the sense of showing that more people will use a browser to do certain things if a feature is there, that also drives decisions."
... "It's important - especially with Pagination - if there are studies showing it's better than scrolling, it becomes useful."

CSS Priorities

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

Markus: "Moving on. Next topic is priorities. Maybe, Dave, for the avoidance of confusion, can you begin with reminding us how it is related to LatinReq and why it is different."

Dave: "It's oddly self-evident and impossible to explain. We wanted to come up with a wish-list of things we'd like to be able to do but cannot do. There are several reasons for why we cannot do something. Easiest level - 3 browsers let you do something, but 4th doesn't - so that prevents you from doing something everywhere. The idea was to come up with things that would have the biggest bang for the buck - and how we communicate that to the browser vendors. This document was a relatively flawed attempt to do that."

Markus: "What are the problems with it?"

Dave: "These are hard things to talk about as it's hard to make a business case - as we tend not to have large amounts of input. It's hard to have a formal process for assigning priorities. "

Markus: "Was it exposed to the CSS working group?"

dave: "Yes, but a year ago and I forgot how it got?"

Markus: "What was the response?"

Dave: "There were some questions as to what it was for and how it was prioritized?"

<dauwhe> http://w3c.github.io/dpub-pagination/priorities.html#changes-since-the-editors-draft-of-30-august-2015
...: "I made some updates, and thought it would be useful. The good news is that there is a fair bit of movement in the things we wanted. In a certain case - there was a lagging browser that got in a new item. Hyphens property is being worked on. Firefox has shipped some things for vertical writing mode. Hanging punctuation in Safari... Generated content... Character alignment in tables is now in an editors draft..."

Nick: "What if we ask publishers?"

Dave: "I wouldn't want pre-determined ideas - but we don't want to be open ended. So it's hard for people to know what they haven't thought about. There are translation issues between CSS and publishing problems. "
...: "Is there a different way we can get direct input into what people think about these things."

Markus: "Nick's question to me is +1. The basic question is that we felt the document was flawed - but should we stop working on it or change the approach to achieve what was intended. It sounds like the original intent, backed by some weight, in terms of companies behind it - sounds like it would be a good thing. Alan? Dave? Would this be worthwhile?"

Dave: "Do formal efforts like this help more? Or is it better for pubs to just talk to their apple reps"

Alan: "The main flaw with priorities - even with large pub backing - is that the browser developers will see this as a theoretical thing, and dismiss it, if there is not someone who is trying to build something but coming up with a roadblock. If a large publisher had a project, but were blocked by a feature, but had some developer weight - if you were to do this, we'd be able to implement this thing, or remove a raft of javascript - ..."

Markus: "Isn't Florian's group an example of this?"

Ivan: "Alan said it better than I was going to. Just to compliment to what you said. I think the problem we have is that, in the CSS working group - and the same holds for HTML - what really counts and makes people think and move is people come not only with wishes, but some sort of implementations - polyfills or not - whether we like it or not, that's how those groups operate. If you just come and say: 'wouldn't it be nice to have this' then people don't listen. If you come up and say: 'i tried to do it, implemented this, and there is a quick-and-dirty implementation - then that makes people listen more. I'm not sure that's good, but that's the impression I get. "

Markus: "In terms of an approach for us, where does that leave us?"

Ivan: "Just coming out and saying: 'we need this - we won't get the result we want..."

Nick: "We have Readium - and things like iBooks - that are web-based with a huge slew of additional features. So can we use that to convince the browsers to implement these things?"

<dauwhe> speaking of pagination, look at this in desktop Safari 9+ https://dauwhe.github.io/epub-zero/acme-publishing/MobyDickPaged/

<clapierre> Benetech is working with Readium on adding accessibility features

Ivan: "I'm afraid that there might be other features - and Dave should know that better - where Readium doesn't do certain things because it's not available. Readium doesn't have CSS polyfill for CSS features. They simply don't do it, and the message to the epub producer is that 'we can't do that becasue CSS doesn't do it."

<dauwhe> overflow: -webkit-paged-x; -webkit-scroll-snap-type: mandatory; -webkit-scroll-snap-points-x: repeat(100%);

<clapierre> Readium is working on MathML Peter has filed some tickets with Readium on those issues and is helping to resolve them.

<astearns> best-case scenario - people start publishing using something like Readium (or Readium itself) in large numbers, then browsers start competing with each other in how they enhance that experience

Markus: "Sounds to me, Dave, and this will be a day you remember - as your workload will get reduced. I don't think we should keep asking you about the CSS priorities doc. The approach we're using today is incomplete. We need to think of another way to do this that we can get something that bears fruit. And we don't know what method that is. Maybe worth discussing on the virtual face-to-face

Ivan: "having - as comprehensive a CSS list as features that publishers need - having a list like that documented is still important."
...: "we shouldn't just throw it away - we need a document that says: 'these are the problems that have not been solved. The current document has quite a bit of that. As for the current document being operational, I'm not sure who to talk to in the CSS working group, or how to push forward. The document Dave started came out of a dicsussion that came out of TPAC - That is how the document came into the picture - and it seems to have whatever we had then. Maybe we need to talk to them again. We can try to spend half and hour during the VF2F and see if the CSS WG will come..."

Dave: "I'll mention one historical thing - lots of work has been done on developing feature-sets like XSL-FO for publishers. It would be really helpful to have the GAP analysis - what's in FO but not CSS yet. We have things that have been spec'd. We have some publishers moving away from FO - so knowing the difference between the two is a big step. "
... "That might be the natural outcome of FO from W3C - to determine what has been replaced by CSS and what has not. "
... "It's a baseline for requirements for some scientific and journal publishing. There is lots of useful information we could profitably mine."

Bill: "It's used by documentation publishers as well. "

Dave: "If our mission is digital publishing in general - here's a large area of digital publishing that hasn't made it to the web, it's worth us thinking about. "

Markus: "Lets keep that in mind as a new effort for this. We do need to discuss it further of the priorities document and what we need to do. I don't think it's useless to have the document, but I don't think it gets us to where we need to go, so that is why I recommended letting it go."

Bill: "There are things that we can only do by using FO or Readium - so here's the only way we can do them now and it's not a particularly good situation. "

Ivan: "Can we continue this next week?"

Markus: "Yes, we can resume discussion next week - and possibly the virtual F2F"