1 Overview

1.1 Purpose and Scope

This section is informative

This specification, EPUB Content Documents 3.1, defines profiles of HTML, SVG, and CSS for use in the context of EPUB® Publications.

This specification is one of a family of specifications that compose [EPUB 3.1], an interchange and delivery format for digital publications based on XML and Web Standards. It is meant to be read and understood in concert with the other specifications that make up EPUB 3.1.

Refer to [EPUB3 Changes] for more information on the differences between this specification and its predecessor.

1.2 Relationship to Other Specifications

This section is informative

1.2.1 Relationship to HTML

This specification does not reference a specific version of W3C [HTML], but instead uses an undated reference that will always point to the latest recommendation. This approach ensures that EPUB will always keep pace with changes to the HTML standard. Authors and Reading System developers will need to keep track of changes to HTML, and ensure that their processes and systems are kept up to date.

caution

As HTML evolves, it is possible that features that were valid in previous versions could become obsolete or be removed. IDPF anticipates that the W3C will make any such changes carefully to ensure minimal disruption for Authors, but in the case of a backwards-incompatible revision the use of an undated reference could be revisited.

The XHTML profile defined by this specification inherits all definitions of semantics, structure and processing behaviors from [HTML] unless otherwise specified.

In addition, this specification defines a set of extensions to the W3C HTML document model that Authors can include in XHTML Content Documents.

This specification does not require EPUB Reading Systems to support scripting, HTML forms or the HTML DOM. Reading Systems conformant with this specification are only expected to be able to process a conforming EPUB Content Document. As support for scripting and HTML forms is not compulsory, a conformant Reading System might not be a fully-conformant HTML user agent.

1.2.2 Relationship to SVG

This specification does not reference a specific version of [SVG], but instead uses an undated reference that will always point to the latest recommendation. This approach ensures that EPUB will always keep pace with changes to the SVG standard. Authors and Reading System developers will need to keep track of changes to the SVG standard, and ensure that their processes and systems are kept up to date.

caution

As SVG evolves, it is possible that features that were valid in previous versions could become obsolete or be removed. IDPF anticipates that the W3C will make any such changes carefully to ensure minimal disruption for Authors, but in the case of a backwards-incompatible revision the use of an undated reference could be revisited.

1.2.3 Relationship to CSS

EPUB 3.1 supports CSS as defined by the CSS Working Group Snapshot [CSS Snapshot]. EPUB 3.1 also maintains some prefixed CSS properties, to ensure consistent support for global languages.

1.3 Terminology

Terms with meanings specific to EPUB 3.1 are capitalized in this document (e.g., "Author", "Reading System"). A complete list of these terms and definitions is provided in [EPUB 3.1].

Only the first instance of a term in a section is linked to its definition.

1.4 Typographic Conventions

The following typographic conventions are used in this specification:

markup: All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine-readable values (string, characters, media types) and file names are in red monospace font.
markup link: Links to markup and code definitions are in underlined red monospace font.
http://www.idpf.org/: URIs are in navy blue monospace font.
hyperlink: Hyperlinks are underlined and blue.
[reference]: Normative and informative references are enclosed in square brackets.
Term: Terms defined in the Terminology are in capital case.
Term Link: Links to term definitions have a dotted blue underline.

: Normative element, attribute and property definitions are in blue boxes.

Informative markup examples are in light gray boxes.

note

Informative notes are in green boxes with a "Note" header.

caution

Informative cautionary notes are in red boxes with a "Caution" header.

1.5 Conformance Statements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

All sections and appendixes of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendixes applies to all child content and subsections they contain.

All examples in this specification are informative.

1.6 Namespace prefix mapping

For convenience, the following namespace prefixes [XMLNS] are used in this specification without explicitly being declared. To use any of these prefixes in an EPUB Content Document, a declaration is required.

Prefix mappings

prefix	URI
`epub`	`http://www.idpf.org/2007/ops`
`pls`	`https://www.w3.org/2005/01/pronunciation-lexicon`
`ssml`	`https://www.w3.org/2001/10/synthesis`

2 XHTML Content Documents

2.1 Introduction

This section defines a profile of [HTML] for creating XHTML Content Documents. An instance of an XML document that conforms to this profile is a Core Media Type Resource and is referred to in this specification as an XHTML Content Document.

Unless otherwise specified, this specification inherits all definitions of semantics, structure and processing behaviors from the [HTML] specification.

2.2 Content Conformance

An XHTML Content Document must meet all of the following criteria:

Document Properties

It must be an [HTML] document that conforms to the XHTML syntax.

It must meet the conformance constraints for XML documents defined in XML Conformance [EPUB 3.1].

For all document constructs used that are defined by [HTML], it must conform to the conformance criteria defined for those constructs in that specification, unless explicitly overridden in HTML Deviations and Constraints.

It may include extensions to the [HTML] grammar as defined in HTML Extensions, and must conform to all content conformance constraints defined therein.

note

The recommendation that EPUB Publications follow the accessibility requirements in [EPUB Accessibility] applies to XHTML Content Documents. See Accessibility [EPUB 3.1].

File Properties

The XHTML Content Document filename should use the file extension .xhtml

2.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing XHTML Content Documents:

Unless explicitly defined by this specification as overridden, it must process XHTML Content Documents using semantics defined by the [HTML] specification and honor any applicable user agent conformance constraints expressed therein.
It must meet all Reading System conformance criteria defined in HTML Extensions.
It must recognize and adapt behaviorally to the constraints defined in HTML Deviations and Constraints.
It must meet the Reading System conformance criteria defined in Scripted Content Documents — Reading System Conformance.
It must support visual rendering of XHTML Content Documents as defined in CSS Style Sheets — Reading System Conformance.
It should recognize embedded ARIA markup and support exposure of any given ARIA roles, states and properties to platform accessibility APIs [WAI-ARIA].

2.4 HTML Extensions

This section defines EPUB 3.1 XHTML Content Document extensions to the underlying [HTML] document model.

note

Although [HTML] allows user agents to support vendor-neutral extensions, unless such extensions are listed in this section they are not supported features of EPUB 3.1.

2.4.1 Semantic Inflection

2.4.1.1 Introduction

This section is informative

Semantic inflection is the process of attaching additional meaning about the specific purpose and/or nature an element plays in an XHTML Content Document. The epub:type attribute is used to express domain-specific semantics in XHTML Content Documents, with the inflection(s) it carries complementing the underlying [HTML] vocabulary.

The applied semantics are intended to refine the meaning of their containing elements; they are not provided to override their nature (e.g., the attribute can be used to indicate a section is a chapter in a work, but is not designed to turn p elements into list items to avoid proper list structures).

Semantic metadata is not intended for direct human consumption; it instead provides a controlled way for Reading Systems to learn more about the structure and content of a document, providing them the opportunity to enhance the reading experience for users.

This specification defines a method for semantic inflection using the attribute axis: instead of adding new elements, the epub:type attribute can be appended to existing elements to inflect the desired semantics. A mechanism to identify external vocabularies that provide controlled values for the attributes is also defined.

2.4.1.2 The `epub:type` Attribute

Attribute Name

type

Namespace

http://www.idpf.org/2007/ops

Usage

Global attribute. May be specified on all elements.

Value

A white space-separated list of property [Packages 3.1] values, with restrictions as defined in Vocabulary Association.

White space is the set of characters as defined in [XML].

The epub:type attribute inflects semantics on the element on which it appears. Its value is one or more white space-separated terms stemming from external vocabularies associated with the document instance, as defined in Vocabulary Association.

The inflected semantic must express a subclass of the semantic of the carrying element. In the case of semantically neutral elements, such as the [HTML] div and span elements, the inflected semantic must not attach a meaning that is already conveyed by an existing element (e.g., that a div represents a paragraph or section). Reading Systems must ignore inflected semantics that conflict with the carrying element.

As the [HTML] head element contains metadata for the document, structural semantics expressed on this element or any descendant of it have no meaning. Reading Systems must ignore such semantics.

Examples

The following example shows how a preamble could be marked up with the epub:type attribute on its containing [HTML] section element.

<html … xmlns:epub="http://www.idpf.org/2007/ops">
    …
    <section epub:type="preamble">
        …    
    </section>
    …
</html>

The following example shows the epub:type attribute used to add glossary semantics on an [HTML] definition list.

<html … xmlns:epub="http://www.idpf.org/2007/ops">
    …
    <dl epub:type="glossary">
        …    
    </dl>        
    …
</html>

The following example shows the epub:type attribute used to add pagebreak semantics.

<html … xmlns:epub="http://www.idpf.org/2007/ops">
   …
  <p> … <span epub:type="pagebreak" title="234" id="p234"/> … </p>    
   … 
</html>

2.4.1.3 Vocabulary Association

This specification adopts the vocabulary association mechanisms defined in Vocabulary Association Mechanisms [Packages 3.1], with the following modifications:

Default Vocabulary

The default vocabulary for Content Documents is defined to be the EPUB 3 Structural Semantics Vocabulary.

Reserved Prefixes

The reserved prefixes that Authors may use in the epub:type attribute without having to declare are defined in [Reserved Prefixes].

The `prefix` Attribute

The prefix attribute definition is unchanged, but the attribute is defined to be in the namespace http://www.idpf.org/2007/ops when used in EPUB Content Documents.

The prefix attribute is only valid on the [HTML] root html element.

2.4.1.4 Processing Requirements

A Reading System must process the epub:type attribute as follows:

It may associate behaviors with none, some or all of the terms defined in the default vocabulary.
It may associate behaviors with terms from other vocabularies.
It must ignore terms that it does not recognize.

When Reading System behavior associated with a given epub:type value conflicts with an element's native behavior, the behavior associated with the element must be given precedence.

2.4.2 Semantic Enrichment

2.4.2.1 Introduction

This section is informative

Unlike semantic inflection, which is about refining the structures within the markup, semantic enrichment enables the layering of meaning into the content in order to facilitate machine processing.

The [Microdata] and [RDFa 1.1] specifications both define sets of attributes that can be used in XHTML Content Documents to semantically enrich the content.

2.4.2.2 RDFa

The use of [RDFa 1.1] attributes is allowed in XHTML Content Documents, but any usage must conform to the requirements defined in [HTML+RDFa11].

The [RDFa 1.1] specification defines changes to the [HTML] content model when RDFa attributes are used. This modified content model is valid in XHTML Content Documents.

EPUB Reading System support for the attribute processing model [RDFa 1.1] is optional.

2.4.2.3 Microdata

The use of [Microdata] attributes is allowed in XHTML Content Documents, but any usage must conform to the requirements defined in that specification.

The [Microdata] specification defines changes to the [HTML] content model when Microdata attributes are used. This modified content model is valid in XHTML Content Documents.

EPUB Reading System support for the attribute processing model is optional, as is the conversion to JSON [Microdata]. Furthermore, the DOM API [Microdata] is also optional, even if the attribute processing model is supported.

2.4.3 SSML Attributes

2.4.3.1 Introduction

The W3C Speech Synthesis Markup Language [SSML] is a language used for assisting Text-to-Speech (TTS) engines in generating synthetic speech. Although SSML is designed as a standalone document type, it also defines semantics suitable for use within other markup languages.

This specification recasts the [SSML] phoneme element as two attributes — ssml:ph and ssml:alphabet — and makes them available within XHTML Content Documents.

Reading Systems with Text-to-Speech (TTS) capabilities should support the SSML Attributes as defined below.

note

For more information on EPUB 3.1 features related to synthetic speech, refer to Text-to-speech [EPUB3 Overview].

2.4.3.2 The `ssml:ph` attribute

The ssml:ph attribute specifies a phonemic/phonetic pronunciation of the text represented by the element to which the attribute is attached.

Attribute Name

ph

Namespace

https://www.w3.org/2001/10/synthesis

Usage

Global attribute. May be specified on all elements with which a phonetic equivalent can logically be associated (e.g., elements that contain textual information).

Must not be specified on a descendant of an element that already carries this attribute.

Value

A phonemic/phonetic expression, syntactically valid with respect to the phonemic/phonetic alphabet being used.

This attribute inherits all the semantics of the [SSML] phoneme element ph attribute, with the following addition:

When the ssml:ph attribute appears on an element that has text node descendants, the corresponding document text to which the pronunciation applies is the string that results from concatenating the descendant text nodes, in document order. The specified phonetic pronunciation must therefore logically match the element's textual data in its entirety (i.e., not just an isolated part of its content).

Reading Systems that support the SSML Attributes and PLS Documents must honor the defined precedence rules for these two constructs.

2.4.3.3 The `ssml:alphabet` attribute

The ssml:alphabet attribute specifies which phonemic/phonetic pronunciation alphabet is used in the value of the ssml:ph attribute.

Attribute Name: alphabet
Namespace: https://www.w3.org/2001/10/synthesis
Usage: Global attribute. May be specified on any element.
Value: The name of the pronunciation alphabet used in the value of ssml:ph (inherited).

This attribute inherits all the semantics of the [SSML] phoneme element alphabet attribute, with the following addition:

The value of the ssml:alphabet attribute is inherited in the document tree. The pronunciation alphabet used in a given ssml:ph attribute value is determined by locating the first occurrence of the ssml:alphabet attribute starting with the element on which the ssml:ph attribute appears, followed by the nearest ancestor element.

note

Although the [SSML] specification makes reference to a registry of alphabets, one has not been published. As the charter of the W3C Voice Browser Working Group has expired, the publication of such a registry is not anticipated. Authors therefore need to reference Reading System support documentation to determine what alphabet values are supported. Some common alphabets include: x-JEITA (also x-JEITA-IT-4002 and x-JEITA-IT-4006) and x-sampa.

Reading Systems that support the SSML Attributes feature of this specification should support the IPA alphabet [IPA], as expressed by the value "ipa".

2.4.4 Alternate Style Tags

In accordance with [Alt Style Tags] , the link element class attribute may include any of the following values: horizontal, vertical, day and night. These values inherit the semantics defined by that specification for their use.

Reading Systems should select and utilize such tagged style sets as appropriate, and as described in that specification.

2.4.5 Custom Attributes

Reading Systems may introduce functionality not defined in this specification to enhance the rendering of EPUB Publications. To facilitate this experimentation, vendors may define custom attributes for use in XHTML Content Documents.

Custom attributes may be included on any element in an XHTML Content Document provided such attributes are from a foreign namespace, which is defined as a namespace [XMLNS] that does not map to either of the following URIs:

http://www.w3.org/1999/xhtml
http://www.idpf.org/2007/ops

Custom attributes, and the behaviors associated with them, must not alter the integrity of an EPUB Publication. The content must remain consumable by a user without any information loss or other significant deterioration, regardless of the Reading System it is rendered on.

note

To facilitate interoperability of custom attributes across Reading Systems, vendors are strongly encouraged to document any extensions they implement in [Attribute Extensions].

2.5 HTML Deviations and Constraints

This section defines deviations from, and constraints on, the underlying [HTML] document model applicable to EPUB 3.1 XHTML Content Documents.

2.5.1 Embedded MathML

2.5.1.1 Introduction

This section is informative

XHTML Content Documents support embedded [MATHML] but limit its usage to a restricted subset of the full MathML markup language.

This subset is designed to ease the implementation burden on Reading Systems and to promote accessibility, while retaining compatibility with [HTML] user agents.

note

The mathml property [Manifest Vocab] of the manifest item element indicates that an XHTML Content Document contains embedded MathML.

2.5.1.2 Content Conformance

Any occurrence of MathML markup in XHTML Content Documents must conform to the constraints expressed in the MathML specification [MATHML], with the following additional restrictions:

Presentation MathML

The math element must contain only Presentation MathML, with the exception of the annotation-xml element as defined below.

Content MathML

Content MathML may be included within MathML markup in XHTML Content Documents, and, when present, must occur within an annotation-xml child element of an semantics element.

When Content MathML is included as per the previous condition, the given annotation-xml element's encoding attribute must be set to either of the functionally-equivalent values MathML-Content or application/mathml-content+xml, and its name attribute must be set to contentequiv.

Deprecated MathML

Elements and attributes marked as deprecated in [MATHML] must not be included within MathML markup in XHTML Content Documents.

XHTML Content Document fragments

XHTML Content Document fragments may be included within MathML markup in XHTML Content Documents, and, when present, must occur within an annotation-xml child element of an semantics element.

When an XHTML Content Document fragment is included as per the above paragraph, the given annotation-xml element's encoding attribute must be set to application/xhtml+xml and its name attribute must be set to alternate-representation.

Any included XHTML Content Document fragments must not themselves contain MathML markup.

Any included XHTML Content Document fragments must conform to the content model in which the ancestor math element occurs, such that if the math element is replaced by the given XHTML Content Document fragment the document remains valid.

2.5.1.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing MathML embedded in XHTML Content Documents:

It must support processing of Presentation MathML using semantics defined by [MATHML].
It may support processing of Content MathML found in an xml-annotation element using semantics defined by [MATHML].
If it has a Viewport, it must support visual rendering of Presentation MathML.

2.5.1.4 Fallback Content

As Reading System support for MathML rendering is inconsistent, Authors are encouraged to provide a fallback image using the altimg attribute on the math element. It is recommended that the dimension and alignment attributes (altimg-width, altimg-height and altimg-valign) be used in conjunction with the altimg attribute.

note

Fallback images have conform to the constraints for Publication Resources defined in EPUB Publication Conformance [EPUB 3.1].

2.5.2 Embedded SVG

XHTML Content Documents support the embedding of SVG document fragments by reference (embedding via reference, for example, from an img or object element) and by inclusion (embedding via direct inclusion of the svg element in the XHTML Content Document) [SVG].

The content conformance constraints for SVG embedded in XHTML Content Documents are the same as defined for SVG Content Documents in Restrictions on SVG.

Reading Systems must process SVG embedded in XHTML Content Documents as defined in SVG Content Documents — Reading System Conformance.

note

The svg property [Manifest Vocab] of the manifest item element indicates that an XHTML Content Document contains embedded SVG.

2.5.2.1 Embedded SVG and CSS

For the purposes of styling SVG embedded in XHTML Content Documents by reference, Reading Systems must not apply CSS style rules of the containing document to the referenced SVG document.

For the purposes of styling SVG embedded in XHTML Content Documents by inclusion, Reading Systems must apply applicable CSS rules of the containing document to the included SVG elements.

note

SVG included by reference is processed as a separate document, and can include its own CSS style rules just like an SVG Content Document would. Note that this is consistent with situations where an [HTML] object element references an external [HTML] element.

2.5.3 Unicode Restrictions

This section lists restrictions on the Unicode character repertoire.

Private Use Characters and Embedded Fonts: Any included characters that map to a code point within one of the Private Use Area (PUA) ranges as defined in [Unicode] must occur within a string that is styled or attributed in a manner that includes a reference to an embedded font [CSS3 Fonts] that contains an appropriate glyph for that code point.

2.5.4 Discouraged Constructs

This section is informative

2.5.4.1 The `rp` Element

The [HTML] rp element is intended to provide a fallback for older version Reading Systems that do not recognize ruby markup (i.e., a parenthesis display around ruby markup). As EPUB 3.1 Reading Systems are ruby-aware, and can provide fallbacks, the use of rp elements is discouraged.

2.5.4.2 The `embed` Element

Since the [HTML] embed element does not include intrinsic facilities to provide fallbacks for Reading Systems that do not support scripting, Authors are discouraged from using the element when the referenced resource includes scripting. The object element can be used instead, as it includes intrinsic fallback capabilities.

2.5.5 Foreign Resource Restrictions

Foreign Resources may be referenced from elements that have intrinsic fallback mechanisms, where an intrinsic fallback method is the capability to offer an alternative presentation if the foreign resource is not supported. For example, most [HTML] embedded content elements provide options for alternative rendering, such as allowing multiple sources to be specified or allowing embedded HTML content for when a resource cannot be rendered. A Core Media Type Resource or embedded HTML content must be provided via the given element's intrinsic fallback mechanism when a Foreign Resource is referenced.

Flow content may be embedded within the [HTML] audio and video elements for rendering in older Reading Systems that do not recognize these elements (e.g., EPUB 2 Reading Systems), but it does not represent a Core Media Type fallback.

The following [HTML] elements are exempt from Core Media Type requirements [EPUB 3.1]:

link — when its rel attribute has the value "pronunciation"
track
video — including any child source elements

Foreign Resources may be referenced from the above elements without the provision of a Core Media Type fallback.

note

Refer to manifest fallbacks [Packages 3.1] for the provision of fallbacks for elements without intrinsic mechanisms, such as the [HTML] iframe and img elements.

3 SVG Content Documents

caution

Some features of [SVG] are not fully supported in Reading Systems, or supported across all platforms on which Reading Systems run. When utilizing such features, Authors need to consider the inherent risks in terms of the potential impact on interoperability and document longevity.

3.1 Introduction

This section is informative

The Scalable Vector Graphics (SVG) specification [SVG] defines a format for representing final-form vector graphics and text.

Although an EPUB Publication typically uses XHTML Content Documents as the top-level document type, the use of SVG Content Documents is also permitted. SVGs are typically only used in certain special circumstances, such as when final-form page images are the only suitable representation of the content (e.g., in the context of manga or comic books).

This section defines a profile for [SVG] documents. An instance of an XML document that conforms to this profile is a Core Media Type Resource and is referred to in this specification as an SVG Content Document.

note

This section defines conformance requirements for SVG Content Documents. Refer to Embedded SVG for conformance requirements for SVG embedded in XHTML Content Documents.

3.2 Content Conformance

An SVG Content Document must meet all of the following criteria:

Document Properties

It must meet the conformance constraints for XML documents defined in XML Conformance [EPUB 3.1].

It may include references to Foreign Resources provided a fallback to a Core Media Type Resource is included.

It must be an SVG document fragment [SVG], and conform to all content conformance constraints expressed in Restrictions on SVG.

note

The recommendation that EPUB Publications follow the accessibility requirements in [EPUB Accessibility] applies to SVG Content Documents. See Accessibility [EPUB 3.1].

File Properties

The SVG Content Document filename should use the file extension .svg.

3.3 Restrictions on SVG

This specification restricts the content model of SVG Content Documents and SVG embedded in XHTML Content Documents as follows:

The [SVG] foreignObject element must adhere to the following criteria:
- It must contain either [HTML] flow content or exactly one [HTML] body element.
- Its content must be a valid document fragment that conforms to the XHTML Content Document model defined in XHTML Content Documents — Content Conformance.
- Its requiredExtensions attribute, if given, must be set to "http://www.idpf.org/2007/ops".
The [SVG] title element must contain only valid XHTML Content Document Phrasing content.

3.4 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing SVG Content Documents and SVG embedded in XHTML Content Documents:

Unless explicitly defined by this specification as overridden, it must process SVG Content Documents using semantics defined by the [SVG] specification and honor any applicable user agent conformance constraints expressed therein.
It must meet the Reading System conformance criteria defined in Scripted Content Documents — Reading System Conformance.
If it has a Viewport, it must support the visual rendering of SVG using CSS as defined in Styling [SVG], and it should support all properties defined in Property Index [SVG]. In the case of embedded SVG, it must also conform to the constraints defined in Embedded SVG and CSS.
It should support user selection and searching of text within SVG elements.
It must recognize the value "http://www.idpf.org/2007/ops" of the requiredExtensions attribute as representing the occurrence of XHTML Content Document fragments (e.g., when the attribute is included on the foreignObject element or children of the switch element).

3.5 Semantic Inflection

The syntax and semantics defined in XHTML Semantic Inflection are inherited for use of the epub:type and epub:prefix attributes in SVG Content Documents.

The use of the epub:prefix attribute is only valid on the root svg element in SVG Content Documents. Prefixes used in embedded SVG must be declared on the [HTML] root html element, as defined in XHTML Semantic Inflection.

4 CSS Style Sheets

4.1 Introduction

This section is informative

CSS has been an integral part of the Open Web Platform for nearly two decades — readers, publishers, and document authors expect CSS to "just work," as they expect HTML to just work.

In the past, EPUB defined a profile of CSS that mandated support for certain properties and provided prefixed versions of numerous other properties. Although the CSS Working Group no longer recommends the use of prefixed properties, this specification has to maintain some prefixed properties to avoid breaking existing content. But with the minor exceptions defined in this section, EPUB defers to the W3C to define CSS.

4.2 Content Conformance

A conformant CSS style sheet must meet all of the following criteria:

It may include any CSS properties, with the following exceptions:
- It must not use the direction property [CSS3 Writing Modes]. Use the [HTML] dir attribute to set the inline base direction.
- It must not use the unicode-bidi property [CSS3 Writing Modes]. Use [HTML] bdo elements and dir attributes to control bidirectionality.
It may include the prefixed properties defined in CSS Style Sheets — Prefixed Properties.
It must be encoded in UTF-8 or UTF-16 [Unicode].

note

Keep in mind that some Reading Systems will not support all desired features of CSS. In particular, the following are known to be problematic:

Reading System-induced pagination can interact poorly with style sheets. Pagination is sometimes done using columns, which can result in incorrect values for viewport sizes. Fixed and absolute positioning are particularly problematic.
Some types of screens will render animations and transitions poorly (e.g., those with high latency).

4.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing CSS Style Sheets:

It must support the official definition of CSS as described in the [CSS Snapshot].
It should support all applicable modules in [CSS Snapshot] that have reached at least Candidate Recommendation status [W3C Process] (and are widely implemented).
It must support all prefixed properties defined in CSS Style Sheets — Prefixed Properties.
In addition to supporting CSS properties as defined above, its user agent style sheet should support the [HTML] suggested default rendering.
It should respect Author CSS and user styles as defined in Reading System Overrides.

Reading System developers are encouraged to implement CSS support at the level of major browsers.

4.4 Prefixed Properties

caution

Authors are strongly encouraged to use unprefixed properties, and Reading Systems to support current CSS specifications. The widely-used prefixed properties from [Content Docs 3.0.1] have been retained, but support for the other properties has been removed. Authors are advised to use CSS-native solutions for the removed properties where and when they are available.

Authors currently using these prefixed properties are advised to move to unprefixed versions as soon as support allows, as these properties are not anticipated to be supported in the next major version of EPUB.

4.4.1 CSS Writing Modes

The following table lists the -epub- prefixed properties for [CSS3 Writing Modes]. The Value column indicates the value the property accepts. The Prior EPUB Mapping column indicates values/properties that were used in previous versions of EPUB 3. An asterisk (*) denotes that the older property or value is now deprecated. The final column describes how to implement the prefixed property based on [CSS3 Writing Modes-20151215].

CSS Writing Modes Properties

Property	Value	Prior EPUB Mapping	Mapping to [CSS3 Writing Modes-20151215]
-epub-text-orientation	`upright`	`upright`	`upright`
-epub-text-orientation	`mixed`	`vertical-right`*	`mixed`
-epub-text-orientation	`sideways-right`	`sideways-right`	`sideways`
-epub-text-orientation	`sideways-right`	`rotate-right`*	`sideways`
-epub-text-orientation	`sideways`	`rotate-normal`*	`sideways`
-epub-text-orientation	`sideways`	`sideways`	`sideways`
-epub-text-orientation	`mixed`	`mixed`	`mixed`
-epub-writing-mode	`horizontal-tb`	`horizontal-tb`	`horizontal-tb`
-epub-writing-mode	`vertical-rl`	`vertical-rl`	`vertical-rl`
-epub-writing-mode	`vertical-lr`	`vertical-lr`	`vertical-lr`
-epub-text-combine*	-epub-text-combine-horizontal: none	`none`	`text-combine-upright: none`
-epub-text-combine*	-epub-text-combine-horizontal: all	`horizontal`	`text-combine-upright: all`
-epub-text-combine*	Error	`horizontal <number>`	text-combine-upright: digits <number>

4.4.2 CSS Text Level 3

CSS Text Level 3 Properties

Property	Value	Mapping to [CSS3 Text-20160119]
-epub-hyphens	`none \| manual \| auto`	No Change
-epub-hyphens	`all`	Not Supported
-epub-line-break	`auto \| loose \| normal \| strict`	No Change
-epub-text-align-last	`auto \| start \| end \| left \| right \| center \| justify`	No Change
-epub-word-break	`normal \| keep-all \| break-all`	No Change
text-transform	`-epub-fullwidth`	text-transform: full-width

4.4.3 CSS Text Decoration Level 3

CSS Text Decoration Level 3 Properties

Property	Value	Mapping to [CSS3 Text Decoration]
-epub-text-emphasis-color	`<color>`	No Change
-epub-text-emphasis-position	`[ over \| under ] && [ right \| left ]`	No Change
-epub-text-emphasis-style	`none \| [ [ filled \| open ] \|\| [ dot \| circle \| double-circle \| triangle \| sesame ] ] \| <string>`	No Change
-epub-text-underline-position	`auto \| [ under \|\| [ left \| right ] ]`	No Change
-epub-text-underline-position	`alphabetic`	text-underline-position: auto

Property value syntax defined in Component value combinators [CSS3 Values and Units].

4.5 Reading System Overrides

EPUB Reading Systems should apply Author style sheets as written to EPUB Content Documents. If a Reading System allows, users should be able to override Author style sheets as desired. EPUB Reading Systems should not override Author style sheets unless strictly necessary.

If a Reading System has to override an Author style sheet, it should do so in a way that preserves the Cascade: through a user agent style sheet, the getOverrideStyle method [DOM2 Style], or [HTML] style attributes.

Developers of Reading Systems are strongly encouraged to publicly document their user agent style sheets and how they interact with Author style sheets.

5 Scripting

5.1 Scripting Contexts

EPUB Content Documents may contain scripting using the facilities defined for this in the respective underlying specifications ([HTML] and [SVG]). When an EPUB Content Document contains scripting, it is referred to in this specification as a Scripted Content Document. This label also applies to XHTML Content Documents when they contain instances of [HTML] forms.

This specification defines two contexts in which scripts may appear:

spine-level

An instance of the [HTML] script or [SVG] script element included in a Top-level Content Document.

container-constrained

Either of the following:

An instance of the [HTML] script element included in an XHTML Content Document that is embedded in a parent XHTML Content Document using the [HTML] iframe element.
An instance of the [SVG] script element included in an SVG Content Document that is embedded in a parent XHTML Content Document using the [HTML] iframe element.

In both of the above-defined contexts, whether the JavaScript code is embedded directly in the script element or referenced via its src attribute makes no difference to the executing context.

Which context a script is used in determines the rights and restrictions that a Reading System places on it. Refer to Content Conformance and Reading System Conformance for some specific requirements that have to be adhered to (not all Reading Systems will provide the same scripting functionality).

Example

Consider the following example Package Document:

<package …>
    …
    <manifest>
        …
        <item id="chap01" 
            href="scripted01.xhtml" 
            media-type="application/xhtml+xml"
            properties="scripted"/>
        <item id="inset01" 
            href="scripted02.xhtml" 
            media-type="application/xhtml+xml"
            properties="scripted"/>
        <item id="slideshowjs" 
            href="slideshow.js" 
            media-type="text/javascript"/>
    </manifest>
    
    <spine …>
        <itemref idref="chap01"/>
        …
    </spine>
    …
</package>

and the following file scripted01.xhtml:

<html …>
    <head>
        …
        <script type="text/javascript">
            alert("Reading System name: " + navigator.epubReadingSystem.name);
        </script>
    </head>
    <body>
        …
        <iframe src="scripted02.xhtml" … />
        …
    </body>
</html>

and the following file scripted02.xhtml:

<html …>
    <head>
        …
        <script type="text/javascript" href="slideshow.js"></script>
    </head>
    <body>
        …
    </body>
</html>

From these examples, it is true that:

the code in the script element in the head in scripted01.xhtml is a spine-level script because the document is referenced from the spine;
the code in the script element in scripted02.xhtml is a container-constrained script because the HTML file it occurs in is included in scripted01.xhtml via the iframe element.

5.2 Content Conformance

Container-constrained scripts

A container-constrained script must not contain instructions for modifying the DOM of the parent Content Document or other contents in the EPUB Publication, and must not contain instructions for manipulating the size of its containing rectangle.

Spine-level scripts

EPUB Content Documents that include spine-level scripting must utilize the progressive enhancement technique, which for the purposes of this specification has the following definition: when the document is rendered by a Reading System without scripting support or with scripting support disabled, the top-level document content must retain its integrity, remaining consumable by the user without any information loss or other significant deterioration.

Accessibility

Fallbacks

EPUB Content Documents that include scripting may provide fallbacks for such content, either by using intrinsic fallback mechanisms (such as those available for the [HTML] object and canvas elements) or, when an intrinsic fallback is not applicable, by using a manifest-level [Packages 3.1] fallback.

Authors must ensure that any output scripts generate meets Core Media Type requirements [EPUB 3.1].

note

The scripted property [Manifest Vocab] of the manifest item element indicates that an EPUB Content Document is a Scripted Content Document.

5.3 Reading System Conformance

A Reading System that supports scripting must meet the following criteria:

It should support container-constrained scripting in reflowable EPUB Content Documents.
It should support spine-level scripting in fixed-layout documents.
It should support spine-level scripting in reflowable EPUB Content Documents that use the "scrolled-doc" or "scrolled-continuous" presentation modes defined by the rendition:flow property [Packages 3.1]. Similarly, if it supports spine-level scripting in reflowable EPUB Content Documents, it must implement the "scrolled-doc" presentation mode and should implement the "scrolled-continuous" presentation mode.
It may support scripting in other contexts, but this specification does not address such scripting. As a result, the use of scripting in these contexts might not be consistent across Reading Systems.
It may render Scripted Content Documents as an interactive, scripted user agent according to [HTML].
It must not allow a container-constrained script to modify the DOM of the parent Content Document or other contents in the EPUB Publication, and must not allow it to manipulate the size of its containing rectangle. (Note: Even if a script is not container-constrained, the Reading System may impose restrictions on modifications (see also the dom-manipulation feature).)
It may place additional limitations on the capabilities provided to scripts during execution (e.g., limiting networking).
It must implement the JavaScript navigator extension object epubReadingSystem defined in Appendix A, JavaScript epubReadingSystem Object. It also must support the dom-manipulation and layout-change features defined in Features in container-constrained scripting contexts.

A Reading System that does not support scripting must meet the following criteria:

It must process fallbacks for scripted content as defined in Fallbacks for Scripted Content Documents.

note

Reading Systems might render Scripted Content Documents in a manner that disables other EPUB capabilities and/or provides a different rendering and user experience (e.g., by disabling pagination).

Authors choosing to restrict the usage of scripting to the container-constrained model will ensure a more consistent user experience between scripted and non-scripted content (e.g., consistent pagination behavior).

Authors are advised to use declarative techniques whenever practical to increase the interoperability, longevity and accessibility of their EPUB Publications, and avoid the inclusion of scripting whenever practical.

5.4 Security Considerations

This section is informative

All EPUB Authors and EPUB Reading System developers have to be aware of the security issues that arise when scripted content is executed by a Reading System. As the underlying scripting model employed by Reading Systems and browsers is the same, the same kinds of issues encountered in Web contexts have to be taken into consideration.

Each Reading System has to establish if the scripts in a particular document are to be trusted or not. It is advised that all scripts be treated as untrusted (and potentially malicious), and that all vectors of attack be examined and protected against. In particular, the following need to be considered:

an attack against the runtime environment (e.g., stealing files from a user's hard drive);
an attack against the Reading System itself (e.g., stealing a list of a user's books or causing unexpected behavior);
an attack of one Content Document against another (e.g., stealing data that originated in a different document);
an attack of an unencrypted script against an encrypted portion of a document (e.g., an injected malicious script extracting protected content);
an attack against the local network (e.g., stealing data from a server behind a firewall).

The following recommendations are provided as a guide to handling untrusted scripts:

Reading Systems need to behave as if a unique domain were allocated to each Content Document, as browser-based security relies heavily on document URLs and domains. Adopting this approach will isolate documents from each other and from other Internet domains, thereby limiting access to external URLs, cookies, DOM storage, etc.

Reading Systems that enable scripting and network access also need to consider including methods to notify the user that network activity is occurring and/or that allow them to disable it.

note

In practice, Reading Systems might share domains across documents, but they still need to maintain isolation between documents.

If parts of a document are encrypted and parts are not, or if different encryption keys are used for different parts of the document, a unique per-document domain might not provide sufficient protection.
If a Reading System allows persistent data to be stored, that data needs to be treated as sensitive. Scripts might save persistent data through cookies and DOM storage, but Reading Systems might block such attempts. Reading Systems that do allow data to be stored have to ensure that it is not made available to other unrelated documents (e.g., ones that could have been spoofed). In particular, checking for a matching document identifier (or similar metadata) is not a valid method to control access to persistent data.

Reading Systems that allow local storage also need to provide methods for users to inspect, disable, or delete that data. The data needs to be destroyed if the corresponding EPUB Publication is deleted.

Note that compliance with these recommendations does not guarantee protection from the possible attacks listed above; developers have to examine each potential vulnerability within the context of their Reading System.

5.5 Event Model Considerations

This section is informative

Reading Systems need to follow the DOM Event model as per [HTML] and pass UI events to the scripting environment before performing any default action associated with these events. Reading System implementers need to ensure that scripts cannot disable critical functionality (such as navigation) to constrain the extent to which a potentially malicious script could impact their Reading Systems. As a result, although the scripting environment needs to be able to cancel the default action of any event, some events either might not be passed through or might not be cancelable.

Authors need to take into account the wide variety of possible Reading System implementations when adding scripting functionality to their EPUB Publications (e.g., not all devices have physical keyboards, and in many cases a soft keyboard is activated only for text input elements). Consequently, relying on keyboard events alone is not advised; alternative ways to trigger a desired action always need to be provided.

6 Fixed Layouts

6.1 Introduction

This section is informative

This section defines rules for the expression and interpretation of dimensional properties of EPUB Content Documents marked as pre-paginated in the Package Document.

This specification does not define how the initial containing block [CSS Snapshot] will be placed within the Reading System Content Display Area.

note

Refer to Fixed-Layout Properties [Packages 3.1] for information on how to designate that a Rendition, or its individual spine items, are to be rendered in a pre-paginated manner (i.e., with fixed width and height dimensions).

6.2 Content Conformance

A conformant Fixed-Layout Document must meet all of the following criteria:

It must specify its initial containing block [CSS Snapshot] as defined in Initial Containing Block Dimensions.

6.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing Fixed-Layout Documents:

It should allocate the full Content Display Area for the document, as defined in Viewport Rendering.
It must use the dimensions expressed in the viewport meta tag to render XHTML Content Documents, as defined in Expressing the ICB in HTML.
It must use the dimensions as defined in Expressing the ICB in SVG to render SVG Content Documents.

6.4 Viewport Rendering

When rendering Fixed-Layout Documents, the default intent is that the Content Display Area should occupy as much of the available Viewport area as possible. Reading Systems should not inject additional content such as border, margins, headers or footers into the Viewport or the application area surrounding the Viewport.

note

The exposure of Reading System control widgets to the user is implementation-specific and not included in the above behavioral expectations.

6.5 Initial Containing Block Dimensions

6.5.1 Expressing in HTML

For XHTML Content Documents, the initial containing block [CSS Snapshot] dimensions must be expressed in a viewport meta tag using the syntax defined in [CSS Device Adaptation]. In this version of this specification, only the width and height expressions must be recognized by Reading Systems.

The following example shows a viewport meta tag.

<head>
   …
   <meta name="viewport" content="width=1200, height=600"/>
   …
</head>

Reading Systems must clip XHTML content to the initial containing block (ICB) dimensions declared in the viewport meta tag — content positioned outside of the initial containing block will not be visible. When the ICB aspect ratio does not match the aspect ratio of the Reading System Content Display Area, Reading Systems may position the ICB inside the area to accommodate the user interface; in other words, added letter-boxing space may appear on either side (or both) of the content.

6.5.2 Expressing in SVG

For SVG Content Documents, the root svg element must include one or both of:

the viewBox attribute;
the height and width (and optional x and y) attributes.

It is recommended to use only the viewBox attribute to ensure proper rescaling of the SVG Content Document, as needed.

The following example shows a viewBox attribute declaration for an SVG Content Document with an aspect ratio of 844 pixels wide by 1200 pixels high.

<svg xmlns="http://www.w3.org/2000/svg"
     version="1.1" 
     viewBox="0 0 844 1200">
   …
</svg>

If only the [SVG] viewBox attribute is present, the coordinate system it defines is mapped to the Viewport, keeping the aspect ratio, thereby establishing the initial containing block (ICB) in pixels [CSS Snapshot]. The result of this mapping is typically the bounds of the Viewport.

If only the x, y, height and width attributes are present, they should be defined in pixel values (establishing the ICB). Note that if the pixel values defined by x, y, height and width attributes exceed the Viewport's pixel values, the graphic will be clipped on the Viewport boundaries (i.e., the graphics will not be rescaled).

If the coordinate system is defined by the viewBox and the width/height values, the coordinate system defined by the viewBox is mapped on the boundaries as described in the previous item.

note

See [SVG] for more details on the interplay between viewBox and the width/height values.

7 Pronunciation Lexicons

7.1 Introduction

This section is informative

The W3C Pronunciation Lexicon Specification [PLS] defines syntax and semantics for XML-based pronunciation lexicons to be used by Automatic Speech Recognition and Text-to-Speech (TTS) engines.

The following sections define conformance criteria for PLS documents when included in EPUB Publications, and rules for associating PLS Documents with XHTML Content Documents.

note

For more information on EPUB 3.1 features related to synthetic speech, refer to Text-to-speech [EPUB3 Overview].

7.2 EPUB Publication Conformance

A conformant Rendition of an EPUB Publication must meet all of the following criteria for inclusion of PLS Documents:

PLS Documents may be associated with XHTML Content Documents. Each XHTML Content Document may contain zero or more PLS Document associations.
PLS Documents must be associated with the XHTML Content Document to which they apply using the [HTML] link element with its rel attribute set to "pronunciation" and its type attribute set to the PLS media type "application/pls+xml".

The link element hreflang attribute should be specified on each PLS link, and its value must match the language for which the pronunciation lexicon is relevant [PLS] when specified.
PLS Documents must meet the content conformance criteria defined in PLS Documents — Content Conformance.
PLS Documents must be represented and located as defined in EPUB Package — Conformance [Packages 3.1].

Examples

The following example shows two PLS Documents (one for Chinese and one for Mongolian) associated with an XHTML Content Document.

<html … >    
    <head>
        …
        <link rel="pronunciation" type="application/pls+xml" hreflang="zh" href="../speech/zh.pls"/>
        <link rel="pronunciation" type="application/pls+xml" hreflang="mn" href="../speech/mn.pls"/>
    </head>        
    …
</html>

7.3 Content Conformance

A PLS Document must meet all of the following criteria:

Document Properties

It must meet the conformance constraints for XML documents defined in XML Conformance [EPUB 3.1].

It must be valid to the RELAX NG schema for PLS documents available at the URI https://www.w3.org/TR/2008/REC-pronunciation-lexicon-20081014/ [PLS].

File Properties

The PLS Document filename should use the file extension .pls.

7.4 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing PLS Documents:

  Reading Systems with Text-to-Speech (TTS) capabilities should support PLS.

  Reading Systems that support PLS must process PLS documents as defined in [PLS].

  Reading Systems that support PLS must apply the supplied pronunciation instructions to all text nodes in the current XHTML Content Document whose language [HTML] matches the language for which the pronunciation lexicon is relevant [PLS]. The algorithm for matching language tags is defined in BCP47.

   When a pronunciation rule is specified more than once for a given string target in a given language, the last occurrence of the rule takes precedence, in such a way that any previously-defined pronunciation rule gets overridden.

  Reading Systems that support PLS and the SSML Attributes must let any pronunciation instructions provided via the ssml:ph attribute take precedence in cases where a pls:grapheme matches a text node of an element that carries the ssml:ph attribute.

Appendix A. JavaScript epubReadingSystem Object

A.1 Interface Definition

This specification extends the [HTML] Navigator object as follows.

[Exposed=(Window)]
interface EpubReadingSystem {
    [Unforgeable] readonly attribute DOMString name;
    [Unforgeable] readonly attribute DOMString version;
    [Unforgeable] boolean hasFeature(DOMString feature, optional DOMString version);
};

partial interface Navigator {
    [Unforgeable, SameObject] readonly attribute EpubReadingSystem epubReadingSystem;
};

[WEB IDL] notation.

note

This specification does not define an epubReadingSystem property extension for the WorkerNavigator object [Web Workers]. Reading Systems therefore do not have to expose the epubReadingSystem object in the scripting context of Workers, and Authors cannot rely on its presence.

A.2 Description

The epubReadingSystem object provides an interface through which a Scripted Content Document can query information about a user's Reading System.

The object exposes properties of the Reading System (its name and version), and provides the hasFeature method which can be invoked to determine the features it supports.

Example JavaScript function that displays the name of the current Reading System.

alert("Reading System name: " + navigator.epubReadingSystem.name);

Reading Systems must expose the epubReadingSystem object on the navigator object of all loaded Scripted Content Documents, including any nested container-constrained scripting contexts. Reading Systems must ensure that the epubReadingSystem object is available no later than when the DOMContentLoaded event is triggered [HTML].

note

Reading systems implementations might create cloned instances of the epubReadingSystem object in Scripted Content Documents for technical feasibility reasons. In such cases, the Reading System has to ensure that the object’s state — as reflected by the values of its properties and methods — is consistently maintained across all copied instances.

A.3 Properties

The following properties must be made available for retrieving information about the Reading System.

Required epubReadingSystem properties

Name	Description
name	Returns a `String` value representing the name of the Reading System (e.g., "`iBooks`", "`Kindle`").
version	Returns a `String` value representing the version of the Reading System (e.g., "`1.0`", "`2.1.1`").

A.4 Methods

A.4.1 hasFeature

A.4.1.1 Description

The hasFeature method returns a boolean value indicating whether any version of the specified feature is supported, or undefined if the specified feature is not recognized.

The optional version parameter is included for querying custom features that could change in incompatible ways over time. The return value indicates support only for the specified version of the feature.

Authors should not include the version parameter when querying features defined in this specification — these features are considered versionless. If a Reading System supports a feature defined in this specification, it must ignore any supplied version parameter and return a true value.

Example JavaScript function that displays whether the current Reading System supports scripted manipulation of the DOM.

var feature = "dom-manipulation";

var conformTest = navigator.epubReadingSystem.hasFeature(feature);

alert("Feature " + feature + " supported?: " + conformTest);

A.4.1.2 Features

The following table lists the set of features that Reading Systems that support the epubReadingSystem object must recognize (i.e., provide a return value for). Support for these features is optional.

Required epubReadingSystem features

Name	Description
`dom-manipulation`	Scripts may make structural changes to the document’s DOM (applies to spine-level scripting only).
`layout-changes`	Scripts may modify attributes and CSS styles that affect content layout (applies to spine-level scripting only).
`touch-events`	The device supports touch events and the Reading System passes touch events to the content.
`mouse-events`	The device supports mouse events and the Reading System passes mouse events to the content.
`keyboard-events`	The device supports keyboard events and the Reading System passes keyboard events to the content.
`spine-scripting`	Indicates whether the Reading System supports spine-level scripting (e.g., so a container-constrained script can determine whether any actions that depend on scripting support in a Top-level Content Document have any chance of success before attempting them).

Additional features may be added by Reading System developers, but future versions of this specification might append to this list in ways that could conflict or be incompatible with any such custom additions.

Status of this Document

1 Overview

1.1 Purpose and Scope

1.2 Relationship to Other Specifications

1.2.1 Relationship to HTML

caution

1.2.2 Relationship to SVG

caution

1.2.3 Relationship to CSS

1.3 Terminology

1.4 Typographic Conventions

note

caution

1.5 Conformance Statements

1.6 Namespace prefix mapping

2 XHTML Content Documents

2.1 Introduction

2.2 Content Conformance

note

2.3 Reading System Conformance

2.4 HTML Extensions

note

2.4.1 Semantic Inflection

2.4.1.1 Introduction

2.4.1.2 The epub:type Attribute

Examples

2.4.1.3 Vocabulary Association

Default Vocabulary

Reserved Prefixes

The prefix Attribute

2.4.1.4 Processing Requirements

2.4.2 Semantic Enrichment

2.4.2.1 Introduction

2.4.2.2 RDFa

2.4.2.3 Microdata

2.4.3 SSML Attributes

2.4.3.1 Introduction

note

2.4.3.2 The ssml:ph attribute

2.4.3.3 The ssml:alphabet attribute

note

2.4.4 Alternate Style Tags

2.4.5 Custom Attributes

note

2.5 HTML Deviations and Constraints

2.5.1 Embedded MathML

2.5.1.1 Introduction

note

2.5.1.2 Content Conformance

2.5.1.3 Reading System Conformance

2.5.1.4 Fallback Content

note

2.5.2 Embedded SVG

note

2.5.2.1 Embedded SVG and CSS

note

2.5.3 Unicode Restrictions

2.5.4 Discouraged Constructs

2.5.4.1 The rp Element

2.5.4.2 The embed Element

2.5.5 Foreign Resource Restrictions

note

3 SVG Content Documents

caution

3.1 Introduction

note

3.2 Content Conformance

note

3.3 Restrictions on SVG

3.4 Reading System Conformance

3.5 Semantic Inflection

4 CSS Style Sheets

4.1 Introduction

4.2 Content Conformance

note

4.3 Reading System Conformance

4.4 Prefixed Properties

caution

4.4.1 CSS Writing Modes

4.4.2 CSS Text Level 3

2.4.1.2 The `epub:type` Attribute

The `prefix` Attribute

2.4.3.2 The `ssml:ph` attribute

2.4.3.3 The `ssml:alphabet` attribute

2.5.4.1 The `rp` Element

2.5.4.2 The `embed` Element

B.1.2 The `epubReadingSystem` Object layoutStyle property