DPUB IG Telco, 2015-10-05: Portable Web Publication Draft, CSS Inline, Extended Description Analysis

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

Portable Web Publication Draft

The PWP Editor’s draft has been updated since like week. Ivan Herman gave a status report, whereby:

  • The term ‘Publication’ has replaced ‘Document’ overall
  • The terminology for states have been incorporated into the document
  • The EPUB dependencies have been removed; instead, a separate section has been added on the relationships to EPUB

There were some discussions on the last issue during the call. It was agreed that

  • The section on EPUB relationships should be a full-blown section and not an appendix
  • That section included a paragraph making it clear that the content of a PWP are (just like EPUB) primarily Open Web Platform resources. That content stays where it is, but the section on terminology should also include some very clear statement in the same direction

It has been agreed that these changes will be done within 1-2 days, and that the rest of the group can look at, and comment by email, between now and next Monday. The goal is to make a formal decision on next Monday to publish a First Public Working Draft

CSS Inline

Dave Cramer has reported that the Initial Letter features have been implemented in the latest version of Safari, and it ships in IOS9 as well as Mac OS “El Capitan”. Although there are some bugs, this is still a great step forward. Unfortunately, tests are still missing, and continuing work on internationalization is necessary (what are the Initial Letter features in, say, Arabic?).

Extended Description Analysis with PF

Michael Cooper published an Extended Description Analysis with PF, that outlines proposed approaches to provide extended descriptions (@longdesc, aria-describedby, etc), in view of making a final decision in which direction the ARIA work would decide to go in this respect. The Accessibility task force has already looked at the table, and will produce comments to the PF Working Group before TPAC

Miscellaneous

The group discussed the schedules and joint meeting plans with other groups in view of the W3C Technical Plenary in a few weeks. The group also decided to hold its meeting next week, although that day is Columbus day in the US.

Posted in Activity News, Meeting reports | Comments Off on DPUB IG Telco, 2015-10-05: Portable Web Publication Draft, CSS Inline, Extended Description Analysis

DPUB IG Telco, 2015-09-28: Glossary, Portable Web Publications FPWD

See minutes online for a more detailed record of the discussions.

Glossary

Development of the Digital Publishing Glossary has been ongoing for a while now, and the IG discussed remaining outstanding issues. There was full agreement that we need to be very clear that the terms included should be used and understood only within the scope of DPUG IG publications and discourse; this since there is a considerable overlap between terms used here and the same terms in other domains (e.g. “document”, “resource”). To reduce the risk of cross-domain confusion, it was agreed as a first step to rename one of the core terms, “portable web document”, to “portable web publication” (PWP). It was also agreed to highlight the need for single-URI identifiability of the set of resources that make up a publication as one of the differentating factors between a PWP and an ordinary website. Regarding states of portable web publications, it was agreed to use protocol vs file system API access instead of the online/offline distinction.

Some further work on the glossary remains, but in general the IG believes we can soon call it done (as a first version) and consequently move on with our lives and other IG activities.

Towards FPWD of Portable Web Publications (formerly EPUB-WEB)

The EPUB-WEB whitepaper has been renamed and revised with the intent of using the terminology of the glossary and through that achieve a lesser dependence on EPUB-specific terminology and technology. The new version is currently being reviewed by the IG, and after another week or two of additional edits we hope to publish it as a FPWD. The IG will discuss the document’s status and outstanding issues on the coming week’s call.

New CSS Grid Layout, Inline Layout and Page Floats Drafts

The W3C Cascading Style Sheets (CSS) Working Group has published three Working Drafts:

CSS Grid Layout Module Level 1: This CSS module defines a two-dimensional grid-based layout system, optimized for user interface design. In the grid layout model, the children of a grid container can be positioned into arbitrary slots in a flexible or fixed predefined layout grid.

CSS Inline Layout Module Level 3: The CSS formatting model provides for a flow of elements and text inside of a container to be wrapped into lines. The formatting of elements and text within a line, its positioning in the inline progression direction, and the breaking of lines are described in CSS3TEXT. This module describes the positioning in the block progression direction both of elements and text within lines and of the lines themselves. This positioning is often relative to a baseline. It also describes special features for formatting of first lines and drop caps. It extends on the model in CSS2.

CSS Page Floats: This document describes floats that move to the top or bottom of content passages. This feature has traditionally been used in print publications in which figures and photos are moved to the top or bottom of columns or pages, along with their captions. This draft describes how to achieve this effect for floats within pages, columns, regions and elements.

Posted in New W3C documents | Tagged | Comments Off on New CSS Grid Layout, Inline Layout and Page Floats Drafts

DPUB IG Telco, 2015-09-21: Publication Object Model, MathML

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

DPUB API

Daniel Glazman presented his ideas of an API to access contents of publishing packages (like EPUB). Daniel is implementing an EPUB3 editor (Bluegriffon). When you create a tool like that and, for example, you want to add metadata, you have to follow a chain of ID-s and IDREF-s repeatedly. The same for adding a file, delete a file, etc. The code you have to write is huge and repetitive. This may have hindered the adoption of EPUB3. If we had an EPUB object model, with an open source implementation and polyfill this would help deployment; right now everyone has to implement everything from scratch.

Although the current development is focused on EPUB, the idea is more general. It would be a two-layered approach: a general layer to access essential constituents within a publication package, and then an lower layer mapping this to EPUB, generic ZIP, MOBI, whatever else. The API would also connect to other API-s underneath: i.e., if the API gets to an HTML resource within the package, it would return a DOM tree of the HTML content. The API should not be bound to Javascript; it is currently drafted in Web IDL.

The discussions led to the agreement that an initial draft specification could be published as an IG Note by this Interest Group and, later, we can see how to gather enough interest and find the right format for a final specification, if there is an agreement to do so.

(Subsequent discussions converged towards the usage of “Publishing Object Model” or “Publication Object Model”, i.e., POM, as a term to be used.)

MathML situation II.

Peter Kreutzberger, from MathJax, continued the discussion started the last week.

Based on the current situation around deployment, a better direction for implementation and deployment is emphasize the server side: an implementation would turn MathML into clever HTML+CSS, meaning that the deployment effort is more closely based on the renderers as developed by the browsers. Although client-side implementations would not disappear, but the bulk of the development would be on the server. It is not unlike the usage of markdown: although there are ways to render markdown on the client on-the-fly, many HTML pages are originally written in markdown, and then converted into HTML before publishing.

The issue is then accessibility. At present, what happens often in practice that MathML is put into the HTML page with display turned off alongside a, e.g., image displaying the mathematical equation. This is done because assistive technologies do understand MathML. The alternative is to rely on ARIA: the conversion of mathematics into HTML+CSS would also add the semantics to the ARIA framework and, therefore, again be based on technologies that browsers already deploy.

The issue of polyfilling came up, i.e., whether that approach would work. It may be possible, but makes a complicated custom element structure, and it seems to be a difficult process for performance. For polyfill, you would expect developments to manipulate the DOM as if it was a normal MathML implementation, but no one is doing that. MathJax does not do polyfill because Web Components aren’t yet really available. Besides, the real problem is to render in HTML and CSS, i.e., it is better to get the rendering easier and rely on native.

DPUB IG Telco, 2015-09-14: MathML

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

(The meeting was cut shorter because the main speaker had to leave unexpectedly; the discussion topic is planned to be continued next week.)

MathML Status

Peter Kreutzberger, from MathJax, gave an overview of some of the latest developments.

The current Math WG at W3C has had a fairly low activity lately, essentially doing maintenance work only. Formally, the WG will have to be rechartered around March 2016; if the group continues to do maintenance work only, it may move into a Community Group instead. The question is what work should/could be done to move the current situation forward; this has also been discussed at the Math WG.

One area is connection with ARIA. ARIA has a glaring hole when it comes to mathematics, which makes accessibility very difficult. There is some interests from ARIA experts to fill this gap, although it is not clear whether similar interest is there from the MathML people. The other area of possible work connects to the Houdini work at the CSS WG, and would evolve around the problem mathematical layout in browser engines. The spec for math layout is very challenging in terms of CSS and this has to be looked at. There was not that much interest from the Math WG itself, but there is interest, for example, in the MathJax community. It may be possible to continue some work in the DPUB Interest Group (that, under a new charter, has the possibility to do more technical work).

One of the issue discussed was around the role of LaTeX, which is still a favorite syntax for many in the mathematical community; the question is whether that impacts the support of MathML. However, LaTeX is more about input, and can be mapped onto MathML; its relation to MathML is a bit like MarkDown vs. HTML. In this sense, this is not a real debate. Actually, publishers overwhelmingly prefer using MathML.

The level of MathML support in browsers came up. The “Can I use Math?” gives a misleading impression: WebKit went through several volunteers and failed to gain interest; Google/Chrome has some voice output but does not render Math. Gecko/Firefox is better, but they do not have their own developers on the code, it is fully volunteer effort. Although Mozilla does invest time to fix issues they create around it, but that is not enough.

MathML is very complex and math layout itself is complex, it expects a high level of typography that the Web does not yet have. Polyfill does not cut it yet, and the current implementations have major efficiency issues. Actually, the next release of MathJax may include some server side generation possibilities that may help. B.t.w., Readium includes MathJax, but many reading systems do not integrate them into their reader because they want to rely on Apple OS’s claim that they have support for it (but they don’t). Obviously, a polyfill approach also has issues with accessibility. )B.t.w., Benetech is busy setting up a description document, a matrix, showing what can be used for which engine.)

The discussion will continue next week.

DPUB IG Telco, 2015-08-31: CSS WG Meeting, Charter

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

Update on the CSS WG Meeting

The CSS WG had a face-to-face meeting last week in Paris; from this group Dave Cramer, Chris Lilley, Bert Bos, and Alan Stearns participated. They gave a report (led by Dave Cramer).

There was a fair amount of discussion on issues of interest for DPUB. The issue of displaying things in a viewport/page came up which was identified as having missing pieces; seems to be missing from the conceptual model of CSS. A new spec will be defined to bridge that gap; that is an important element for pagination in general. The CSS fragmentation spec is also progressing; these two features are essential for a more general pagination solution.

However, on the pagination in general, there is currently a gap among browser vendors and some other participants of the WG. Essentially, browser vendors regard pagination as an application feature (i.e., that should be implemented on top of the browser as a complex Web Application) as opposed to a fundamental feature that should be provided by the platform. Many non-browser participants regard, on the other hand, pagination as a fundamental feature.

For pagination in general (and the needs of the DPUB industry in particular) this means that the core layout part will solve, via the core implementation, about 70% of the needs, and the remaining 30% will have to be solved by external scripts based on the features provided by Houdini. What is in that (rougly) 70% is a very simple pagination which will interact with the viewport spec, but more complex cases like side-by-side, footnoted, sidetones, etc, will not be done.

There are, however, lots of interested people who want to push things forward; maybe subgroups will organize calls and meetings to work on these items and bring them back to the CSS WG.

Another way forward is to see whether there could be some sort of a reference and/or proof-of-concept pagination implementation that could be put out there (maybe even in open source). At the moment, all reading systems implement pagination on their own (and people are usually not proud of the code they produce); but the new possibilities of the CSS core may help in reducing the footprint of such an implementations; a proof-of-concept code would help. The best would be to seek a cooperation with, e.g., the Readium Consortium on this.

Another line of thought is to gather evidence, studies, etc, on the usefulness of pagination for long content, regardless on whether this is used in a browser or a reading system. (An example is a study of the Nielsen Norman Group “Infinite Scrolling Is Not for Every Website”.

There were also some discussion on the feedbacks received on the recent IG draft on CSS priorities at the CSS WG; some reorganization of the document may be necessary. The most important takeaway was that, maybe, a Math may warrant a separate document, due to its complexity and size.

The group also discussed to organize a more structured joint meeting with the CSS WG at the TPAC meeting in October.

New Charter

The group’s proposed new charter has been accepted by the W3C AC with flying colors. The charter enters into effect on the 1st of September, 2015; see further details in a separate blog

Miscellaneous

Next week’s meeting has been cancelled due to a US holiday.

The Digital Publishing Interest Group has been rechartered

The Digital Publishing Interest Group’s charter has been renewed as of the 1st of September, 2015. The new charter follows the footsteps of the previous charter insofar as building bridges between the technical needs of the Digital Publishing Community and the development of the Open Web Platform. Furthermore, the new charter also adopts, as a general vision for the future of Digital Publishing, the approach described in a separate white paper “Advancing Portable Documents for the Open Web Platform: EPUB+WEB”, leading to the mission description of the group:

The mission of the Digital Publishing Interest Group is to provide a technical forum for experts in the digital publishing ecosystem to hold discussions and recommend solutions regarding a future vision of Digital Publishing. The main message of that vision is that the current format- and workflow-level separation between offline/portable and online document publishing should be diminished to zero. The Interest Group will provide technical direction, identify technical issues, and outline prototype solutions for relevant Working Groups of the W3C to finalize as Web standards. This group is not chartered to publish Recommendations; instead, the goal is to cooperate with the relevant W3C Working Groups to ensure that the requirements of this particular community are met.

The groups is also planning to document draft technical solutions and, possibly, put forward proof-of-concept implementations. If some of the technical issues will warrant the creation of separate Working Groups for the purpose of formal standardization, the Interest Group will take an active role in the corresponding chartering activity.

The new charter extends the Interest Group until October 2017; the group is co-chaired by Tzviya Siegman, from John Wiley & Sons, Inc., and Markus Gylling, from the Daisy Consortium and IDPF.

DPUB IG Telco, 2015-08-24: accessibility, requirements for packaging

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

Update on accessibility

Charles LaPierre gave a short update on the work of the Accessibility Task Force. The document they plan to publish is moving along nicely, but lots of email discussions, that took place in the past few days (e.g., on MathML), drew some attention away. The main message is that we sometimes things that Digital Publishing is simple a special case of Web Publishing, but, in reality, Digital Publishing has its some different and specific needs that needs articulating when it comes to accessibility.

Subsequent discussions also drew attention on the fact that some other groups (e.g., the ISO groups working on PDF) have addressed similar issues; a cross-pollination among the groups might be useful.

Document about publishing requirement for packaging

A document called “Requirements for Web Publication and Packaging” has been finalized the past few weeks, and collects the various issues that the digital publishing community has v.a.v. packaging. The group has agreed that the document could be handed over to the Web Application Working Group that works on a Web Packaging specification.

This group still has to clarify with the Web Application WG whether the document, in its current format, is what they need. Indeed, this document has some higher level concepts (“Online State”, “Portable State”, etc.) that might go beyond what that Working Group needs, in which case an abridged version would be submitted. That will be done in the weeks to come.

Miscellaneous

The group also briefly discussed practical issues about the upcoming Technical Plenary meeting, and what topic would be discussed there.

Priorities for CSS from the Digital Publishing Interest Group (Draft)

The Digital Publishing Interest Group has published a Working Draft of Priorities for CSS from the Digital Publishing Interest Group. As publishing moves to the Open Web Platform (OWP), we hope to expand upon the range of content we are able to publish with web technologies. How content is displayed is of critical importance to how it is understood, and so we ask much of CSS. This document aims to describe our highest priorities for entirely new CSS features, implementation of CSS features that have already been specified, and even some cases where work may need to be done beyond the scope of CSS.