├── 2014.11.21 ├── figures │ └── epubweb.png └── index.html ├── 2015.01.30 ├── figures │ └── epubweb.png └── index.html ├── 2015.03.23 ├── figures │ ├── epubweb.key │ └── epubweb.png └── index.html ├── 2015.06.04 ├── figures │ ├── epubweb.png │ └── epubweb.svg └── index.html ├── 2015.06.30 ├── figures │ ├── epubweb.png │ └── epubweb.svg └── index.html ├── README.md ├── draft ├── figures │ ├── epubweb.png │ └── epubweb.svg └── index.html ├── figures ├── epubweb.png └── epubweb.svg ├── index.html ├── presentation ├── figures │ ├── auditorium.jpg │ ├── bnf.jpg │ ├── commute.jpg │ ├── contents.jpg │ ├── epubweb.png │ ├── javascript.jpg │ ├── joseph-book.png │ ├── joseph-web.png │ ├── manuals.jpg │ ├── manuscript.jpg │ └── plos.png ├── index.html ├── ribbon_w3c_idpf.png ├── ribbon_w3c_idpf.svg ├── shower │ ├── shower.min.js │ └── themes │ │ └── w3c │ │ ├── images │ │ ├── grid-16x10.svg │ │ ├── grid-4x3.svg │ │ ├── linen.png │ │ ├── linen@2x.png │ │ └── ribbon_w3c.svg │ │ ├── pictures │ │ ├── exact.png │ │ ├── square.png │ │ ├── tall.png │ │ └── wide.png │ │ └── styles │ │ ├── screen.css │ │ └── w3c-shower.css └── slides.pdf └── w3c.json /2014.11.21/figures/epubweb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/2014.11.21/figures/epubweb.png -------------------------------------------------------------------------------- /2015.01.30/figures/epubweb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/2015.01.30/figures/epubweb.png -------------------------------------------------------------------------------- /2015.03.23/figures/epubweb.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/2015.03.23/figures/epubweb.key -------------------------------------------------------------------------------- /2015.03.23/figures/epubweb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/2015.03.23/figures/epubweb.png -------------------------------------------------------------------------------- /2015.03.23/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Advancing Portable Documents for the Open Web Platform: EPUB-WEB 6 | 48 | 49 | 62 | 63 | 64 | 65 | 292 | 293 | 294 |

295 |

This white paper introduces EPUB-WEB, a vision for the future of digital publishing that is based on a fully native representation of documents within the Open Web Platform. EPUB-WEB achieves full convergence between online and offline/portable document publishing: publishers and users won't need to choose one or the other, but can switch between them dynamically, at will. 296 |

297 |

The name “EPUB-WEB” is used colloquially in this paper. The eventual effort may choose to use a completely different name that is more evocative of the larger community we want to engage; e.g. “Portable Document”, “Portable Multimedia Document”, “Offline Web Document”, “Multipart Electronic Publication“,… In what follows, for the sake of simplicity, we will use the term “EPUB-WEB”.

298 | 299 |

300 | 301 |

302 |

This is a living document which at the time of writing reflects the authors’ opinions only. Comments and suggestions are welcomed, either via the authors’ email addresses (see above) or via the github issue tracker (with a preference for the latter).

303 |

304 |

305 |

Our Vision

306 | 307 |

Our vision for EPUB-WEB is that portable documents become fully native citizens of the Open Web Platform. In this vision, the current format- and workflow-level separation between offline/portable (EPUB) and online (Web) document publishing is diminished to zero. These are merely two dynamic manifestations of the same publication: content authored with online use as the primary mode can easily be saved by the user for offline reading in portable document form. Content authored primarily for use as a portable document can be put online, without any need for refactoring the content. Publishers can choose to utilize either or both of these publishing modes, and users can choose either or both of these consumption modes. Essential features flow seamlessly between online and offline modes; examples include cross-references, user annotations, access to online databases, as well as licensing and rights management. 308 |

309 | 310 |

A portable document is a collection of content items (e.g. pages, chapters, modules, articles) structured as a single, self-contained logical unit. Individual items can consist of text, images, graphics, possibly interactive mathematical or chemical formulae, as well as audio and video. These documents by definition have a default, linear “reading order”, however the user may choose to skip around in the content just as with a book on paper; alternatively, interactive aspects of the content may alter the reading order on behalf of the user. 311 |

312 | 313 |

Several portable document formats exist. The only vendor independent and HTML based format is EPUB [[EPUB3]], which emphasizes a dynamic determination of content presentation and a closer alignment with the Open Web Platform. EPUB can represent reflowable contents as well as sequences of final-form fixed pages; depending on the publication type, an EPUB document may default to one of those. EPUB is built on Web Standards, and the individual items that make up an EPUB publication are identical to types of content on a Web site: [[html5]], [[svg]], [[css21]], [[ECMAScript]], [[JPEG]] and [[png]] images, etc.

314 | 315 |

EPUB can be viewed as simply defining a specialization of Web content that assures that a collection of content items has the needed properties of completeness and logical structure, and does so in a standard way that other processing tools and services can reliably create, manipulate, and present such collections. This completeness constraint is key for bridging the current gap between an online and offline/portable view of the same content (see section on usage patterns below). 316 |

317 | 318 |

The differences between the distinguishing characteristics of web documents and portable document can be viewed as situational and gradual rather than as representative of bright-line distinctions. Just as most of the content features of Web pages and portable documents implemented via EPUB are held in common, portable documents and documents on the Web share a desire for occasional or on-demand use of their distinguishing characteristics. Authors of HTML Web pages using CSS for styling may want pagination features. Users of Web sites want the occasional ability to download a part of a Web site for offline use with links intact to both the saved offline content and remaining content that has not been downloaded. Reliable navigation of a Web site would increase usability and accessibility. 319 |

320 | 321 |

The same content can be turned into an archived file and back without any inherent changes to the core content or associated digital assets.

324 |

325 |

326 |

Why work on this now?

327 |

EPUB can be considered to be at a tipping point. EPUB has been broadly adopted globally for trade ebooks, and is starting to gain adoption among textbook publishers as well as corporate marketing departments. However, EPUB has largely been seen as an “offline” format up until now. Various browser extensions supporting EPUB exist (Readium in Chrome, EPUB in Firefox, et al.). Other solutions exist for delivering EPUB files in browsers (Readium-Cloud, EPUB.js, Safari Books Online, et al.). Browser- and cloud-based solutions require relatively complex server and/or client software. In many cases browser- and cloud-based solutions depend on a proprietary transformation of the packaged EPUB files into formats more suitable to network delivery. A focused effort to make EPUB a first-class Open web Platform citizen will result in significant reduction in the complexity of deploying EPUB content into browsers for both online and offline consumption. Further, this focused effort will increase the momentum of EPUB and associated web adoption across communities who are looking for an open, non-proprietary, next-generation portable document format. 328 |

329 | 330 |

The broader Web Platform can also be considered to be at a tipping point. Mobile platform web site use is diminishing in favor of native applications. Hybrid applications that use web content alongside native application technology, and web-technology-based system applications are growing. The specific means of delivering hybrid and web-technology-based system applications is currently proprietary to specific applications frameworks and/or browser platforms. The point of EPUB-WEB is to increase problem solving momentum in package, metadata, and offline support applicable to both portable documents and installed applications. Open and native solutions to replace proprietary packaging, metadata, and offline support are intended to ensure the broadest possible general adoption of the Open Web Platform. 331 |

332 | 333 |

In many respect, the convergence is already happening. In a number of areas (e.g., educational publications, travel books, etc.) publishers already exploit the advanced possibilities of EPUB3 to produce highly interactive documents whose features are very close to what one is used to on the Web. A good example is Cay Horstmann’s “Big Java, Late Objects” [[BigJava]] that combines the feel of a traditional book with interactive learning materials that makes it reminiscent of similar, Web based tutorials (see the video on a companion page for the book). And the converse is also true: tutorial and introductory articles have appeared on the Web that have the quality of traditional publications that one was used to see in a scientific magazine, but combined with the interactive possibilities of the Web (Mike Bostock’s article on visualizing algorithms or Bret Victor’s article on visualization are just two of several possible examples).

334 | 335 |

The convergence of EPUB and the Open Web Platform provides a common set of solutions and opportunities to various stakeholders: 336 |

337 | 338 |

339 |

Publishers

340 |

Book publishers are investing in the development of technical expertise in web technologies. While gaining understanding of technical topics is important to new and future publishing workflows, the lack of communication between the trade publishers and web application developer communities is resulting in unnecessary duplication and investments in effort.

341 | 342 |

Collaboration between the web content development and publishing communities will result in major benefits to publishers. Adopting a universal and interoperable format means publishers can concentrate on engaging content authors in the production of high quality content. The web content development community can be relied on to deal with sophisticated technical issues (e.g., CSS, SVG). Potential future web content formats (e.g., 3D rendering) and various interactive web programs (e.g., visualization tools like D3) will naturally flow into the publishing realm through EPUB-WEB, hence increasing publishers' opportunities to sell new content products across the board.

343 | 344 |

Realizing new opportunities is a reality for publishers traditionally considered to be on the leading edge of technological advances in working with content. These publishers include STM and educational publishing houses, as well as scholarly and journal publishing organizations (see the section on scholarly publishing in this document).

345 | 346 |

A converged platform will support more tools and services and a much larger population of trained practitioners compared to the current state of working in parallel universes.

347 |

348 | 349 |

350 |

Scholarly Journal and STM Publishers

351 | 352 |

Scholarly journal publishers also provide articles for download these days. The most popular distribution format for journal articles continues to be [[PDF]] as a direct reflection of the scholarly community which highly prioritizes linear text and preservation of print typography. Indeed, the original goal for scholarly publisher to make files available online was to enable readers to download and print content directly, instead of borrowing a paper copy of a journal issue and photocopying relevant articles.

353 | 354 |

But things are changing. First of all, Web-only publications become part of the mainstream (e.g., the multidisciplinary PLOS ONE or the new PeerJ CompSci journals) with the main content being published with traditional Web technologies like HTML and CSS. And there is much more. Scholarly communication increasingly use additional media such as video, audio, animated graphics, or very large images, and the trend is to consider these as integral parts of the scientific output. (Mike Bostock’s recent article on visualizing algorithms or the “live” presentation of data in a paper published by F1000 Research are good examples for the new possibilities.) Furthermore, publishing the scientific data sources, like the results of a sociological survey or measurement output of biochemical experiments in XML or CSV formats, alongside the “main” publication, is also coming to the fore, with some journals and institutions actually requiring a public access to those. Gaining access to all these various media and contents both online and offline is important for scholars, whether the goal is to read the publication on the Web, or to download the papers for various reasons: reading the article offline, inclusion of the paper into bibliographic management systems like Mendeley or Zotero, or peer-reviewing submissions. Any offline format for scholarly purposes should be adapted to these needs.

355 | 356 |

EPUB offers a solution to many of the problems (see, e.g., [[Sigarchian]]), and those will be further enhanced by EPUB-WEB. Having an essentially identical online and offline versions of the same content, including the usage of various media, leads to similar reading experiences whether online or offline. User annotations, formal reviews, etc, performed by the scholar on a small, mobile device while being offline can be automatically synchronized with the online version as soon as there is Internet access. Being based on a general archival format, EPUB-WEB provides an easy way to consistently include video, audio, interactive scripts, any kind of data, and can naturally contain active links to the scientific data published elsewhere on the Web in case the data is too large to be distributed offline. These and other possibilities provided by EPUB-WEB may contribute to fundamentally change the way scholarly publishing works.

357 |

358 | 359 |

360 |

In-house Publishers

361 |

A special form of document production is related to technical and/or user documentation of complex products as well as complex administrative documents. Such documents are often akin to STM or scholarly publications edited by traditional trade or scholarly publishers but, often, the sheer quantity and complexity of production, as well as confidentiality requirements, mean that the production are done in-house. In many respects major corporations such as IBM, Intel, Renault, or Boeing, or institutions like the European Commission, the FAO, or the UNESCO have become specialized publishers themselves.

362 | 363 |

The quantity of documentation makes it infeasible to produce these documents in print (or print-only); instead, publishing them on the public Web or an Intranet and/or providing them through specialized mobile devices is the viable alternative. The production of these documents has similar challenges to scholarly publications like accessibility issues, portability of annotations, or the possible inclusion of complex media.

364 | 365 |

Just as for scientific publications, EPUB-WEB will provide new possibilities for these types of documents. Documentation in EPUB-WEB can be used offline in, for example, a cockpit, while being easily updated through the Web when possible. Inclusion of interactive animation, explanations, etc., become easy thanks to the possibilities provided by the Open Web Platform, whether online or offline.

366 |

367 | 368 |

369 |

Reading System developers

370 | 371 |

Reading system developers will also benefit. It is already true today that, due to the large scale use of the Open Web Platform technologies in EPUB3, reading systems often rely on existing Web browser “cores”. This means that the development of these reading systems already benefit from a level of synergy insofar as they can rely on software developments done elsewhere. Making EPUB-WEB “native” to browsers will mean that an even larger percentage of the necessary software will be available as part of the “core” and developers can concentrate on book-specific issues such as specialized user interfaces or connection to online bookstores.

372 | 373 |

But the main advantage of EPUB-WEB for reading systems is a vastly larger user base. Whilst, today, reading systems are mainly used to read traditional novels, the introduction of EPUB-WEB will open up new possibilities for, e.g., scholarly and educational use, journals and magazines, governmental usage, etc.

374 |

375 | 376 |

377 |

Web page designers

378 | 379 |

The synergy between the traditional publishing community and the Web site designers may help in greatly improving the quality of overall Web page design. Indeed, the publishing community has significant experience on issues like ergonomy, complex layout design, paged layout, or user interface problems when consuming, for example, long, elaborate, and mostly linear content. Publishers also have an experience in a proper editorial and curatory workflow in producing content, which can be easily transposed from traditional publishing to Web site production.

380 | 381 |

Another aspect of Web page design is its adaption to various environments easily. Creating documents on the Web that could be uncompromisingly displayed both on traditional screens and on mobile devices with varying screen sizes is already a growing trend today; with EPUB-WEB, users will be able to create digitally native documents easily, whether the document is viewed online or offline.

382 |

383 | 384 |

385 |

Web browsers

386 | 387 |

Generation of an offline version of a Web page (mainly in terms of very long and complex content) is an area where browsers will benefit from EPUB-WEB. Such a facility is important: when roaming charging are often high, or when internet access may be of a low quality or not available at all, users need the possibility to create, in an ad-hoc and easy manner, an offline version of the Web page they are reading. Several browsers offer such facilities already, albeit in mutually incompatible formats. Making EPUB-WEB native to a browser means to standardize an archive format that can be used through a suitable user interface by anyone using a browser. Also, some of the facilities required by reading systems are also extremely useful for “traditional” Web content; annotation facilities are an obvious example. A joint development will therefore provide a welcome addition to the core browser facilities.

388 | 389 |

It must be emphasized, however, that EPUB-WEB is not meant to create an offline version of any Web page; the emphasis is on Web documents and not to, so to say, duplicate the Web. For example, it is not the goal of EPUB-WEB to store the page of a Web-based email client. The exact boundaries and limitations will have to be properly specified alongside the work on archival formats.

390 | 391 |

Note that, technically, the inclusion of EPUB-WEB capabilities in browsers is a matter of enhancement rather than addition of completely new capabilities: because EPUB-WEB documents are based on the core Web Technologies, the “extras” to make them a native feature of the Web is limited to a smaller set of tasks like handling packages, dealing with features like reading order, dynamic pagination, and displaying tables of contents. An important goal of EPUB-WEB will be to further streamline these tasks, all while making sure it is feasible to include EPUB-WEB content handling even in mobile environments, where the computing and memory limits are more demanding.

392 |

393 | 394 |

395 |

Libraries and archival services

396 | 397 |

The archiving of digital assets is coming to the fore as a significant issue for dedicated institutions like national libraries. With the arrival of highly dynamic and possibly interactive Web documents as primary content, the traditional means of archiving (i.e., storing an XML or HTML page on some backup device for long term preservation) is no longer adequate. Web documents depend on a multitude of auxiliary files, like CSS style sheets, images, videos, javascript programs, etc. The completeness of an EPUB-WEB document has a significant role to play in this respect: combined with archiving it provides means to store the content offline, making it appropriate for archival purposes.

398 |

399 | 400 |

401 |

Users

402 | 403 |

Users will benefit, arguably the most, from a convergence of efforts between EPUB-WEB documents and other uses of Web technologies. Users will have the choice among different reading systems for the same content, ranging from specialized devices to traditional Web Browsers. Beyond the overall qualities of the reading environment the choice can also be made based on the content and usage: whereas a specialized device would work well for reading a novel on the beach, a Web browser or a high-end tablet may be preferred to consume highly interactive educational content in a class room. Publishers do not have to make this decision: users can do that. The same content can also smoothly migrate from one device or system to another, possibly carrying notes, annotations, but also the possibility to fill interactive Web forms offline (and “pushing” the results to its destination when on line again). Features for people with disabilities will also be provided consistently, whether the content is a portable document or a Web page.

404 |

405 |

406 | 407 |

408 |

Achieving convergence: work areas

409 |

Although all effort must be taken to keep as much backward compatibility as possible, the requirement(s) of EPUB-WEB will very likely mean a non-backward compatible transition from EPUB3. That being said, it must be emphasized that the major part of any EPUB3 publication, namely the content, will remain unchanged or will require only minimal changes. Indeed, the content of an EPUB3 file is based on core Open Web Platform technologies, including HTML5, SVG, or CSS3, and this will remain true for EPUB-WEB as well. The bulk of the changes are expected to occur around the accompanying constructs like publication-level metadata records, the spine, or the packaging of the content. In other words, the investments made by publishers into the transition from EPUB2 to EPUB3 (i.e., the move from XHTML1 to HTML5, from CSS2 to CSS3) are certainly not lost: the new changes would be mostly restricted to the implementation details of reading systems and production workflows. The evolution, in the past few years, of online tooling for the production of EPUB content based on the Open Web Platform (e.g., the platforms developed and used by companies like O’Reilly, Hachette, Metrodigi, or Inkling) will greatly facilitate any transition to EPUB-WEB; adapting these tools to EPUB-WEB is expected to be quite straightforward.

410 | 411 |

This section lists some of the work areas that EPUB-WEB should engage in. The list is not exhaustive and there are only hints at the technical solutions; one of the main goals of the work ahead will be to clarify the requirements and technical details. It must be emphasized that the solutions to these problems may not come from either IDPF or W3C, but possibly from other, external organizations (document identification is a typical example).

412 | 413 |

414 |

Generic archive format for the portable/offline state

415 |

A variety of formats for offline/archival storage of collections of digital resources exist today [[OCF]], [[ODF]], [[OOXML]], but none of them is universally recognized and supported across ecosystems. EPUB-WEB needs to be based on the definition of an archive format that is generic and native to the Open Web Platform, eventually with read and write support in Web browsers as well as dedicated Reading Systems and authoring tools. (Note that EPUB-WEB has more specific needs than what a general Web page may have, but this should be covered by adding information to a generic format.)

416 | 417 |

To achieve interoperability between implementations, EPUB-WEB also needs to define the process for transitioning a publication from the online to the offline/portable (a.k.a. archived) states, and vice versa.

418 | 419 |

W3C’s Web Application Working Group has published a First Working Draft for a Streamable Package Format for the Web[[web-packaging]] to encompass the needs of various applications (like installing Web Applications or downloading data for local processing). It is probably advantageous for EPUB-WEB to adopt this format, thereby being compatible with what Web Browsers may implement anyway. While this general packaging format could hypothetically be compatible with the ZIP+XML manifest format used by EPUB (and also by the Open Document Format [[ODF]]) the broader requirements of installable applications and other types of content, and efficient incremental transmission over networks, may well imply a different and incompatible packaging format. 420 |

421 |

422 | 423 |

424 |

Capturing overall publication structure

425 |

As outlined above, portable document formats in general tend to include information pertaining to the overall publication structure, such as the logical reading order(s) of the set of resources that comprise the publication (e.g. the “spine” and associated constructs in EPUB), as well as predictable user-facing meta-structures, such as one or several tables of contents or “guides”. EPUB already incorporates definitions of how to express these data based on W3C Standards such as XML and HTML. For EPUB-WEB’s requirements it may be imperative to further optimize these data structures in a way that is even more native to the Open Web Platform and more easily supported in authoring tools, browsers and Reading Systems. The Manifest for web application format [[web-manifest]] is one example of a technology that could potentially be used to achieve this goal. 426 |

427 | 428 |

Whilst these information objects are important for larger and/or more complex publications, it is unnecessary for a number of use cases for EPUB-WEB. A typical example is the archival of a document consisting of a single Web page. EPUB-WEB should therefore include the definition of a set of “defaults”, i.e., it should not require the presence of, say, a spine if the publication contains one single HTML file. Such defaults are not currently present in EPUB.

429 |

430 | 431 |

432 |

Document and fragment identification

433 |

On the web, HTTP URIs serve as the fundamental method of identifying a resource, or a fragment thereof. Among the various portable document formats available today, there is no equivalent ubiquitous method for identifying a publication that by definition does not have an HTTP address. Within the scholarly publishing industry, for example, initiatives such as DOI and CROSSREF have addressed this problem by providing explicit URN resolver services, but these services are not used by traditional “trade” publishing that rely more on ISBN related services. Also, for a universally applicable portable document format, unconditionally relying on distinct resolver services is suboptimal for a number of use cases, primarily as these may not be free of charge, and may require registration process that is not be applicable to the use case at hand.

434 | 435 |

A typical, and extremely valuable use case is in academic and scholarly publishing. There are currently several methods for citing online works (disputed among style guides), but there is no standard method for citations to ebooks. Even if a reflowable ebook is by a scholar, she must refer to PDF, paper copy, or HTML version to cite it in her bibliography. EPUB-WEB should enable stable citations.

436 | 437 |

Today’s EPUB supports a mechanism [[CFI]] for fine-grained references into a publication, but it is not defined in a manner that natively handles transitions between online and offline/portable states.

438 | 439 |

EPUB-WEB needs to define a way to utilize URI schemes for identifying documents and/or fragments thereof such that the addressing scheme does not break, nor needs to be changed, when a document transits from online to offline/portable states, or vice versa. A number of questions arise and need answers, e.g.:

440 | 441 |

What is the URI of the offline version of the document? How does that URI relate to the online identification of the content?
How does one identify the instance of a publication that “belongs to”, e.g., a specific person? This may be important if one wants to create and store, e.g., annotation to one’s own “copy” only, as opposed to the content in general.
Should there be one URI identifying the content itself, regardless of its format (e.g., whether it is online or offline)? This is akin to the issue of identifying, e.g., a book as a whole, as opposed to its delivery format (i.e., whether it is a printed or electronic).

448 | 449 |

Beyond the identification of the document as a whole, there is a further need for fragment identification, i.e., to identify “anchors” within the document. EPUB-WEB needs to include fragment identification schemes that are agnostic to the online/offline state, and that can address fragments of various kinds (e.g. resources within archives, elements with or without IDs, text ranges, time positions, etc.) and for various media types.

450 | 451 |

The W3C Annotation Working Group has a joint deliverable with the W3C Web Application Working Group called “Robust Anchoring”. This deliverable will provide a general framework for anchoring; and, although defined within the framework of annotations, the specification can also be used for other fragment identification use cases. Similarly, the W3C Media Fragments specification [[media-frags]] may prove useful to address some of the use cases. Finally, the Streamable Package Format draft, mentioned above, also includes a fragment identification mechanism. Would that package format be adopted for EPUB-WEB, that fragment identification may also come to the fore as an important mechanism to consider.

452 |

453 | 454 |

455 |

Metadata: discovery

456 |

Throughout the digital publishing industry, highly specialized metadata vocabularies and serialization forms thereof are being used. Within trade publishing as an example, ONIX [[ONIX]] has attained a dominant status as a metadata package that typically travels (in XML form) independently of the publication, and contains not only bibliographic metadata, but also trade information such as pricing. Scholarly publishing uses various derivatives of the ubiquitous BibTeX vocabulary.

457 | 458 |

While not contradicting the obvious use cases for out-of-line metadata records as used by publishers, retailers and libraries, EPUB-WEB must define a syntax for basic in-line metadata records that is agnostic to the online and offline modes. This means that the syntax must seamlessly support discovery and harvesting by both generic Web search engines, as well as dedicated bibliographic/archival/retailer systems. While it is expected that EPUB-WEB will define a minimal set of required metadata (cf. the section on identities and fragments above), development and adoption of further vocabularies in EPUB-WEB will most likely be deemed as out of scope; in other words: domain-specific metadata requirements are up to the domains themselves to define via a profiling mechanism, or similar yet-to-be-defined means.

459 | 460 |

The adoption of HTML as the vehicle for expressing publication-level metadata (i.e., using RDFa [[html-rdfa]] and/or Microdata [[microdata]] for metadata like authors or title) would have the added benefits of better I18N support than XML or JSON formats.

461 |

462 | 463 |

464 |

Styling and Layout, Pagination

465 |

As outlined in [[dpub-latinreq]] or [[jlreq]], the Open Web Platform in general, and CSS in particular, is still lacking solutions for meeting all of the publishers’ expectations on satisfactory typography and layout for digital publications. While improved presentation fidelity will be of paramount importance to the overall success and adoption rate of EPUB-WEB, it is clear that many of these issues are going to be addressed on a case-by-case basis by the CSS WG over a longer period of time. STM publishing, for example, where the faithful representation and rendering of, e.g., mathematical or chemical formulae is of a paramount importance, has particularly severe requirements that must be fulfilled by the Open Web Platform technologies. Similarly, dynamic pagination of reflowable content is not natively supported by browsers today, and as a result EPUB Reading System developers are forced to implement pagination using various ad-hoc approaches, all coming with a significant penalty in terms of development costs, performance and stability.

466 | 467 |

It is anticipated that native support for pagination (in CSS and/or in the DOM) is going to be put forward by stakeholders as a critical component of EPUB-WEB; thus the finalization of EPUB-WEB may be contingent on the availability of a native pagination model for Web content. Today’s EPUB does not define a particular pagination model for reflowable content (although work has been done on this, leading to the experimental EPUB Adaptive Layout specification [[PGT]] that has informed subsequent related work in CSS WG).

468 |

469 | 470 |

471 |

Security and privacy models

472 | 473 |

The security model of the Web, based primarily on the same-origin policy and the concept of “site”, does not apply to portable documents, as the notion of “origin” is based on HTTP properties that are invalidated/non-existent when a document transitions from its online state to the portable state. EPUB-WEB must incorporate a state agnostic security and privacy model that defines rules for both the online and portable states.

474 |

475 | 476 |

477 |

Presentation Control and Personalization

478 | 479 |

When reading long-form (and sometimes mission-critical) publications, personalization — i.e. the ability for users to adapt the presentation to suit their needs — is of a paramount importance. While technologies such as CSS Media Queries have come a long way in terms of adapting content to devices, this is not the same thing as adapting to a user. Presentation control features are often available in EPUB Reading Systems, for example the possibility to dynamically change font size or background/foreground color schemes, but implementations are brittle and limited due to the lack of an underlying framework that explicitly supports user adaptation.

480 | 481 |

EPUB-WEB needs to incorporate an explicit framework for achieving advanced and predictable user-triggered presentation control. (Note that from this perspective, accessibility can be seen just a radical case of personalization.)

482 |

483 | 484 |

485 |

Models for embracing domain-specific restrictions and extensions

486 | 487 |

Different domains of digital publishing have vastly different expectations and/or requirements on the nature of the content and their presentation. In the digital comics domain for example, the default presentation form is, traditionally at least, pre-paginated, fixed-form, and image-based media, possibly with a set of omnipresent (i.e., cross-publisher) user interaction patterns that are expected to be enabled. On the other hand, for trade publishing the default form is fully reflowable content, where user interaction patterns are defined entirely by the user agent. In educational publishing, the ability to control structure, to include rich domain-specific structural semantics and extensive specialized metadata, are at the basis for enhanced reading system behaviors, as well as predictable content discovery and repurposing.

488 | 489 |

To allow for the predictability of content within those domains that need it, EPUB-WEB needs to incorporate a notion of “profiles” that content can be authored and validated against, and that user agent implementations can use to trigger enhanced behaviors, if any. To allow for agile feature-set extensions and innovation, EPUB-WEB profiles also needs to embrace the notion of “feature addons” that can be included by a publisher without risking to invalidate the integrity and functionality of the basic publication.

490 |

491 |

492 |

493 |

Conclusions

494 |

This White Paper outlines a vision for the convergence between the Open Web Platform and portable documents while also significantly advancing and expanding the existing EPUB ecosystem. The realization of this vision would require a strong cooperation between the traditional publishing and Web communities, ideally based on a close collaboration between IDPF and the W3C and potentially other relevant organizations. While it is envisaged that most of the work could be done in one or more dedicated Working Groups (within IDPF and/or W3C), it must be emphasized that many of the features will affect and will be affected by work done elsewhere, within or outside these organizations. The starting point will be to explore and plan for the detailed technical challenges to gain a better insight into the work ahead; this exploration should be done together with the various interested communities. 495 |

496 |

497 | 498 | 499 | -------------------------------------------------------------------------------- /2015.06.04/figures/epubweb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/2015.06.04/figures/epubweb.png -------------------------------------------------------------------------------- /2015.06.04/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Advancing Portable Documents for the Open Web Platform: EPUB+WEB 6 | 48 | 49 | 62 | 63 | 64 | 65 | 292 | 293 | 294 |

295 |

This white paper introduces EPUB+WEB, a vision for the future of digital publishing that is based on a fully native representation of documents within the Open Web Platform. EPUB+WEB achieves full convergence between online and offline/portable document publishing: publishers and users won't need to choose one or the other, but can switch between them dynamically, at will. 296 |

297 |

The name “EPUB+WEB” is used colloquially in this paper. The eventual effort may choose to use a completely different name that is more evocative of the larger community we want to engage; e.g. “Portable Document”, “Portable Multimedia Document”, “Offline Web Document”, “Multipart Electronic Publication“,… In what follows, for the sake of simplicity, we will use the term “EPUB+WEB”.

298 | 299 |

300 | 301 |

302 |

303 |

304 |

305 |

Our Vision

306 | 307 |

Our vision for EPUB+WEB is that portable documents become fully native citizens of the Open Web Platform. In this vision, the current format- and workflow-level separation between offline/portable (EPUB) and online (Web) document publishing is diminished to zero. These are merely two dynamic manifestations of the same publication: content authored with online use as the primary mode can easily be saved by the user for offline reading in portable document form. Content authored primarily for use as a portable document can be put online, without any need for refactoring the content. Publishers can choose to utilize either or both of these publishing modes, and users can choose either or both of these consumption modes. Essential features flow seamlessly between online and offline modes; examples include cross-references, user annotations, access to online databases, as well as licensing and rights management. 308 |

309 | 310 |

312 | 313 |

314 | 315 |

317 | 318 |

320 | 321 |

324 |

325 |

326 |

Why work on this now?

327 |

329 | 330 |

The broader Web Platform can also be considered to be at a tipping point. Mobile platform web site use is diminishing in favor of native applications. Hybrid applications that use web content alongside native application technology, and web-technology-based system applications are growing. The specific means of delivering hybrid and web-technology-based system applications is currently proprietary to specific applications frameworks and/or browser platforms. The point of EPUB+WEB is to increase problem solving momentum in package, metadata, and offline support applicable to both portable documents and installed applications. Open and native solutions to replace proprietary packaging, metadata, and offline support are intended to ensure the broadest possible general adoption of the Open Web Platform. 331 |

332 | 333 |

334 | 335 |

The convergence of EPUB and the Open Web Platform provides a common set of solutions and opportunities to various stakeholders: 336 |

337 | 338 |

339 |

Publishers

340 |

341 | 342 |

Collaboration between the web content development and publishing communities will result in major benefits to publishers. Adopting a universal and interoperable format means publishers can concentrate on engaging content authors in the production of high quality content. The web content development community can be relied on to deal with sophisticated technical issues (e.g., CSS, SVG). Potential future web content formats (e.g., 3D rendering) and various interactive web programs (e.g., visualization tools like D3) will naturally flow into the publishing realm through EPUB+WEB, hence increasing publishers' opportunities to sell new content products across the board.

343 | 344 |

345 | 346 |

A converged platform will support more tools and services and a much larger population of trained practitioners compared to the current state of working in parallel universes.

347 |

348 | 349 |

350 |

Scholarly Journal and STM Publishers

351 | 352 |

353 | 354 |

355 | 356 |

EPUB offers a solution to many of the problems (see, e.g., [[Sigarchian]]), and those will be further enhanced by EPUB+WEB. Having an essentially identical online and offline versions of the same content, including the usage of various media, leads to similar reading experiences whether online or offline. User annotations, formal reviews, etc, performed by the scholar on a small, mobile device while being offline can be automatically synchronized with the online version as soon as there is Internet access. Being based on a general archival format, EPUB+WEB provides an easy way to consistently include video, audio, interactive scripts, any kind of data, and can naturally contain active links to the scientific data published elsewhere on the Web in case the data is too large to be distributed offline. These and other possibilities provided by EPUB+WEB may contribute to fundamentally change the way scholarly publishing works.

357 |

358 | 359 |

360 |

In-house Publishers

361 |

362 | 363 |

364 | 365 |

Just as for scientific publications, EPUB+WEB will provide new possibilities for these types of documents. Documentation in EPUB+WEB can be used offline in, for example, a cockpit, while being easily updated through the Web when possible. Inclusion of interactive animation, explanations, etc., become easy thanks to the possibilities provided by the Open Web Platform, whether online or offline.

366 |

367 | 368 |

369 |

Reading System developers

370 | 371 |

Reading system developers will also benefit. It is already true today that, due to the large scale use of the Open Web Platform technologies in EPUB3, reading systems often rely on existing Web browser “cores”. This means that the development of these reading systems already benefit from a level of synergy insofar as they can rely on software developments done elsewhere. Making EPUB+WEB “native” to browsers will mean that an even larger percentage of the necessary software will be available as part of the “core” and developers can concentrate on book-specific issues such as specialized user interfaces or connection to online bookstores.

372 | 373 |

But the main advantage of EPUB+WEB for reading systems is a vastly larger user base. Whilst, today, reading systems are mainly used to read traditional novels, the introduction of EPUB+WEB will open up new possibilities for, e.g., scholarly and educational use, journals and magazines, governmental usage, etc.

374 |

375 | 376 |

377 |

Web page designers

378 | 379 |

380 | 381 |

Another aspect of Web page design is its adaption to various environments easily. Creating documents on the Web that could be uncompromisingly displayed both on traditional screens and on mobile devices with varying screen sizes is already a growing trend today; with EPUB+WEB, users will be able to create digitally native documents easily, whether the document is viewed online or offline.

382 |

383 | 384 |

385 |

Web browsers

386 | 387 |

Generation of an offline version of a Web page (mainly in terms of very long and complex content) is an area where browsers will benefit from EPUB+WEB. Such a facility is important: when roaming charging are often high, or when internet access may be of a low quality or not available at all, users need the possibility to create, in an ad-hoc and easy manner, an offline version of the Web page they are reading. Several browsers offer such facilities already, albeit in mutually incompatible formats. Making EPUB+WEB native to a browser means to standardize an archive format that can be used through a suitable user interface by anyone using a browser. Also, some of the facilities required by reading systems are also extremely useful for “traditional” Web content; annotation facilities are an obvious example. A joint development will therefore provide a welcome addition to the core browser facilities.

388 | 389 |

It must be emphasized, however, that EPUB+WEB is not meant to create an offline version of any Web page; the emphasis is on Web documents and not to, so to say, duplicate the Web. For example, it is not the goal of EPUB+WEB to store the page of a Web-based email client. The exact boundaries and limitations will have to be properly specified alongside the work on archival formats.

390 | 391 |

Note that, technically, the inclusion of EPUB+WEB capabilities in browsers is a matter of enhancement rather than addition of completely new capabilities: because EPUB+WEB documents are based on the core Web Technologies, the “extras” to make them a native feature of the Web is limited to a smaller set of tasks like handling packages, dealing with features like reading order, dynamic pagination, and displaying tables of contents. An important goal of EPUB+WEB will be to further streamline these tasks, all while making sure it is feasible to include EPUB+WEB content handling even in mobile environments, where the computing and memory limits are more demanding.

392 |

393 | 394 |

395 |

Libraries and archival services

396 | 397 |

The archiving of digital assets is coming to the fore as a significant issue for dedicated institutions like national libraries. With the arrival of highly dynamic and possibly interactive Web documents as primary content, the traditional means of archiving (i.e., storing an XML or HTML page on some backup device for long term preservation) is no longer adequate. Web documents depend on a multitude of auxiliary files, like CSS style sheets, images, videos, javascript programs, etc. The completeness of an EPUB+WEB document has a significant role to play in this respect: combined with archiving it provides means to store the content offline, making it appropriate for archival purposes.

398 |

399 | 400 |

401 |

Users

402 | 403 |

Users will benefit, arguably the most, from a convergence of efforts between EPUB+WEB documents and other uses of Web technologies. Users will have the choice among different reading systems for the same content, ranging from specialized devices to traditional Web Browsers. Beyond the overall qualities of the reading environment the choice can also be made based on the content and usage: whereas a specialized device would work well for reading a novel on the beach, a Web browser or a high-end tablet may be preferred to consume highly interactive educational content in a class room. Publishers do not have to make this decision: users can do that. The same content can also smoothly migrate from one device or system to another, possibly carrying notes, annotations, but also the possibility to fill interactive Web forms offline (and “pushing” the results to its destination when on line again). Features for people with disabilities will also be provided consistently, whether the content is a portable document or a Web page.

404 |

405 |

406 | 407 |

408 |

Achieving convergence: work areas

409 |

Although all effort must be taken to keep as much backward compatibility as possible, the requirement(s) of EPUB+WEB will very likely mean a non-backward compatible transition from EPUB3. That being said, it must be emphasized that the major part of any EPUB3 publication, namely the content, will remain unchanged or will require only minimal changes. Indeed, the content of an EPUB3 file is based on core Open Web Platform technologies, including HTML5, SVG, or CSS3, and this will remain true for EPUB+WEB as well. The bulk of the changes are expected to occur around the accompanying constructs like publication-level metadata records, the spine, or the packaging of the content. In other words, the investments made by publishers into the transition from EPUB2 to EPUB3 (i.e., the move from XHTML1 to HTML5, from CSS2 to CSS3) are certainly not lost: the new changes would be mostly restricted to the implementation details of reading systems and production workflows. The evolution, in the past few years, of online tooling for the production of EPUB content based on the Open Web Platform (e.g., the platforms developed and used by companies like O’Reilly, Hachette, Metrodigi, or Inkling) will greatly facilitate any transition to EPUB+WEB; adapting these tools to EPUB+WEB is expected to be quite straightforward.

410 | 411 |

This section lists some of the work areas that EPUB+WEB should engage in. The list is not exhaustive and there are only hints at the technical solutions; one of the main goals of the work ahead will be to clarify the requirements and technical details. It must be emphasized that the solutions to these problems may not come from either IDPF or W3C, but possibly from other, external organizations (document identification is a typical example).

412 | 413 |

414 |

Generic archive format for the portable/offline state

415 |

A variety of formats for offline/archival storage of collections of digital resources exist today [[OCF]], [[ODF]], [[OOXML]], but none of them is universally recognized and supported across ecosystems. EPUB+WEB needs to be based on the definition of an archive format that is generic and native to the Open Web Platform, eventually with read and write support in Web browsers as well as dedicated Reading Systems and authoring tools. (Note that EPUB+WEB has more specific needs than what a general Web page may have, but this should be covered by adding information to a generic format.)

416 | 417 |

To achieve interoperability between implementations, EPUB+WEB also needs to define the process for transitioning a publication from the online to the offline/portable (a.k.a. archived) states, and vice versa.

418 | 419 |

W3C’s Web Application Working Group has published a First Working Draft for a Streamable Package Format for the Web[[web-packaging]] to encompass the needs of various applications (like installing Web Applications or downloading data for local processing). It is probably advantageous for EPUB+WEB to adopt this format, thereby being compatible with what Web Browsers may implement anyway. While this general packaging format could hypothetically be compatible with the ZIP+XML manifest format used by EPUB (and also by the Open Document Format [[ODF]]) the broader requirements of installable applications and other types of content, and efficient incremental transmission over networks, may well imply a different and incompatible packaging format. 420 |

421 | 422 |

The IETF has published an informational draft on a top-level media type for archives. Although that draft does not specify a specific archive format it shows the overall interest in packaging on the Web, in line with the concerns of EPUB+WEB.

423 |

424 | 425 |

426 |

Capturing overall publication structure

427 |

As outlined above, portable document formats in general tend to include information pertaining to the overall publication structure, such as the logical reading order(s) of the set of resources that comprise the publication (e.g. the “spine” and associated constructs in EPUB), as well as predictable user-facing meta-structures, such as one or several tables of contents or “guides”. EPUB already incorporates definitions of how to express these data based on W3C Standards such as XML and HTML. For EPUB+WEB’s requirements it may be imperative to further optimize these data structures in a way that is even more native to the Open Web Platform and more easily supported in authoring tools, browsers and Reading Systems. The Manifest for web application format [[web-manifest]] is one example of a technology that could potentially be used to achieve this goal. 428 |

429 | 430 |

Whilst these information objects are important for larger and/or more complex publications, it is unnecessary for a number of use cases for EPUB+WEB. A typical example is the archival of a document consisting of a single Web page. EPUB+WEB should therefore include the definition of a set of “defaults”, i.e., it should not require the presence of, say, a spine if the publication contains one single HTML file. Such defaults are not currently present in EPUB.

431 |

432 | 433 |

434 |

Document and fragment identification

435 |

436 | 437 |

438 | 439 |

440 | 441 |

EPUB+WEB needs to define a way to utilize URI schemes for identifying documents and/or fragments thereof such that the addressing scheme does not break, nor needs to be changed, when a document transits from online to offline/portable states, or vice versa. A number of questions arise and need answers, e.g.:

442 | 443 |

What is the URI of the offline version of the document? How does that URI relate to the online identification of the content?
How does one identify the instance of a publication that “belongs to”, e.g., a specific person? This may be important if one wants to create and store, e.g., annotation to one’s own “copy” only, as opposed to the content in general.
Should there be one URI identifying the content itself, regardless of its format (e.g., whether it is online or offline)? This is akin to the issue of identifying, e.g., a book as a whole, as opposed to its delivery format (i.e., whether it is a printed or electronic).

450 | 451 |

Beyond the identification of the document as a whole, there is a further need for fragment identification, i.e., to identify “anchors” within the document. EPUB+WEB needs to include fragment identification schemes that are agnostic to the online/offline state, and that can address fragments of various kinds (e.g. resources within archives, elements with or without IDs, text ranges, time positions, etc.) and for various media types.

452 | 453 |

The W3C Annotation Working Group has a joint deliverable with the W3C Web Application Working Group called “Robust Anchoring”. This deliverable will provide a general framework for anchoring; and, although defined within the framework of annotations, the specification can also be used for other fragment identification use cases. Similarly, the W3C Media Fragments specification [[media-frags]] may prove useful to address some of the use cases. Finally, the Streamable Package Format draft, mentioned above, also includes a fragment identification mechanism. Would that package format be adopted for EPUB+WEB, that fragment identification may also come to the fore as an important mechanism to consider.

454 |

455 | 456 |

457 |

Metadata: discovery

458 |

459 | 460 |

While not contradicting the obvious use cases for out-of-line metadata records as used by publishers, retailers and libraries, EPUB+WEB must define a syntax for basic in-line metadata records that is agnostic to the online and offline modes. This means that the syntax must seamlessly support discovery and harvesting by both generic Web search engines, as well as dedicated bibliographic/archival/retailer systems. While it is expected that EPUB+WEB will define a minimal set of required metadata (cf. the section on identities and fragments above), development and adoption of further vocabularies in EPUB+WEB will most likely be deemed as out of scope; in other words: domain-specific metadata requirements are up to the domains themselves to define via a profiling mechanism, or similar yet-to-be-defined means.

461 | 462 |

463 |

464 | 465 |

466 |

Styling and Layout, Pagination

467 |

As outlined in [[dpub-latinreq]] or [[jlreq]], the Open Web Platform in general, and CSS in particular, is still lacking solutions for meeting all of the publishers’ expectations on satisfactory typography and layout for digital publications. While improved presentation fidelity will be of paramount importance to the overall success and adoption rate of EPUB+WEB, it is clear that many of these issues are going to be addressed on a case-by-case basis by the CSS WG over a longer period of time. STM publishing, for example, where the faithful representation and rendering of, e.g., mathematical or chemical formulae is of a paramount importance, has particularly severe requirements that must be fulfilled by the Open Web Platform technologies. Similarly, dynamic pagination of reflowable content is not natively supported by browsers today, and as a result EPUB Reading System developers are forced to implement pagination using various ad-hoc approaches, all coming with a significant penalty in terms of development costs, performance and stability.

468 | 469 |

It is anticipated that native support for pagination (in CSS and/or in the DOM) is going to be put forward by stakeholders as a critical component of EPUB+WEB; thus the finalization of EPUB+WEB may be contingent on the availability of a native pagination model for Web content. Today’s EPUB does not define a particular pagination model for reflowable content (although work has been done on this, leading to the experimental EPUB Adaptive Layout specification [[PGT]] that has informed subsequent related work in CSS WG).

470 | 471 |

Note that the “Houdini” Task Force, recently started jointly by the W3C CSS WG and the W3C TAG, may open new avenues to handle pagination.

472 |

473 | 474 |

475 |

Security Models

476 | 477 |

The security model of the Web, based primarily on the same-origin policy and the concept of “site”, does not apply to portable documents, as the notion of “origin” is based on HTTP properties that are invalidated/non-existent when a document transitions from its online state to the portable state. EPUB+WEB must incorporate a state agnostic security model that defines rules for both the online and portable states.

478 |

479 | 480 |

481 |

Presentation Control and Personalization

482 | 483 |

484 | 485 |

EPUB+WEB needs to incorporate an explicit framework for achieving advanced and predictable user-triggered presentation control. (Note that from this perspective, accessibility can be seen just a radical case of personalization.)

486 |

487 | 488 |

489 |

Models for embracing domain-specific restrictions and extensions

490 | 491 |

492 | 493 |

To allow for the predictability of content within those domains that need it, EPUB+WEB needs to incorporate a notion of “profiles” that content can be authored and validated against, and that user agent implementations can use to trigger enhanced behaviors, if any. To allow for agile feature-set extensions and innovation, EPUB+WEB profiles also needs to embrace the notion of “feature addons” that can be included by a publisher without risking to invalidate the integrity and functionality of the basic publication.

494 |

495 |

496 |

497 |

Conclusions

498 |

500 |

501 | 502 | 503 | -------------------------------------------------------------------------------- /2015.06.30/figures/epubweb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/2015.06.30/figures/epubweb.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Advancing Portable Documents for the Open Web Platform: EPUB-WEB 2 | =============================================================== 3 | 4 | ***This Repo should be considered as closed now. The work has been transferred to the [DPUB Interest Group](http://www.w3.org/dpub/IG/) and is now part of the deliverables of that group. See the [new repo](https://github.com/w3c/dpub-pwp) for the continuation work. (2015-09-26)*** 5 | 6 | 7 | Markus Gylling (), Ivan Herman (). 8 | -------------------------------------------------------------------------------- /draft/figures/epubweb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/draft/figures/epubweb.png -------------------------------------------------------------------------------- /figures/epubweb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/figures/epubweb.png -------------------------------------------------------------------------------- /presentation/figures/auditorium.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/auditorium.jpg -------------------------------------------------------------------------------- /presentation/figures/bnf.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/bnf.jpg -------------------------------------------------------------------------------- /presentation/figures/commute.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/commute.jpg -------------------------------------------------------------------------------- /presentation/figures/contents.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/contents.jpg -------------------------------------------------------------------------------- /presentation/figures/epubweb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/epubweb.png -------------------------------------------------------------------------------- /presentation/figures/javascript.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/javascript.jpg -------------------------------------------------------------------------------- /presentation/figures/joseph-book.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/joseph-book.png -------------------------------------------------------------------------------- /presentation/figures/joseph-web.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/joseph-web.png -------------------------------------------------------------------------------- /presentation/figures/manuals.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/manuals.jpg -------------------------------------------------------------------------------- /presentation/figures/manuscript.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/manuscript.jpg -------------------------------------------------------------------------------- /presentation/figures/plos.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/figures/plos.png -------------------------------------------------------------------------------- /presentation/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Advancing Portable Documents for the Open Web Platform: EPUB-WEB 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 45 | 46 | 47 |

48 |

49 | Advancing Portable Documents for the Open Web Platform: EPUB-WEB 50 |

51 |

2014-11-26

52 |

53 | 54 | 55 | Markus Gylling, IDPF, and 56 | Ivan Herman, 57 | W3C 58 | 59 |

60 |

62 | This work is licensed under a Creative 63 | Commons Attribution 3.0 License, with attribution to W3C and IDPF

65 |

68 |

69 |

70 |

71 |

72 | Bridging the Web and Digital Publishing: EPUB-WEB 73 |

74 |

75 | 76 | 77 | Markus Gylling, IDPF, and 78 | Ivan Herman, 79 | W3C 80 | 81 |

82 |

2014-11-26

83 |

85 | This work is licensed under a Creative 86 | Commons Attribution 3.0 License, with attribution to W3C and IDPF
88 | Copyright ^©2014 IDPF^® and ^©2014 W3C^® (MIT, ERCIM, Keio, Beihang) 89 |

90 |

91 |

92 |

93 |

94 |

95 | EPUB-WEB is a vision for the future 96 |

97 |

100 |

101 |

102 |

103 |

104 |

105 | The vision 106 |

107 |

Portable documents are fully native citizen of the Open Web Platform
Separation between online (i.e., the “Web”) and portable (i.e., “EPUB”) is diminished to zero
This means:

Content authored for primarily offline use can be used online by loading it into a browser
Content authored for primarily online use can be easily saved as a portable document for offline use
These should be doable smoothly, solely based on the user’s interaction

117 |

118 |

119 |

120 |

121 |

122 | The vision 123 |

124 |

Publishers can choose to utilize either or both of these publishing modes
Users can choose either or both of these consumption modes
Essential features flow seamlessly between on-line and off-line modes, like 128 |
- cross-references, user annotations, access to on-line databases
- licensing and rights management
- etc.
133 |

135 |

136 |

137 | 138 |

139 |

140 |

141 | Why bother? 142 |

143 |

144 |

145 |

146 |

147 |

EPUB at an inflection point

148 |

EPUB 3 is getting adopted by publishers
But rendering EPUB 3 requires:

browser extensions; or
significant development on top of “browser cores” for software/hardware solutions

EPUB as “first class Web citizen” would mean an easier and quicker deployment

157 |

158 |

159 |

160 |

161 |

Web Platform at an inflection point

162 |

Usage of (mobile) apps come to the fore (although often based on the same “browser cores”)
EPUB-WEB development would go in parallel with the development of general issues like packaging, metadata, or offline support

166 |

167 |

168 | 169 |

170 |

171 |

172 | A number of use cases… 173 |

174 |

175 |

176 | 177 |

178 |

179 |

180 | For example: book in a browser 181 |

182 |

Joseph Reagle's book as a web page — Extract of Joseph Reaggle’s PhD on the Web

186 |

On a desktop I may want to read a book just like a Web page: 188 |
- easily follow a link “out” of the book
- create bookmarks “into” a page in a book
- use useful plugins and tools that my browser may have
193 |

195 |

196 |

197 |

198 |

199 |

200 | For example: book in a browser (cont.) 201 |

202 |

Joseph Reagle's book as an ebook in a browser — Extract of Joseph Reaggle’s PhD as ePUB

206 |

But:

my book may be 2000 pages long
conventional Web browsing may not be the right way to view content, a paginated view may be better
I may also want to use a small dedicated reader device to read the book on the beach…

All this should happen using the same book, and not a conversion from one format to the other!

215 |

216 |

217 |

218 |

219 |

220 | For example: I may not be online… 221 |

222 |

Person sitting in a station with a mobile in hand — Photo credit: Bryan Ong, Flickr

226 |

I may find an article on the Web that I want to review, annotate, etc., while commuting home on a train
I want the results of the annotations to be back online, when I am back on the Internet
Note: some browsers have an “archiving” possibility, but they are not interoperable 230 |
- the content can definitely no be read on a dedicated reader
231 |

232 |

233 |

234 |

235 |

236 |

237 | For example: scholarly publishing 238 |

239 |

Screen dump of a PLOS 1 page — Screen dump of “Web based applications” on PLOS 1

243 |

My paper is published, primarily, on-line, but people may want to download it for offline use
The format of the paper should be adaptable to my reading environment 246 |
- do not want a two column, fixed layout file that I cannot handle on my iPad…
249 |
My “paper” may also contain video, audio, data, programs… 251 |
- scholarly publishing is not text only any more!
254 |

256 |

257 |

258 |

259 |

260 |

261 | For example: in-house publishing 262 |

263 |

Bookshelf full of documentation — Photo credit: Petdro Agüera, Flickr

267 |

Major companies (IBM, Intel, Boeing, FAO, Renault,…) are specialized publishers through the publication of huge amount of documentation
Delivering it on paper is not an option any more
Fast refresh time is needed
The same document should be available offline (e.g., in the cockpit) or online (e.g., on the work floor): there should be no difference between the two

273 |

274 |

275 |

276 |

277 |

278 | For example: archival and preservation 279 |

280 |

Image of a hall at the Bibliothèque National de France — Photo credit: Vincent Dejardin, Flickr

284 |

Archiving digital assets (i.e., Web pages with all dependencies) is a major problem
There is a need to produce, easily, a complete version of a page to be stored through archival facilities

288 |

289 |

290 |

291 |

292 |

293 | For example: educational materials 294 |

295 |

University hall with students, most of them with a tablet — Photo credit: Merrill College of Journalism, Flickr

299 |

What is an educational publication?

A book of possibly long texts that requires offline access on dedicated devices?
A packaged application with built-in interactive tests, animated examples?
A Web client reaching out to Web services for assessing test results, to encyclopedia, …?
An interactive data container storing various data for, e.g., demonstrations?

The borderline between a “book” and a “(Web) Application” are becoming blurred!

309 |

310 |

311 |

312 |

313 |

314 | Synergy effects of convergence 315 |

316 |

317 |

318 |

319 |

320 |

321 | Advantage for publishers‘ community 322 |

323 |

Photo of two javascript books — Photo credit: Nathan Smith, Flickr

327 |

Publishers want to concentrate on what they know better: how to produce, edit, curate, etc, great content
Publishers are not technology companies, nor do they intend to be; they want instead to rely on the vibrant Web community!

331 |

332 |

333 |

334 |

335 |

336 | Advantage for the Web community 337 |

338 |

image of a medieval manuscript — Photo credit: e-codices, Flickr

342 |

Publishers have a long experience in ergonomy, typography, paging, complex layout, etc.
Publishing long texts, with the right aesthetics, readability, structure, etc., is an expertise the Web community can profit from
Experience of publishers in the complete curatory workflow for producing content may become important for Web design

347 |

348 |

349 |

350 |

351 |

Some communities that may be affected

352 | 353 | 354 | 355 | 356 | 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 | 365 | 366 | 367 | 368 | 369 | 370 | 371 |

(Trade) Publishers	STM Publishers
Browser vendors	Large companies
Governmental bodies	International institutions
Consumers of ebooks	Scholarly authors
Web designers	Archivists
Web Developers	Publishing workflows

372 |

373 |

374 |

375 |

376 |

377 | How do we get there? (Technically) 378 |

379 |

380 |

381 |

382 |

383 |

384 | How do we get there? 385 |

386 |

A strong cooperation between the different communities should be ensured
Technical challenges must be identified
A new generation of EPUB (“EPUB-WEB”) has to be specified

391 |

In what follows some of the main technical issues will be highlighted

392 |

393 |

394 |

395 |

396 |

397 | Archival format 398 |

399 |

EPUB is based on ZIP
There is no standard packaging format for browsers yet… 402 |
- although there is a need for, e.g., applications or data sets
405 |
… but ZIP may not be the right approach on the Web 407 |
- Multipart Mime may be an alternative
410 |
There is a new work item at W3C on packaging standard whicht may affect EPUB-WEB

413 |

414 |

415 |

416 |

417 |

418 | Overall document structure 419 |

420 |

A complete, offline content needs additional information 422 |
- list of all necessary content, default reading order, etc.
- in EPUB these are stored in additional, auxilliary files (“spine”, etc.)
- these may have to be adapted to EPUB-WEB (e.g., usage of JSON instead of XML)
427 |
But these data may not be necessary for a simple Web page with a few CSS files 429 |
- i.e., some sort of a default structure should be defined
432 |
User interaction paradigms should also be developed to create documents from more complex Web sites easily

435 |

436 |

437 |

438 |

439 |

440 | Identification 441 |

442 |

A consise and unique identification for the document (e.g., the “work”) under various usage patterns is necessary

i.e., what is the URI for… 446 |
- Shakespeare's Hamlet?
- its digital edition published by Publisher XYZ?
- the copy I own and annotate?
451 |

This is necessary to make a book a first-class citizen on the Web

455 |

B.t.w., this is already the topic for debates in the publishing and library communities…

456 |

457 |

458 |

459 |

460 |

461 | Identification (cont.) 462 |

463 |

Unique identification of the work is not enough
A fragment identification framework is also necessary to link into the document
There are fragments defined for various media, but a universal model, workable for browsers, is still missing 467 |
- these should be agnostic to offline vs. online state, to media type, etc.
470 |

472 |

Works are already ongoing within the framework of activities around annotations

473 |

474 |

475 |

476 |

477 |

Metadata

478 |

EPUB-WEB must make use of browser friendly metadata formats (RDFa, JSON-LD, µdata) to carry metadata
EPUB-WEB should also provide means to link to external metadata
A typical area where a solution for identification (including fragment identification) is essential

483 |

484 |

485 |

486 |

487 |

488 | Improvement on styling 489 |

490 |

Books usually need higher quality typesetting than average Web pages 492 |
- control over fine aspects of drop caps, alignments, justification, hyphenation, bleeds, etc.
- cf. http://www.w3.org/TR/dpub-latinreq/
496 |

498 |

499 |

500 |

501 |

502 |

503 | Pagination, numbering, indexing 504 |

505 |

What is a “page” for an electronic content? 507 |
- is this a new CSS concept? Do we need an extension to the DOM?
510 |
In general, content may be placed into linked regions
References (page numbers, references to pictures or diagrams, bibliographic references, etc.) should have robust mechanism across several documents/regions

e.g., if the book’s chapters are stored in different files
page numbers can dynamically change as a result of user interaction, e.g., larger fonts
numbering of items should be automatically continuous across documents

519 |

520 |

521 |

522 |

523 |

524 | Security and Privacy 525 |

526 |

The Web/browser mechanism is based on the control per “site”, or a ”web page”, largely based on user/password
Current publishing practices are very divergent (strict DRM, watermarking, social DRM, etc.)
A consensus solution will be needed

531 |

532 |

533 |

534 |

535 |

536 | Presentation control 537 |

538 |

What is the level of user control of the presentation? 540 |
The Web and eBook traditions are vastly different: 542 |
- In a browser, the Web designer is in full control 544 |
  - CSS alternate style sheets are hardly in use
  - some user interface aspects can be controlled but only for the browser as a whole
  548 |
- In an eBook reader, there may be more user control 550 |
  - foreground/background color
  - choice of fonts
  554 |
556 |
There is a need to reconcile these traditions

559 |

560 |

561 |

562 |

563 |

564 | How do we get there? (Practically) 565 |

566 |

567 |

568 |

569 |

570 |

571 | What is next? 572 |

573 |

We collect comments on this vision

collecting (public or private comments) to the White Paper
discussions at various events with the communities at large
internal discussions at IDPF and W3C

Develop a more specific roadmap

what are the specific technical specifications that have to be developed?
what other work should be “influenced”?
what groups should be set up at IDPF and/or W3C?

Regular updates of the White Paper based on the comments

588 |

589 |

590 |

591 |

592 |

593 | If there is a consensus 594 |

595 |

Work with existing IDPF and W3C groups, where necessary, on specific details
Set up a new group (or groups) to define the EPUB-WEB specific issues

599 |

600 |

601 |

602 |

603 |

604 | Conclusion 605 |

606 |

There is a great potential in a convergence between the Open Web Platform and Portable Documents
It will require a common effort and cooperation of both communities
But it is an exciting prospect!

611 |

612 |

613 |

614 |

615 |

616 |

617 |

618 |

Some pointers

619 |

White paper:

http://w3c.github.io/epubweb/

Issue list:

https://github.com/w3c/epubweb/issues

These slides:

http://w3c.github.io/epubweb/presentation

Direct contacts:

628 |

Markus Gylling, IDPF: mgylling@idpf.org
Ivan Herman, W3C: ivan@w3.org

634 |

636 |

637 |

638 |

639 |

640 |

641 | Thank you for your attention 642 |

643 |

644 |

645 |

646 | 647 | 648 | 649 | -------------------------------------------------------------------------------- /presentation/ribbon_w3c_idpf.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/ribbon_w3c_idpf.png -------------------------------------------------------------------------------- /presentation/ribbon_w3c_idpf.svg: -------------------------------------------------------------------------------- 1 | 2 | 4 | ]> 5 | 6 | 99 | -------------------------------------------------------------------------------- /presentation/shower/shower.min.js: -------------------------------------------------------------------------------- 1 | /** 2 | * Core for Shower HTML presentation engine 3 | * shower-core v1.0.3, https://github.com/shower/core 4 | * @copyright 2010–2014 Vadim Makeev, http://pepelsbey.net 5 | * @license MIT license: github.com/shower/shower/wiki/MIT-License 6 | */ 7 | window.shower&&window.shower.init||(window.shower=function(a,b,c){function d(a){for(var b in a)a.hasOwnProperty(b)&&(this[b]=a[b])}var e,f={},g=a.location,h=a.console,i=[],j=[],k=!(!a.history||!a.history.pushState);f.debugMode=!1,d.prototype={getSlideNumber:function(){return this.number},isLast:function(){return f.slideList.length===this.number+1},isFinished:function(){return this.innerComplete>=this.innerLength},process:function(a){return this.timing?(this.initTimer(a),this):(this.next(a),this)},initTimer:function(a){var b=this;return b.timing?(b.stopTimer(),e=b.isFinished()?setInterval(function(){b.stopTimer(),a.next()},b.timing*(b.innerLength||1)):setInterval(function(){b.isFinished()?(b.stopTimer(),a.next()):b.next(a)},b.timing),this):!1},stopTimer:function(){return e&&(clearInterval(e),e=!1),this},prev:function(a){var c,d=this;return!d.hasInnerNavigation||d.isFinished()||0===d.innerComplete?(a.prev(),!1):(c=b.getElementById(d.id).querySelectorAll(".next.active"),!c||c.length<1?!1:(d.innerComplete>0?(d.innerComplete--,c[c.length-1].classList.remove("active")):a.prev(),this))},next:function(a){var c,d=this;return!d.hasInnerNavigation||d.isFinished()?(a.next(),!1):(d.isFinished()||(c=b.getElementById(d.id).querySelectorAll(".next:not(.active)"),c[0].classList.add("active"),d.innerComplete++),this)}},f._getData=function(a,b){return a.dataset?a.dataset[b]:a.getAttribute("data-"+b)},f.slideList=[],f.init=function(a,c){var e;f.debugMode&&(body.classList.add("debug"),h.log("Debug mode on")),a=a||".slide",c=c||"div.progress div",i=b.querySelectorAll(a),j=b.querySelector(c);for(var g=0;g=0&&f.go(a),c&&f.enterSlideMode()},f._getTransform=function(){var c=Math.max(b.body.clientWidth/a.innerWidth,b.body.clientHeight/a.innerHeight);return"scale("+1/c+")"},f._applyTransform=function(a){return["WebkitTransform","MozTransform","msTransform","OTransform","transform"].forEach(function(c){b.body.style[c]=a}),!0},f._isNumber=function(a){return!isNaN(parseFloat(a))&&isFinite(a)},f._normalizeSlideNumber=function(a){if(!f._isNumber(a))throw new Error("Gimme slide number as Number, baby!");return 0>a&&(a=0),a>=f.slideList.length&&(a=f.slideList.length-1),a},f._getSlideIdByEl=function(a){for(;"BODY"!==a.nodeName&&"HTML"!==a.nodeName;){if(a.classList.contains("slide"))return a.id;a=a.parentNode}return""},f._checkInteractiveElement=function(a){return"A"===a.target.nodeName},f.getSlideNumber=function(a){var b,c=f.slideList.length-1;for(""===a&&(b=0);c>=0;--c)if(a===f.slideList[c].id){b=c;break}return b},f.go=function(a,b){var c;if(!f._isNumber(a))throw new Error("Gimme slide number as Number, baby!");return f.slideList[a]?(g.hash=f.getSlideHash(a),f.updateProgress(a),f.updateActiveAndVisitedSlides(a),f.isSlideMode()&&(f.showPresenterNotes(a),c=f.slideList[a],c.timing&&c.initTimer(f)),"function"==typeof b&&b(),a):!1},f.next=function(a){var b=f.getCurrentSlideNumber(),c=f.slideList[b+1];return c?(f.go(b+1),"function"==typeof a&&a(),this):!1},f._turnNextSlide=function(a){var b=f.getCurrentSlideNumber(),c=f.slideList[b];f.isSlideMode()?(c.stopTimer(),c.next(f)):f.go(b+1),"function"==typeof a&&a()},f.prev=f.previous=function(a){var b=f.getCurrentSlideNumber();return 1>b?!1:(f.go(b-1),"function"==typeof a&&a(),!0)},f._turnPreviousSlide=function(a){var b=f.getCurrentSlideNumber(),c=f.slideList[b];return c.stopTimer(),f.isSlideMode()?c.prev(f):f.go(b-1),"function"==typeof a&&a(),!0},f.first=function(a){var b=f.slideList[f.getCurrentSlideNumber()];b&&b.timing&&b.stopTimer(),f.go(0),"function"==typeof a&&a()},f.last=function(a){var b=f.slideList[f.getCurrentSlideNumber()];b&&b.timing&&b.stopTimer(),f.go(f.slideList.length-1),"function"==typeof a&&a()},f.enterSlideMode=function(a){var c=f.getCurrentSlideNumber();return b.body.classList.remove("list"),b.body.classList.add("full"),f.isListMode()&&k&&history.pushState(null,null,g.pathname+"?full"+f.getSlideHash(c)),f._applyTransform(f._getTransform()),"function"==typeof a&&a(),!0},f.enterListMode=function(a){var c;return b.body.classList.remove("full"),b.body.classList.add("list"),f.clearPresenterNotes(),f._applyTransform("none"),f.isListMode()?!1:(c=f.getCurrentSlideNumber(),f.slideList[c].stopTimer(),f.isSlideMode()&&k&&history.pushState(null,null,g.pathname+f.getSlideHash(c)),f.scrollToSlide(c),"function"==typeof a&&a(),!0)},f.toggleMode=function(a){return f.isListMode()?f.enterSlideMode():f.enterListMode(),"function"==typeof a&&a(),!0},f.getCurrentSlideNumber=function(){var a=f.slideList.length-1,b=g.hash.substr(1);if(""===b)return-1;for(;a>=0;--a)if(b===f.slideList[a].id)return a;return-1},f.scrollToSlide=function(c){var d,e=!1;if(!f._isNumber(c))throw new Error("Gimme slide number as Number, baby!");if(f.isSlideMode())throw new Error("You can't scroll to because you in slide mode. Please, switch to list mode.");if(-1===c)return e;if(!f.slideList[c])throw new Error("There is no slide with number "+c);return d=b.getElementById(f.slideList[c].id),a.scrollTo(0,d.offsetTop),e=!0,e},f.isListMode=function(){return k?!/^full.*/.test(g.search.substr(1)):b.body.classList.contains("list")},f.isSlideMode=function(){return k?/^full.*/.test(g.search.substr(1)):b.body.classList.contains("full")},f.updateProgress=function(a){if(null===j)return!1;if(!f._isNumber(a))throw new Error("Gimme slide number as Number, baby!");return j.style.width=(100/(f.slideList.length-1)*f._normalizeSlideNumber(a)).toFixed(2)+"%",!0},f.updateActiveAndVisitedSlides=function(a){var c,d,e=f.slideList.length;if(a=f._normalizeSlideNumber(a),!f._isNumber(a))throw new Error("Gimme slide number as Number, baby!");for(c=0;e>c;++c)d=b.getElementById(f.slideList[c].id),a>c?(d.classList.remove("active"),d.classList.add("visited")):c>a?(d.classList.remove("visited"),d.classList.remove("active")):(d.classList.remove("visited"),d.classList.add("active"));return!0},f.clearPresenterNotes=function(){f.isSlideMode()&&h&&h.clear&&!f.debugMode&&h.clear()},f.showPresenterNotes=function(a){if(f.clearPresenterNotes(),h){a=f._normalizeSlideNumber(a);var c=f.slideList[a].id,d=f.slideList[a+1]?f.slideList[a+1].id:null,e=b.getElementById(c).querySelector("footer");if(e&&e.innerHTML&&h.info(e.innerHTML.replace(/\n\s+/g,"\n")),d){var g=b.getElementById(d).querySelector("h2");g&&(g=g.innerHTML.replace(/^\s+|<[^>]+>/g,""),h.info("NEXT: "+g))}}},f.getSlideHash=function(a){if(!f._isNumber(a))throw new Error("Gimme slide number as Number, baby!");return a=f._normalizeSlideNumber(a),"#"+f.slideList[a].id},f.wheel=function(a){var d,e=b.querySelector("body"),g="locked"===e.getAttribute("data-scroll");g||f.isListMode()||(e.setAttribute("data-scroll","locked"),d=a.deltaY===c?a.detail?a.wheelDeltaY/a.detail/120*a.detail>0?1:-1:a.wheelDeltaY/10:-a.deltaY,0>d?f._turnNextSlide():f._turnPreviousSlide(),setTimeout(function(){e.setAttribute("data-scroll","unlocked")},Math.abs(d)>3?200:800))};for(var l in a.shower)f[l]=a.shower[l];return a.addEventListener("DOMContentLoaded",function(){f.init().run()},!1),a.addEventListener("popstate",function(){var a=f.getCurrentSlideNumber(),c=b.body.classList.contains("full")||f.isSlideMode();c&&-1===a?f.go(0):-1===a&&""!==g.hash&&f.go(0),f.isListMode()?f.enterListMode():f.enterSlideMode()},!1),a.addEventListener("resize",function(){f.isSlideMode()&&f._applyTransform(f._getTransform())},!1),b.addEventListener("keydown",function(a){var b,c=f.getCurrentSlideNumber(),d=f.slideList[-1!==c?c:0];switch(a.which){case 80:f.isListMode()&&a.altKey&&a.metaKey&&(a.preventDefault(),b=d.number,f.go(b),f.enterSlideMode(),f.showPresenterNotes(b),d.timing&&d.initTimer(f));break;case 116:a.preventDefault(),f.isListMode()?(b=a.shiftKey?d.number:0,f.go(b),f.enterSlideMode(),f.showPresenterNotes(b),d.timing&&d.initTimer(f)):f.enterListMode();break;case 13:f.isListMode()&&-1!==c&&(a.preventDefault(),f.enterSlideMode(),f.showPresenterNotes(c),d.timing&&d.initTimer(f));break;case 27:f.isSlideMode()&&(a.preventDefault(),f.enterListMode());break;case 33:case 38:case 37:case 72:case 75:if(a.altKey||a.ctrlKey||a.metaKey)return;a.preventDefault(),f._turnPreviousSlide();break;case 34:case 40:case 39:case 76:case 74:if(a.altKey||a.ctrlKey||a.metaKey)return;a.preventDefault(),f._turnNextSlide();break;case 36:a.preventDefault(),f.first();break;case 35:a.preventDefault(),f.last();break;case 9:case 32:a.preventDefault(),f[a.shiftKey?"_turnPreviousSlide":"_turnNextSlide"]()}},!1),b.addEventListener("click",function(a){var b,c,d=f._getSlideIdByEl(a.target);d&&f.isListMode()&&(b=f.getSlideNumber(d),f.go(b),f.enterSlideMode(),f.showPresenterNotes(b),c=f.slideList[b],c.timing&&c.initTimer(f))},!1),b.addEventListener("touchstart",function(b){var c,d,e,g=f._getSlideIdByEl(b.target);g&&(f.isSlideMode()&&!f._checkInteractiveElement(b)&&(e=b.touches[0].pageX,e>a.innerWidth/2?f._turnNextSlide():f._turnPreviousSlide()),f.isListMode()&&(c=f.getSlideNumber(g),f.go(c),f.enterSlideMode(),f.showPresenterNotes(c),d=f.slideList[c],d.timing&&d.initTimer(f)))},!1),b.addEventListener("touchmove",function(a){f.isSlideMode()&&a.preventDefault()},!1),b.addEventListener("wheel",f.wheel,!1),b.addEventListener("mousewheel",f.wheel,!1),f}(this,this.document)); -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/images/grid-16x10.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/images/grid-4x3.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/images/linen.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/shower/themes/w3c/images/linen.png -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/images/linen@2x.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/shower/themes/w3c/images/linen@2x.png -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/images/ribbon_w3c.svg: -------------------------------------------------------------------------------- 1 | 2 | 142 | -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/pictures/exact.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/shower/themes/w3c/pictures/exact.png -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/pictures/square.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/shower/themes/w3c/pictures/square.png -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/pictures/tall.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/shower/themes/w3c/pictures/tall.png -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/pictures/wide.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/shower/themes/w3c/pictures/wide.png -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/styles/screen.css: -------------------------------------------------------------------------------- 1 | /** 2 | * W3C theme for Shower HTML presentation engine 3 | * shower-w3c v1.0.0 by Daniel Davis 4 | * Based on shower-ribbon v1.0.9, https://github.com/shower/ribbon 5 | * Copyright © 2010–2014 Vadim Makeev, http://pepelsbey.net 6 | * Licensed under MIT license: github.com/shower/shower/wiki/MIT-License 7 | */ 8 | 9 | html,body,div,span,applet,object,iframe,h1,h2,h3,h4,h5,h6,p,blockquote,pre,a,abbr,acronym,address,big,cite,code,del,dfn,em,img,ins,kbd,q,s,samp,small,strike,strong,sub,sup,tt,var,b,u,i,center,dl,dt,dd,ol,ul,li,fieldset,form,label,legend,table,caption,tbody,tfoot,thead,tr,th,td,article,aside,canvas,details,embed,figure,figcaption,footer,header,hgroup,menu,nav,output,ruby,section,summary,time,mark,audio,video { 10 | margin: 0; 11 | padding: 0; 12 | border: 0; 13 | font-size: 100%; 14 | font: inherit; 15 | vertical-align: baseline; 16 | } 17 | 18 | article,aside,details,figcaption,figure,footer,header,hgroup,menu,nav,section { 19 | display: block; 20 | } 21 | 22 | body { 23 | line-height: 1; 24 | } 25 | 26 | ol,ul { 27 | list-style: none; 28 | } 29 | 30 | blockquote,q { 31 | quotes: none; 32 | } 33 | 34 | blockquote:before,blockquote:after,q:before,q:after { 35 | content: ''; 36 | content: none; 37 | } 38 | 39 | table { 40 | border-collapse: collapse; 41 | border-spacing: 0; 42 | } 43 | 44 | body { 45 | counter-reset: slide; 46 | font: 24px/2 "Helvetica Neue",Helvetica,Arial,Verdana,Geneva,sans-serif; 47 | } 48 | 49 | @media print { 50 | body { 51 | text-rendering: geometricPrecision; 52 | } 53 | } 54 | 55 | a { 56 | color: #005a9c; 57 | background: -webkit-gradient(linear,left bottom,left top,from(currentColor),color-stop(.09em,currentColor),color-stop(.09em,transparent),to(transparent))repeat-x; 58 | background: -webkit-linear-gradient(bottom,currentColor,currentColor .09em,transparent .09em,transparent)repeat-x; 59 | background: linear-gradient(to top,currentColor,currentColor .09em,transparent .09em,transparent)repeat-x; 60 | text-decoration: none; 61 | } 62 | 63 | .caption { 64 | display: none; 65 | margin: 0 0 50px; 66 | color: #3C3D40; 67 | text-shadow: 0 1px 1px #8D8E90; 68 | } 69 | 70 | .caption h1 { 71 | font: 700 48px/1 "Helvetica Neue",Helvetica,Arial,Verdana,Geneva,sans-serif; 72 | } 73 | 74 | .caption a { 75 | text-shadow: 0 -1px 1px #005a9c; 76 | background: 0 0; 77 | } 78 | 79 | .caption a:hover { 80 | color: #5e93c8; 81 | } 82 | 83 | .badge { 84 | position: absolute; 85 | top: 0; 86 | right: 0; 87 | display: none; 88 | overflow: hidden; 89 | visibility: hidden; 90 | width: 11em; 91 | height: 11em; 92 | line-height: 2.5; 93 | font-size: 15px; 94 | } 95 | 96 | .badge a { 97 | position: absolute; 98 | bottom: 50%; 99 | right: -50%; 100 | left: -50%; 101 | visibility: visible; 102 | background: #005a9c; 103 | -webkit-box-shadow: 0 0 1em rgba(0,0,0,.3); 104 | box-shadow: 0 0 1em rgba(0,0,0,.3); 105 | color: #FFF; 106 | text-decoration: none; 107 | text-align: center; 108 | -webkit-transform-origin: 50% 100%; 109 | -ms-transform-origin: 50% 100%; 110 | transform-origin: 50% 100%; 111 | -webkit-transform: rotate(45deg)translateY(-1em); 112 | -ms-transform: rotate(45deg)translateY(-1em); 113 | transform: rotate(45deg)translateY(-1em); 114 | } 115 | 116 | .badge a:hover { 117 | background: #568ec6; 118 | } 119 | 120 | .slide { 121 | position: relative; 122 | width: 1024px; 123 | height: 640px; 124 | background: #FFF; 125 | color: #333; 126 | -webkit-print-color-adjust: exact; 127 | -webkit-text-size-adjust: none; 128 | -moz-text-size-adjust: none; 129 | -ms-text-size-adjust: none; 130 | } 131 | 132 | @media print { 133 | .slide { 134 | page-break-before: always; 135 | } 136 | } 137 | 138 | .slide:after { 139 | position: absolute; 140 | top: 0; 141 | right: 119px; 142 | padding: 50px 0 0; 143 | width: 60px; 144 | height: 100px; 145 | background: url(../images/ribbon_w3c.svg) no-repeat; 146 | color: #FFF; 147 | counter-increment: slide; 148 | content: counter(slide); 149 | text-align: center; 150 | font-size: 20px; 151 | } 152 | 153 | .slide>div { 154 | position: absolute; 155 | top: 0; 156 | left: 0; 157 | overflow: hidden; 158 | padding: 105px 120px 0; 159 | width: 784px; 160 | height: 535px; 161 | } 162 | 163 | .slide h2 { 164 | margin: 0 0 37px; 165 | color: #333; 166 | font: 700 48px/1 "Helvetica Neue",Helvetica,Arial,Verdana,Geneva,sans-serif; 167 | } 168 | 169 | .slide p { 170 | margin: 0 0 50px; 171 | } 172 | 173 | .slide p.note { 174 | color: #666; 175 | } 176 | 177 | .slide b,.slide strong { 178 | font-weight: 700; 179 | } 180 | 181 | .slide i,.slide em { 182 | font-style: italic; 183 | } 184 | 185 | .slide kbd,.slide code,.slide samp { 186 | padding: 3px 8px; 187 | border-radius: 8px; 188 | background: #fafaa2; 189 | color: #333; 190 | -moz-tab-size: 4; 191 | -o-tab-size: 4; 192 | tab-size: 4; 193 | line-height: 1; 194 | font-family: monospace; 195 | } 196 | 197 | .slide sub,.slide sup { 198 | position: relative; 199 | line-height: 0; 200 | font-size: 75%; 201 | } 202 | 203 | .slide sub { 204 | bottom: -.25em; 205 | } 206 | 207 | .slide sup { 208 | top: -.5em; 209 | } 210 | 211 | .slide blockquote { 212 | font-style: italic; 213 | } 214 | 215 | .slide blockquote:before { 216 | position: absolute; 217 | margin: -16px 0 0 -80px; 218 | color: #CCC; 219 | font: 200px/1 "Helvetica Neue",Helvetica,Arial,Verdana,Geneva,sans-serif; 220 | content: '\201C'; 221 | } 222 | 223 | .slide blockquote+figcaption { 224 | margin: -50px 0 50px; 225 | font-style: italic; 226 | font-weight: 700; 227 | } 228 | 229 | .slide ol,.slide ul { 230 | margin: 0 0 50px; 231 | counter-reset: list; 232 | } 233 | 234 | .slide ol li,.slide ul li { 235 | text-indent: -2em; 236 | } 237 | 238 | .slide ol li:before,.slide ul li:before { 239 | display: inline-block; 240 | width: 2em; 241 | color: #BBB; 242 | text-align: right; 243 | } 244 | 245 | .slide ol ol,.slide ol ul,.slide ul ol,.slide ul ul { 246 | margin: 0 0 0 2em; 247 | } 248 | 249 | .slide ul>li:before { 250 | content: '\2022\00A0\00A0'; 251 | } 252 | 253 | .slide ul>li:lang(ru):before { 254 | content: '\2014\00A0\00A0'; 255 | } 256 | 257 | .slide ol>li:before { 258 | counter-increment: list; 259 | content: counter(list)".\00A0"; 260 | } 261 | 262 | .slide pre { 263 | margin: 0 0 49px; 264 | padding: 1px 0 0; 265 | counter-reset: code; 266 | white-space: normal; 267 | } 268 | 269 | .slide pre code { 270 | display: block; 271 | padding: 0; 272 | background: 0 0; 273 | white-space: pre; 274 | line-height: 50px; 275 | } 276 | 277 | .slide pre code:before { 278 | position: absolute; 279 | margin: 0 0 0 -110px; 280 | width: 100px; 281 | color: #BBB; 282 | text-align: right; 283 | counter-increment: code; 284 | content: counter(code,decimal-leading-zero)"."; 285 | } 286 | 287 | .slide pre code:only-child:before { 288 | content: ''; 289 | } 290 | 291 | .slide pre mark { 292 | padding: 3px 8px; 293 | border-radius: 8px; 294 | background: #F7FCA0; 295 | color: #333; 296 | font-style: normal; 297 | } 298 | 299 | .slide pre mark.important { 300 | background: #005a9c; 301 | color: #FFF; 302 | font-weight: 400; 303 | } 304 | 305 | .slide pre mark.comment { 306 | padding: 0; 307 | background: 0 0; 308 | color: #666; 309 | } 310 | 311 | .slide table { 312 | margin: 1em !important; 313 | width: 100%; 314 | border-collapse: collapse; 315 | border-spacing: 0; 316 | } 317 | 318 | .slide table th { 319 | text-align: left; 320 | font-weight: 700; 321 | } 322 | 323 | .slide table.striped tr:nth-child(even) { 324 | background: #EEE; 325 | } 326 | 327 | .slide.cover,.slide.shout { 328 | z-index: 1; 329 | } 330 | 331 | .slide.cover:after,.slide.shout:after { 332 | visibility: hidden; 333 | } 334 | 335 | .slide.cover { 336 | background: #000; 337 | } 338 | 339 | .slide.cover img,.slide.cover svg,.slide.cover video,.slide.cover object,.slide.cover canvas,.slide.cover iframe { 340 | position: absolute; 341 | top: 0; 342 | left: 0; 343 | z-index: -1; 344 | } 345 | 346 | .slide.cover.w img,.slide.cover.w svg,.slide.cover.w video,.slide.cover.w object,.slide.cover.w canvas,.slide.cover.w iframe { 347 | top: 50%; 348 | width: 100%; 349 | -webkit-transform: translateY(-50%); 350 | -ms-transform: translateY(-50%); 351 | transform: translateY(-50%); 352 | } 353 | 354 | .slide.cover.h img,.slide.cover.h svg,.slide.cover.h video,.slide.cover.h object,.slide.cover.h canvas,.slide.cover.h iframe { 355 | left: 50%; 356 | height: 100%; 357 | -webkit-transform: translateX(-50%); 358 | -ms-transform: translateX(-50%); 359 | transform: translateX(-50%); 360 | } 361 | 362 | .slide.cover.w.h img,.slide.cover.w.h svg,.slide.cover.w.h video,.slide.cover.w.h object,.slide.cover.w.h canvas,.slide.cover.w.h iframe { 363 | top: 0; 364 | left: 0; 365 | -webkit-transform: none; 366 | -ms-transform: none; 367 | transform: none; 368 | } 369 | 370 | .slide.shout h2 { 371 | position: absolute; 372 | top: 50%; 373 | left: 0; 374 | width: 100%; 375 | text-align: center; 376 | line-height: 1; 377 | font-size: 140px; 378 | -webkit-transform: translateY(-50%); 379 | -ms-transform: translateY(-50%); 380 | transform: translateY(-50%); 381 | } 382 | 383 | .slide.shout h2 a { 384 | background: -webkit-gradient(linear,left bottom,left top,from(currentColor),color-stop(.11em,currentColor),color-stop(.11em,transparent),to(transparent))repeat-x; 385 | background: -webkit-linear-gradient(bottom,currentColor,currentColor .11em,transparent .11em,transparent)repeat-x; 386 | background: linear-gradient(to top,currentColor,currentColor .11em,transparent .11em,transparent)repeat-x; 387 | } 388 | 389 | .slide .place { 390 | position: absolute; 391 | top: 50%; 392 | left: 50%; 393 | -webkit-transform: translate(-50%,-50%); 394 | -ms-transform: translate(-50%,-50%); 395 | transform: translate(-50%,-50%); 396 | } 397 | 398 | .slide .place.t.l,.slide .place.t.r,.slide .place.b.r,.slide .place.b.l { 399 | -webkit-transform: none; 400 | -ms-transform: none; 401 | transform: none; 402 | } 403 | 404 | .slide .place.t,.slide .place.b { 405 | -webkit-transform: translate(-50%,0); 406 | -ms-transform: translate(-50%,0); 407 | transform: translate(-50%,0); 408 | } 409 | 410 | .slide .place.l,.slide .place.r { 411 | -webkit-transform: translate(0,-50%); 412 | -ms-transform: translate(0,-50%); 413 | transform: translate(0,-50%); 414 | } 415 | 416 | .slide .place.t,.slide .place.t.l,.slide .place.t.r { 417 | top: 0; 418 | } 419 | 420 | .slide .place.r { 421 | right: 0; 422 | left: auto; 423 | } 424 | 425 | .slide .place.b,.slide .place.b.r,.slide .place.b.l { 426 | top: auto; 427 | bottom: 0; 428 | } 429 | 430 | .slide .place.l { 431 | left: 0; 432 | } 433 | 434 | .slide footer { 435 | position: absolute; 436 | left: 0; 437 | right: 0; 438 | bottom: -640px; 439 | z-index: 1; 440 | display: none; 441 | padding: 20px 120px 4px; 442 | background: #fafaa2; 443 | -webkit-box-shadow: 0 0 0 2px #f0f0ac inset; 444 | box-shadow: 0 0 0 2px #f0f0ac inset; 445 | -webkit-transition: bottom .3s; 446 | transition: bottom .3s; 447 | } 448 | 449 | .slide footer p { 450 | margin: 0 0 16px; 451 | } 452 | 453 | .slide footer code { 454 | background: #fefeeb; 455 | } 456 | 457 | .slide:hover footer { 458 | bottom: 0; 459 | } 460 | 461 | @media screen { 462 | .list { 463 | position: absolute; 464 | clip: rect(0,auto,auto,0); 465 | padding: 80px 0 40px 100px; 466 | background: #585a5e url(../images/linen.png); 467 | } 468 | } 469 | 470 | @media screen and (-webkit-min-device-pixel-ratio:2),screen and (min-resolution:192dpi) { 471 | .list { 472 | background-image: url(../images/linen@2x.png); 473 | -webkit-background-size: 256px; 474 | background-size: 256px; 475 | } 476 | } 477 | 478 | @media screen { 479 | .list .caption,.list .badge { 480 | display: block; 481 | } 482 | 483 | .list .slide { 484 | float: left; 485 | margin: 0 -412px -220px 0; 486 | -webkit-transform-origin: 0 0; 487 | -ms-transform-origin: 0 0; 488 | transform-origin: 0 0; 489 | -webkit-transform: scale(.5); 490 | -ms-transform: scale(.5); 491 | transform: scale(.5); 492 | } 493 | } 494 | 495 | @media screen and (max-width:1324px) { 496 | .list .slide { 497 | margin: 0 -688px -400px 0; 498 | -webkit-transform: scale(.25); 499 | -ms-transform: scale(.25); 500 | transform: scale(.25); 501 | } 502 | } 503 | 504 | @media screen { 505 | .list .slide:before { 506 | position: absolute; 507 | top: 0; 508 | left: 0; 509 | z-index: -1; 510 | width: 512px; 511 | height: 320px; 512 | -webkit-box-shadow: 0 0 30px rgba(0,0,0,.005),0 20px 50px rgba(42,43,45,.6); 513 | box-shadow: 0 0 30px rgba(0,0,0,.005),0 20px 50px rgba(42,43,45,.6); 514 | border-radius: 2px; 515 | content: ''; 516 | -webkit-transform-origin: 0 0; 517 | -ms-transform-origin: 0 0; 518 | transform-origin: 0 0; 519 | -webkit-transform: scale(2); 520 | -ms-transform: scale(2); 521 | transform: scale(2); 522 | } 523 | } 524 | 525 | @media screen and (max-width:1324px) { 526 | .list .slide:before { 527 | width: 256px; 528 | height: 160px; 529 | -webkit-transform: scale(4); 530 | -ms-transform: scale(4); 531 | transform: scale(4); 532 | } 533 | } 534 | 535 | @media screen { 536 | .list .slide:after { 537 | top: auto; 538 | right: auto; 539 | bottom: -80px; 540 | left: 120px; 541 | padding: 0; 542 | width: auto; 543 | height: auto; 544 | background: 0 0; 545 | color: #3C3D40; 546 | text-shadow: 0 1px 1px #8D8E90; 547 | font-weight: 700; 548 | -webkit-transform-origin: 0 0; 549 | -ms-transform-origin: 0 0; 550 | transform-origin: 0 0; 551 | -webkit-transform: scale(2); 552 | -ms-transform: scale(2); 553 | transform: scale(2); 554 | } 555 | } 556 | 557 | @media screen and (max-width:1324px) { 558 | .list .slide:after { 559 | bottom: -104px; 560 | -webkit-transform: scale(4); 561 | -ms-transform: scale(4); 562 | transform: scale(4); 563 | } 564 | } 565 | 566 | @media screen { 567 | .list .slide:hover:before { 568 | -webkit-box-shadow: 0 0 0 10px rgba(42,43,45,.3),0 20px 50px rgba(42,43,45,.6); 569 | box-shadow: 0 0 0 10px rgba(42,43,45,.3),0 20px 50px rgba(42,43,45,.6); 570 | } 571 | 572 | .list .slide:target:before { 573 | -webkit-box-shadow: 0 0 0 10px #005a9c,0 20px 50px rgba(42,43,45,.6); 574 | box-shadow: 0 0 0 10px #005a9c,0 20px 50px rgba(42,43,45,.6); 575 | } 576 | } 577 | 578 | @media screen { 579 | .list .slide:target:after { 580 | text-shadow: 0 1px 1px rgba(42,43,45,.6); 581 | color: #fff; 582 | } 583 | 584 | .list .slide>div:before { 585 | position: absolute; 586 | top: 0; 587 | right: 0; 588 | bottom: 0; 589 | left: 0; 590 | z-index: 2; 591 | content: ''; 592 | } 593 | 594 | .list .slide.cover:after,.list .slide.shout:after { 595 | visibility: visible; 596 | } 597 | 598 | .list .slide footer { 599 | display: block; 600 | } 601 | 602 | .full { 603 | position: absolute; 604 | top: 50%; 605 | left: 50%; 606 | overflow: hidden; 607 | margin: -320px 0 0 -512px; 608 | width: 1024px; 609 | height: 640px; 610 | background: #000; 611 | } 612 | 613 | .full.debug:after { 614 | position: absolute; 615 | top: 0; 616 | right: 0; 617 | bottom: 0; 618 | left: 0; 619 | z-index: 2; 620 | background: url(../images/grid-16x10.svg) no-repeat; 621 | content: ''; 622 | } 623 | 624 | .full .slide { 625 | position: absolute; 626 | top: 0; 627 | left: 0; 628 | margin-left: 150%; 629 | } 630 | 631 | .full .slide .next { 632 | visibility: hidden; 633 | } 634 | 635 | .full .slide .next.active { 636 | visibility: visible; 637 | } 638 | 639 | .full .slide:target { 640 | margin: 0; 641 | } 642 | 643 | .full .slide.shout.grow h2,.full .slide.shout.shrink h2 { 644 | opacity: 0; 645 | -webkit-transition: all .4s ease-out; 646 | transition: all .4s ease-out; 647 | } 648 | 649 | .full .slide.shout.grow:target h2,.full .slide.shout.shrink:target h2 { 650 | opacity: 1; 651 | -webkit-transform: scale(1)translateY(-50%); 652 | -ms-transform: scale(1)translateY(-50%); 653 | transform: scale(1)translateY(-50%); 654 | } 655 | 656 | .full .slide.shout.grow h2 { 657 | -webkit-transform: scale(.1)translateY(-50%); 658 | -ms-transform: scale(.1)translateY(-50%); 659 | transform: scale(.1)translateY(-50%); 660 | } 661 | 662 | .full .slide.shout.shrink h2 { 663 | -webkit-transform: scale(10)translateY(-50%); 664 | -ms-transform: scale(10)translateY(-50%); 665 | transform: scale(10)translateY(-50%); 666 | } 667 | 668 | .full .progress { 669 | position: absolute; 670 | right: 0; 671 | bottom: 0; 672 | left: 0; 673 | overflow: hidden; 674 | height: 10px; 675 | z-index: 1; 676 | } 677 | 678 | .full .progress div { 679 | position: absolute; 680 | left: -20px; 681 | top: -10px; 682 | width: 0; 683 | height: 0; 684 | border: 10px solid transparent; 685 | border-bottom-color: #005a9c; 686 | -webkit-transition: width .2s linear; 687 | transition: width .2s linear; 688 | } 689 | 690 | .full .progress div[style$='100%;'] { 691 | padding-left: 10px; 692 | } 693 | } 694 | 695 | @page { 696 | margin:0;size:1024px 640px; 697 | } -------------------------------------------------------------------------------- /presentation/shower/themes/w3c/styles/w3c-shower.css: -------------------------------------------------------------------------------- 1 | 2 | body { 3 | line-height: 1.4em !important 4 | } 5 | 6 | .slide { 7 | background: #add9e4; 8 | background: -moz-radial-gradient(center, circle cover, #f7fbfc 0%, #add9e4 100%); 9 | background: -webkit-gradient(radial, center center, 0px, center center, 100%, color-stop(0%, #f7fbfc), color-stop(100%, #add9e4)); 10 | background: -webkit-radial-gradient(center, circle cover, #f7fbfc 0%, #add9e4 100%); 11 | background: -o-radial-gradient(center, circle cover, #f7fbfc 0%, #add9e4 100%); 12 | background: -ms-radial-gradient(center, circle cover, #f7fbfc 0%, #add9e4 100%); 13 | background: radial-gradient(center, circle cover, #f7fbfc 0%, #add9e4 100%); 14 | background-color: #f7fbfc; 15 | 16 | font-family: "Open Sans", sans-serif; 17 | font-size: 28px; 18 | font-weight: 200; 19 | letter-spacing: -0.02em; 20 | color: #333333; 21 | } 22 | 23 | ul ul li, ol ul li { 24 | font-size: 80% !important 25 | } 26 | 27 | ul li, ol li { 28 | padding-bottom: 0.3em !important 29 | } 30 | 31 | .slide ol ol,.slide ol ul,.slide ul ol,.slide ul ul { 32 | margin: 0 0 0 0.5em; 33 | } 34 | 35 | .slide h1, .slide h2, .slide h3, .slide h4 { 36 | padding-bottom: 2.2px; 37 | border-bottom: 2px solid #004480; 38 | color: #004480; 39 | -webkit-hyphens: none; 40 | -moz-hyphens: none; 41 | -ms-hyphens: none; 42 | hyphens: none; 43 | text-align: center; 44 | font-weight: normal; 45 | text-transform: uppercase; 46 | line-height: 0.9em; 47 | padding-right: 1.6em; 48 | padding-left: 1.6em; 49 | } 50 | 51 | .slide h2 { 52 | font-size: 1.3em; 53 | } 54 | 55 | .slide h3 { 56 | font-size: 1.1em 57 | } 58 | .slide h4 { 59 | font-size: 1em 60 | } 61 | 62 | .slide h1.title { 63 | font-size: 2.8em; 64 | padding-top: 2em; 65 | padding-bottom: 2.2px; 66 | border-bottom: none !important; 67 | text-align: center; 68 | 69 | } 70 | 71 | .titlepage h1, .titlepage h2, .titlepage h3, .titlepage h4 { 72 | border-bottom: none !important; 73 | text-align: center; 74 | } 75 | 76 | .titlepage h3 { 77 | font-size: 1em; 78 | margin-top: 2em; 79 | text-transform: none; 80 | } 81 | 82 | .titlepage h4 { 83 | font-size: 0.8em; 84 | margin-top: 1em; 85 | text-transform: none; 86 | } 87 | 88 | .titlepage p { 89 | font-size: 0.5em; 90 | } 91 | 92 | .slide.shout h2 { 93 | border-bottom: none; 94 | font-size: 3.5em; 95 | padding-left: 0em; 96 | padding-right: 0em; 97 | } 98 | 99 | .slide a { 100 | background: transparent; 101 | } 102 | 103 | .slide a:hover { 104 | background: #fafaa2; 105 | } 106 | 107 | .slide kbd,.slide code,.slide samp { 108 | background: transparent; 109 | color: inherit; 110 | } 111 | 112 | dt { font-weight: bold;} 113 | dd { padding-left: 1.5em;} 114 | 115 | dl.plain dt { font-weight: inherit !important;} 116 | 117 | .slide table { 118 | border: none !important; 119 | } 120 | 121 | .slide table.striped tr:nth-child(even) { 122 | background: snow; 123 | } 124 | 125 | .slide pre { 126 | font-family: monospace; 127 | font-size: 80%; 128 | line-height: 1.1em; 129 | white-space: pre !important; 130 | color: green; 131 | } 132 | 133 | .slide code { 134 | font-family: monospace; 135 | font-size: 80%; 136 | color: green; 137 | } 138 | 139 | .slide em { 140 | text-decoration: underline; 141 | } 142 | 143 | header a { 144 | color: khaki !important; 145 | } 146 | 147 | header p, header h1, header h2, header h3 { 148 | color: snow; 149 | } 150 | 151 | .slide table { border-collapse: separate; 152 | border-spacing: 0.1em } 153 | 154 | 155 | 156 | 157 | 158 | -------------------------------------------------------------------------------- /presentation/slides.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/epubweb/0c2fbf5edf886c112d6c49f25e442d887503f6b5/presentation/slides.pdf -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": 64149, 3 | "contacts": [ 4 | "iherman" 5 | ], 6 | "policy": "open", 7 | "repo-type": "note" 8 | } 9 | --------------------------------------------------------------------------------