Digital Publishing Interest Group Teleconference

<trackbot> Date: 29 June 2015

<scribe> scribenick: NickRuffilo

<laudrain> present_ Luc

<HeatherF> Mute early, mute often.

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

Tzviya: "any comments on minutes for last week?"

<pkra> +1

<HeatherF> Sorry I missed it

Tzviya: "Silence is golden - the minutes from last week are..... APPROVED!"
... "Web Annotations Update"

Web Annotations Update

<tzviya> http://www.w3.org/annotation/

Ivan: "as you know the group was created after a workshop. We have no quite a good mix of publishers and web-application developers. That's a good things. part of the good is semantic web - some are the more 'geeky' web developers. Contact is going OK - but they think different (tm)"

<ivan> http://w3c.github.io/web-annotation/model/wd/
...: "There are no issues, that's just the dynamics. As you may know, the group started with a specific specification that wasn't a W3C standard - but was created by a community group - the open annotations community group. They had a pretty complete specification. That was the main input for the work there. That work is the annotation data model. The way annotations are represented when moving to different systems. There was a first working draft that was published."

ivan: "That document is mostly the same as the community draft. Biggest difference is that this is based less on semantic web and Turtle (one of the usual languages used for semantic web) and it has been translated into JSON - and it has both, so it lets you choose how you'd like to read it. There were some minor changes."

<ivan> http://w3c.github.io/web-annotation/protocol/wd/
...: "There is a documentation called Web Annotations Protocol (linked above). it's in a fairly good state and we hope to have it out in the first working draft in 1-2 weeks. It's actually a document that is based on a recommendation that was recently published at W3C the LDP (linked data protocol) which looked at how you transfer this types of data over HTTP and store them, retrieve them, etc. Fairly minor specification on top of the existing protocol."

<ivan> http://w3c.github.io/web-annotation/api/rangefinder/
...: " The 3rd document that is in prep that we hope will be a draft within a few weeks is the Rangefinder API, which comes closer and closer to the things we've discussed. The issues is how do you define a range or a sequence of characters, or place in a document to which you can attach some annotations - so you can also change, so it's relatively stable to changes to the document as a whole. It's currently and API for Javascript - mainly for JS applications that are running on the client. But it has issues on JS level things on how you can get the text of a selection, and find it in a document... If you look at the document there are quite some issues."

...: "Once this rangefinder is specified, there should be some sort of URI or serialization of it, so I can define it in terms of URI, or fragment ID."
... "There are lots of discussions on various use cases and technical details. There are directions that have been raised that we still don't know if we'll do more. Still not sure if we want to define and API in Javascript. I don't know if this will be defined. It is still something we have to look at. The other thing that is regularly coming up - the annotation data model is JSON or Turtle. Implementation will be JSON, but there are discussions on whether there is an HTML serialization of the model..."
...: "The way it could be used is that a client could add such elements into the DOM tree. Since it's in terms of the DOM, it can be styled easily in general - which is probably something very useful. Whether this would be done using existing elements or whether it would be done as an extension to HTML is unknown. We haven't had any serious discussions on it yet."
... "We have some overlaps - which is good. Bill K is regularly on the call. Rob Sanderson will hopefully come back soon..."

<tzviya> https://www.w3.org/annotation/wiki/Use_Cases#Use_Cases_by_the_Web_Annotation_Working_Group

Tzviya: "From my perspective - what is happening in my day-to-day - my colleague is attending the annotation meetings. There are topics we are both discussing. Issues like fragment identifier come up, and it may be helpful for everyone to discuss the overlaps. The use-cases that the WG put together would be useful. The copy-edit use-case for example."

Liam: "This relates to copy-edit use-case. There is a change-markup working group. They implemented the open-office using open markup - may be worth considering what they do."

<liam> https://www.w3.org/community/change/

Tzviya: "Idea is to keep the work we are doing in sync. make sure we're aware of what everyone is working on."

<liam> (I think that is right; DeltaXML has offered their technology to W3C)

CSS Prioritization

<tzviya> https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jun/0091.html

<dauwhe> google doc: https://docs.google.com/spreadsheets/d/15IsDMPwSXx197Iqe4I9xh7K8anmJ5c0-OFEG7w0LHYM/edit?usp=sharing

Tzivya: "Dave has put together a list of CSS priorities."

<dauwhe> The start of a more expository version: http://w3c.github.io/dpub-pagination/priorities.html
...: "We can spend some time today work on the priorities list."
... "Thank you dave - this is the thing we really need to send to the CSS working group

...: "It's STARTING in google docs for easy and quick edits - but we're doing an HTML doc in github as well"

Dave: "I think some of this may end up merging with latinReq so i'm still figuring out the best way to collect and display this information"

Tzviya: "Any other comments?"

Luc: "I was just wondering why footnotes is #3? Is it because it's already processed/specified?"

Dave: "Right now it's mostly a print feature and I'm not sure there is consensus that it works within digital publishing. Within paged media I'm not sure there is a reason to display footnotes as they do in print. It's a feature that's incredibly difficult to spec. We are a long way from having interest for implementations. It will have to be a lot of lower level features - and it is a problematic area."

Luc: "if we treat footnotes as we do in paper, it could be complex, but if we treat it as a place where we treat it differently in digital - it comes down to spec."

Tzviya: "That's an issue for semantics of HTML, not for CSS. "

Luc: "Do we really want footnotes to display at the bottom of the page in digital?"

DavE: "people are doing tons of things in HTML. There are popups, and all sorts of renderings. In open-web, we can do many renderings, but the bottom of a page is not really possible. Until there are some specific display-mode that people agree on, it may be a bit pre-mature. i'm not sure what we would do right now, besides saying "we want displays at the bottom of the page." that would need new CSS or markup."

Peter: "How far the MathML spec is a reasonable reference? I suppose there is an open problem of MathML and CSS in general - and the reality of it in implementations... How useful is the MathML reference?"

Dave: "Basically we're unsure how it will introduce it. For the spreadsheet - this isn't what we'll do when we finally present it. for each of the math issues - we have different points for different sections of the spec. We know much exists in the MathML spec. For the spreadsheet - spell out what items you want and why (specifics). We'll get to the politics later on."

Liam: "The spreadsheet is great - another aspect is what should be under USER control and what should be publisher control. You may also want to say 'i want to see footnotes at the bottom of the screen' If footnotes are marked up, the readers will have the ability to let the users choose. We should bear that in mind."
... 'User style sheets are a low-level thing. No user in the planet is capable of writing it, so it becomes the job of the user-agent. This is more global.'

Brady: "The user-stylesheet is misnamed. It's broader - the ability for the user to do interesting things. User-stylesheet is probably not the right word."

<liam> [e.g. "display footnotes at bottom of screen" depends on footnotes being marked up in the text]

Peter: "I think actual work needs to happen between MathML and HTML/CSS is equations. How far is it appropriate to link to the mathML spec as a solution to the problem when they are supposed to be CSS problems."

Dave: "Linking to MathML is perfectly appropriate. It is a spec that has a solution to a particular problem - even if in a different space.
...: "Going back to user-control over styling. I see that as a huge issue, on the scale of being it's own task force, I don't think it has been explored nearly enough. My sense is that that is the model that CSS was built on and it's entirely inadequate - and we need to think about that area."

+1

<tzviya> +1

<astearns> +1 to more discussion on user customization - the discussion usually ends on "not user stylesheets" and needs to progress past that

Tzviya: "we should not hesitate at ALL on commenting - this is an early document, please comment."
... "Think of it as a brainstorming thing - priority is hard to assign and I think dave has done a good job so far with priorities, if you have input, dave would appreciate it. If things are missing, throw them in. We also need to figure out what to do NEXT with the document. And how we bring it up to our friends."

Dave: "If we have more priorities - more things we want but don't have - after that it is a lot of wordsmithsing and information and such."
... "Input on priorities is greatly appreciated. I found some recurring themes. And posted on twitter..."

Ivan: "Let's remember how we started with this current round. It started because there was a disconnect between DPUB and CSS WG - and CSS had a false impression that the DPUB community doesn't have anything to ask for - we're all happy with problems solved!"
...: "What this table shows is that this is not true. What we want to show is to see what is the most helpful for the CSS working group to influence the way the CSS working group evolves so that everyone is equally happy. Not sure we should go back into our corner for half a year. we should see this as a continuous discussion."

Bert: "Hard to say what the BEST approach is, but probably good to have some people meet at the fence. To get to the priorities - you'd need a champion who can talk to people - alan, dave, myself. Try to get those people to speak up at the CSS working group. People can read the documents, but you need someone to explain them in a nice voice

Ivan: "We did have the idea - chris offered to come to this call at some point - more interested in pagination that houdini, etc. We could invite daniel glazman, etc. Would be good to have regular contact"

Nick: "Might be worth a read-through of EPUB3 spec and Apple Spec"

Dave: "Most of what we've discussed are in multiple specs - so one of our big task is leaning on browser vendors to actually implement these things."
... "The CSS working group might not be the only working group to do that."

Not just browsers - also ereading platforms

Ivan: "We should separate features that land on CSS working group and features that are just about implementation by browsers/reading systems"

Dave: "Ways of structuring that are evolved - I've been trying to have a category for 'things that need spec' 'things that have been spec'd but need implementation' ..."

Tzviya: "We have a few tasks in front - items we're asking for, and from whom we're making the request. Our immediate goal is to list the items we're asking for. Then what to do next is a little more complicated. Not alot of support for implementation. We need it written up and fairly quickly."

<HeatherF> Yes
...: "Everyone get comments in by end of the week. Is that enough time for the first draft?"

+1

<HeatherF> :-D
...: "In the following weeks we'll work towards documentation."

Liam: "When i get a chance, I'll add the properties in XSL-FO that aren't yet in CSS"

Charles: "In reviewing the document - I see accessibility - it's blank right now. Isn't that a big issue?"
... "With screen-readers and hyphenation - getting that working..."

Dave: "That's also a question with initial letters, pseudo elements - making sure ..."
...: "What sort of virtual elements..."

Tzviya: "We need to make sure WHAT we are working on is accessible. We may not right it, but it may get passed to PF for an accessibility review. Most of what we're asking for is generated content - which is not accessibile."

<pkra> http://bocoup.com/weblog/text-rendering/

Peter: "I just was wondering what to do about the above issue. Somebody analyzed that improving text rendering came with significant performance. Even if we get issues into CSS, but they aren't usable, that gives other issues..."

Dave: "On thing is we all have different use cases in different environments. There are features that are not appropriate because of context, etc. If readability is more important than 60FPS, we give authors tools so they can make tradeoffs themselves."

Brady: "The performance issues are difficult to leave up to publishers - a 2meg chapters, with optimized legibility and pagination, it's hard to tell the publisher to worry about that, or the reading system. Although not sure what CSS can do."

Changes to white paper

<ivan> http://w3c.github.io/epubweb/draft/

ivan: "I've made changes to the white-paper based on the discussion on Cache - where some of us chimed in. I tried to put the general ideas in there. Before I put that in the main version, I'd like it to be reviewed."

<ivan> http://w3c.github.io/epubweb/draft/#general-architecture-for-online-offline-publications
...: Please have a look today - because things need time to be read by others."

<tzviya> http://www.w3.org/TR/2015/WD-service-workers-20150625/

Tzviya: "Service workers is a first-public working draft."

tzviya: "Looking for comments on CSS prioritization and the EPUB-WEB white paper - ASAP!!!!"