CSS3 Text Module (original) (raw)

Abstract

This document presents a set of text formatting properties for CSS3. Many of these properties already existed in CSS2 [CSS2]. Many of the new properties have been added to address basic requirements in international text layout, particularly for East Asian and bidirectional text.

Status of This Document

This specification is one of the "modules" for the upcoming CSS level 3 (CSS3) specification. It has been developed by the CSS Working Group which is part of the Style Activity (see summary). It contains features to be included in CSS level 3.

This is a Candidate Recommendation, which means W3C believes the specification is ready to be implemented.

All persons are encouraged to review and implement this specification and send comments to the (archived) public mailing list www-style (see instructions). W3C Members can also send comments directly to the CSS Working Group.

For this specification to become a W3C Recommendation, the following criteria must be met:

  1. There must be at least two interoperable implementations for every feature in the specification.
    For the purposes of this criterion, we define the following terms:
    feature
    a section or subsection in the specification
    interoperable
    passing the respective test case(s) in the test suite, or, if the implementation is not a web browser, an equivalent test. Every relevant test in the test suite should have an equivalent test created if such a user agent (UA) is to be used to claim interoperability. In addition if such a UA is to be used to claim interoperability, then there must one or more additional UAs which can also pass those equivalent tests in the same way for the purpose of interoperability. The equivalent tests must be made publically available for the purposes of peer review.
    implementation
    a user agent which:
    1. implements the feature.
    2. is available (i.e. publicly downloadable or available through some other public point of sale mechanism). This is the "show me" requirement.
    3. is shipping (i.e. development, private or unofficial versions are insufficient).
    4. is not experimental (i.e. is intended for a wide audience and could be used on a daily basis.)
  2. A minimum of six months of the CR period must have elapsed. This is to ensure that enough time is given for any remaining major errors to be caught.

The comments that the CSS WG received on the last working draft, together with responses and resulting changes are listed in the disposition of comments.

This document has been produced as a combined effort of the W3C Internationalization Activity, and theStyle Activity. It also includes extensive contribution made by participants in the XSL Working Group (members only). Finally, some of the proposal surfaced first in the Scalable Vector Graphics (SVG) 1.1 Specification [SVG1.1]. The text has been duplicated in this document to reflect which properties and specification should eventually be referenced in CSS itself.

Patent disclosures relevant to CSS may be found on the Working Group's public patent disclosure page.

To find the latest version of this Working Draft, please follow the "Latest version" link above, or visit the list of W3C Technical Reports.

Contents

1. Dependencies on other modules

This CSS3 module depends on the following CSS3 modules:

It has non-normative (informative) references to the following CSS3 modules:

2. Introduction

In both CSS1 and CSS2, text formatting has been limited to simple effects like: text decoration, text alignment and letter spacing. However, international typography contains types of formatting that could not be achieved without using special workarounds or graphics.

Along with already existing text-related properties, this document presents a number of new CSS properties to represent such formatting. The features this proposal covers include two of the most important features for East Asian typography: vertical text and layout grid.

There are a number of illustrations in this document for which the following legend is used:

Wide n

- wide-cell glyph (e.g. Han) which is the n-th glyph in the text run,

Narrow n

- narrow-cell glyph (e.g. Latin) which is the n-th glyph in the text run,

Connected n

- connected glyph (e.g. Arabic) which is the n-th glyph in the text run.

Many typographical properties in East Asian typography depends on the fact that a character is typically rendered as either a wide or narrow glyph. All characters described by the Unicode Standard [UNICODE] can be categorized by a width property. This is covered by the Unicode Standard Annex #11, East Asian Width [UAX-11].

The orientation which the above symbols assume in the diagrams corresponds to the orientation that the glyphs they represent are intended to assume when rendered in the UA (user agent). Spacing between these glyphs in the diagrams is usually symbolic, unless intentionally changed to make a point.

Furthermore, all properties, in addition to the noted values, take 'initial' and 'inherit'. These values are not repeated in property value enumerations.

This module uses extensively the 'before', 'after', 'start' and 'end' notation to specify the four edges of a box relative to its text advance direction, independently of its absolute orientation in terms of 'top', 'bottom', 'left' and 'right' (corresponding respectively to the 'before', 'after', 'start' and 'end' positions in a typical Western text layout). This notation is also used extensively in [XSL1.0] for the same purpose.

The term 'Latin' is used frequently in this document to designate behavior shared among popular writing scripts in Europe and America based on the Latin, Greek and Cyrillic scripts.

Finally, in this document, requirements are expressed using the key words "MUST", "MUST NOT", "REQUIRED", "SHALL" and "SHALL NOT". Recommendations are expressed using the key words "SHOULD", "SHOULD NOT" and "RECOMMENDED". "MAY" and "OPTIONAL" are used to indicate optional features or behavior. These keywords are used in accordance with [RFC2119]. For legibility these keywords are used in small caps form.

3. Text layout

3.1. Text layout introduction

This section describes the text layout features supported by CSS, which includes support for various international writing directions, such as left-to-right (e.g., Latin scripts), right-to-left (e.g., Hebrew or Arabic), bidirectional (e.g., mixing Latin with Arabic) and vertical (e.g., Asian scripts).

The 'direction' property, already defined in CSS2, determines an inline-progression. The 'block-progression' property determines a block-progression. The 'writing-mode' shorthand combines inline and block progression together. For example, Latin scripts are typically written with a left to right inline-progression and a top to bottom block-progression.

The glyph orientationis the orientation of the rendered visual shape of characters relative to the block-progression and the bottom of the block box.

Within a line, the inline-progression for characters is based on the current glyph orientation, the metrics of the glyph just rendered, kerning tables in the font, and the current values of various attributes and properties, such as the spacing properties.

For many combinations of 'direction', 'block-progression' and glyph orientation values, the proper directionality and ordering of text are determined the Unicode Bidirectional Algorithm [UAX9]. CSS relies on that algorithm to achieve proper bidirectional text rendering and possible reordering. Furthermore, with the 'unicode-bidi' property, the style sheet can influence the bidirectional algorithm by allowing new embedding levels and direction overrides.

Note: The Unicode Standard Annex #9, The Bidirectional Algorithm [UAX9]defines a bidirectional algorithm that determines the character directionality for bidirectional text. The display ordering of bidirectional text depends upon the directional properties of the characters in the text.

The HTML 4.01 specification ([HTML401], section 8.2) defines bidirectionality behavior for HTML elements. Conforming HTML user agentsMAY therefore ignore the 'direction' and 'unicode-bidi' properties in author and user style sheets. The style sheet rules that would achieve the bidirectionality behavior specified in HTML 4.01 are given in the sample style sheet. The HTML 4.01 specification also contains more information on bidirectionality issues.

Note: HTML 4.01 only allows the change of inline-progression whereas the 'block-progression' and the 'writing-mode'properties allow the change of the block-progression.

3.2. Setting the inline-progression and block-progression: the 'direction', 'block-progression' properties and the shorthand 'writing-mode' property

Name: direction
Value: ltr | rtl
Initial: ltr
Applies to: all elements and generated content, but see prose
Inherited: yes
Percentages: N/A
Media: visual
Computed value: specified value (except for initial and inherit)

The 'direction' property sets the inline-progression value. Possible values:

ltr

Left-to-right direction.

rtl

Right-to-left direction.

This property specifies the inline-progression and the direction of embeddings and overrides (see 'unicode-bidi') for the Unicode Bidirectional Algorithm [UAX9]. The values 'ltr' and 'rtl' are interpreted relative to the 'block-progression'. For example, a 'ltr' inline-progression goes from the left to the right of the box when the 'block-progression' is set to 'tb'; the same 'ltr' inline-progression goes from the top to the bottom of the box when 'block-progression' is set to 'rl'.

This property also affects the direction of table column layout, the direction of theoverflow when determined by the inline-progression (such as the 'start' and 'end' values of the 'text-align'property), the initial alignment of text and the position of an incomplete last line in a block in case of 'text-align: justify' and many other properties affected by inline-progression changes.

Note: Even when the inline-progression is left-to-right or right-to-left, some or all of the character content within a given element might advance in the opposite direction because of the Unicode Bidirectional Algorithm [UAX9] or because of explicit text advance overrides due to the usage of this property and 'unicode-bidi' on children elements.

For the 'direction' property to have any effect on inline-level elements, the following conditions must be met:

For more on bidirectional text, see the section about Embedding and override.

Note: The 'direction' property, when specified for table column elements, is not inherited by cells in the column since column elements are never the ancestors of their constituent cell elements. Thus, CSS cannot easily capture the "dir" attribute inheritance rules described in [HTML4.01], section 11.3.2.

Name: block-progression
Value: tb | rl lr
Initial: tb
Applies to: all elements and generated content
Inherited: yes
Percentages: N/A
Media: visual
Computed value: specified value (except for initial and inherit)

The 'block-progression' property sets the block-progression value and the flow orientation. Possible values:

tb

Top-to-bottom direction. The flow orientation is horizontal.

rl

Right-to-left direction. The flow orientation is vertical.

lr

Left-to-right direction. The flow orientation is vertical.

An inline-level element that has a different 'block-progression' from its parent becomes an 'inline-block' element[CSS3-box]. Two cases are possible:

  1. The two block-progressions are perpendicular to each other (for example, 'tb' and 'lr'). In such cases, the content height of the element within the line box height is determined by its maximum inline progression dimension (advance width). However, the resulting line height is determined by other properties such as the 'text-height' and the 'line-stacking-strategy' [CSS3-line].
  2. The two block-progressions are parallel to each other (for example, 'rl' and 'lr'). In such cases, the content width of the element within the line box width is determined by its maximum inline progression dimension.

In horizontal flow orientations, the top and bottom margins can be collapsed. For vertical flow orientations, the left and right margin can be collapsed. See "Collapsing margins" in the CSS3 Box module [CSS3-box] for the details of collapsing margins.

Name: writing-mode
Value: lr-tb | rl-tb tb-rl tb-lr
Initial: not defined for shorthand properties
Applies to: all elements and generated content
Inherited: yes
Percentages: N/A
Media: visual
Computed value: see individual properties

The 'writing-mode' property is a shorthand property for the 'direction' property and the 'block-progression' property. Although strictly speaking, the property has no initial value, it is equivalent to 'lr-tb'. The definition of the property values are established by the following table, which shows the setting of the constituent properties and example of common usage.

writing-mode: direction: block-progression: Common Usage:
lr-tb ltr tb Latin-based, Greek, Cyrillic writing systems (and many others)
rl-tb rtl tb Arabic, Hebrew writing systems
tb-rl ltr rl some East Asian writing systems
tb-lr rtl lr Mongolian writing system

In the following example, two blocks elements (1 and 3) separated by an image (2) are presented in various flow orientations.

Here is a diagram of a horizontal flow ("writing-mode: lr-tb"):

Diagram of a horizontal flow

Here is a diagram for a vertical flow used in East Asia ("writing-mode: tb-rl"):

Diagram of a vertical flow with right-to-left block-progression

And finally, here is a diagram for another flow used for Uighur and Mongolian ("writing-mode: tb-lr"):

Diagram of a vertical flow with left-to-right block-progression

In East Asian documents, it is often preferred to display certain Latin-based strings, such as numerals in a year, always in a horizontal flow orientation regardless of the flow orientation of the line of text these strings appear in, as in:

Layout of Tate Naka Yoko, showing a group of glyphs appearing horizontally in a vertical column of text Example of Tate Naka Yoko, showing the year 1996 appearing horizontally in a column of vertical text

Horizontal in vertical ("Tate-chu-yoko")

In Japanese, this effect is known as "Tate-chu-yoko". In order to achieve it in an XHTML context, the Latin string should be enclosed in a span element with a horizontal flow orientation, as in:

.date {writing-mode: lr-tb;} 1996

3.3. Glyph orientation within a text run: the 'glyph-orientation-vertical'and 'glyph-orientation-horizontal'properties

In some cases, it is required to alter the orientation of a sequence of glyphs relative to the block-progression. The requirement is particularly applicable to vertical layouts of East Asian documents, where sometimes half-width Latin text is to be displayed horizontally and other times vertically.

Two properties control the glyph orientation relative to the block-progression. 'glyph-orientation-vertical'controls glyph orientation when the flow orientation is vertical. 'glyph-orientation-horizontal'controls glyph orientation when the flow orientation is horizontal.

Name: glyph-orientation-vertical
Value: | auto upright inline
Initial: auto
Applies to: all elements and generated content
Inherited: yes
Percentages: N/A
Media: visual
Computed value: specified value (except for initial and inherit)

Although any angle value may be used, the behavior related to the value is determined by rounding it to the nearest multiple of 90 degrees.

auto

The glyph orientation is determined automatically based on the Unicode character code of the rendered character.

upright

Glyphs are oriented as if an of "0deg"had been specified. However all vertical alternates of the glyphs should be used. Enclosing punctuations such as parentheses should be oriented to face in the text they enclose. The user agent may use heuristic to determine the best orientation for symbols that are flow orientation dependent.

inline

All glyphs are laid out top to bottom regardless of inherent direction. The embedding levels, as determined by the bidirectional algorithm [UAX9], are used to set the orientation of some glyphs (see following prose).

The bidirectional algorithm [UAX9] applies differently depending on the value of the glyph vertical orientation, either specified as an value, or as implied by one of the 'glyph-orientation-vertical'keyword values. Possible effects:

Conforming user agents MUST at least support the 'auto' and "90deg"value. The user agent MAY round the actual value of the angle to the values of glyph rotation supported by the user agent. However, this does not affect the computed value.

The glyph orientation affects the amount that the current text position advances as each glyph is rendered. It also affects how the glyph is aligned relative to the baseline. When the flow orientation is vertical and the'glyph-orientation-vertical' value results in a glyph orientation angle which is a multiple of 180deg, then the current text position is incremented according to the vertical metrics of the glyph, and the glyph is aligned using the vertical alignment-point as described in the CSS3 Line module [CSS3-line].

The diagrams below illustrate different uses of 'glyph-orientation-vertical'. The diagram on the left shows the result of the mixing of full-width ideographic characters with normal-width Latin characters when 'glyph-orientation-vertical'for the span containing the Latin characters is either auto or "90deg". The diagram on the right show the result of mixing full-width ideographic characters with normal-width Latin characters when the span containing the Latin characters is specified to have a 'glyph-orientation-vertical' of "0deg".

Note: The effect on the right can be also be achieved by using full-width Latin characters and using 'glyph-orientation-vertical: auto' for the span containing the ideographic characters and the full-width Latin characters.

Layout of mixed glyphs in vertical-ideographic mode. Wide-cell glyphs are upright, Non-wide-cell glyphs are rotated by 90 degrees. Example of mixed Japanese and English in vertical-ideographic layout. Japanese glyphs are upright, English rotated. Layout of mixed glyphs in vertical mode. All glyphs are upright. Example of mixed Japanese and English in vertical layout. All glyphs are upright.

Name: glyph-orientation-horizontal
Value: | auto inline
Initial: auto
Applies to: all elements and generated content
Inherited: yes
Percentages: N/A
Media: visual
Computed value: specified value (except for initial and inherit)

Although any angle value may be used, the behavior related to the value is determined by rounding it to the nearest multiple of 90 degrees.

auto

The glyph orientation relative to the inline-progression is determined automatically based on the Unicode character code of the rendered character.

inline

All glyphs are laid out left to right regardless of inherent direction. The embedding levels, as determined by the bidirectional algorithm [UAX9], are used to set the orientation of some glyphs (see following prose).

The bidirectional algorithm [UAX9] applies differently depending on the value of the glyph horizontal orientation, either specified as an value, or as implied by one of the 'glyph-orientation-horizontal'keyword values. Possible effects:

Conforming user agents MUST at least support the 'auto' and "0deg"value. The user agent MAY round the actual value of the angle to the values of glyph rotation supported by the user agent. However, this does not affect the computed value.

The glyph orientation affects the amount that the current text position advances as each glyph is rendered. It also affects how the glyph is aligned relative to the baseline. When the inline-progression is horizontal and the 'glyph-orientation-horizontal' value results in a glyph orientation angle which is a multiple of "180deg", then the current text position is incremented according to the horizontal metrics of the glyph, and the glyph is aligned using the horizontal alignment-point as described in the CSS3 Line module [CSS3-line].

3.4. Embedding and override: the 'unicode-bidi'property

Name: unicode-bidi
Value: normal | embed bidi-override
Initial: normal
Applies to: all elements and generated content, but see prose
Inherited: no
Percentages: N/A
Media: visual
Computed value: specified (except for initial and inherit)

This property allows further control of the Unicode Bidirectional Algorithm [UAX9] by allowing new embedding levels or direction overrides. Values for this property have the following meanings:

normal

The element does not open an additional level of embedding with respect to the bidirectional algorithm. For inline-level elements, implicit reordering works across element boundaries.

embed

If the element is inline-level, this value opens an additional level of embedding with respect to the bidirectional algorithm. The direction of this embedding level is given by the 'direction' property. Inside the element, reordering is done implicitly. This corresponds to adding a LRE (U+202A; for 'direction: ltr') or RLE (U+202B; for 'direction: rtl') at the start of the element and a PDF (U+202C) at the end of the element.

bidi-override

For inline-level elements this creates an override. For block-level elements this creates an override for inline-level descendents not within another block. This means that inside the element, reordering is strictly in sequence according to the 'direction'property; the implicit part of the bidirectional algorithm is ignored. This corresponds to adding a LRO (U+202D; for 'direction: ltr') or RLO (U+202E; for 'direction: rtl') at the start of the element and a PDF (U+202C) at the end of the element.

The final order of characters in each block-level element is the same as if the bidirectional control codes had been added as described above, mark-up had been stripped, non-textual entities such as images treated as object replacement characters (U+FFFC), and the resulting character sequence had been passed to an implementation of the Unicode Bidirectional Algorithm [UAX9] for plain text that produced the same line-breaks as the styled text.

Note: In order to be able to flow inline boxes in a uniform direction (either entirely left-to-right or entirely right-to-left), more inline boxes (including anonymous inline boxes) may have to be created, and some inline boxes may have to be split up and reordered before flowing.

Because the Unicode algorithm has a limit of 61 levels of embedding, care should be taken not to use 'unicode-bidi' with a value other than 'normal' unless appropriate. In particular, a value of 'inherit' should be used with extreme caution. However, for elements that are, in general, intended to be displayed as blocks, a setting of 'unicode-bidi: embed' is preferred to keep the element together in case display is changed to inline (see example below).

The following example shows an XML document with bidirectional text. It illustrates an important design principle: DTD designers should take bidirectionality into account both in the language proper (elements and attributes) and in any accompanying style sheets. The style sheets should be designed so that bidirectional rules are separate from other style rules. The bidirectional rules should not be overridden by other style sheets so that the document language's or DTD's bidirectional behavior is preserved.

Example(s):

In this example, lowercase letters in element contents stand for inherently left-to-right characters and uppercase letters represent inherently right-to-left characters:

HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5 HEBREW6 HEBREW7 HEBREW8
english9 english10 english11 HEBREW12 HEBREW13 english14 english15 english16 english17 HEBREW18 english19 HEBREW20

Since this is XML, the style sheet is responsible for setting the writing direction. This is the style sheet:

/* Rules for bidirectional */ div:lang(he) {direction: rtl} quo:lang(he) {direction: rtl; unicode-bidi: embed} par:lang(en) {direction: ltr}

/* Rules for presentation */ div, par {display: block} emph {font-weight: bold}

The div element with xml:lang="he" is a block with a right-to-left base direction, the div element with xml:lang="en" is a block with a left-to-right base direction. The par elements are blocks that inherit the base direction from their parents. Thus, the first two par elements are read starting at the top right, the final three are read starting at the top left.

The emph element is inline-level, and since its value for'unicode-bidi' is 'normal' (the initial value), it has no effect on the ordering of the text. The quo element, on the other hand, creates an embedding.

The formatting of this text might look like this if the line length is long:

           5WERBEH 4WERBEH english3 2WERBEH 1WERBEH

                            8WERBEH **7WERBEH** 6WERBEH

english9 english10 english11 13WERBEH 12WERBEH

english14 english15 english16

english17 20WERBEH english19 18WERBEH

Note that the quo embedding causes HEBREW18 to be to the right of english19.

If lines have to be broken, it might be more like this:

   2WERBEH 1WERBEH

-EH 4WERBEH english3 5WERB

-EH 7WERBEH 6WERBEH 8WERB

english9 english10 en- glish11 12WERBEH 13WERBEH

english14 english15 english16

english17 18WERBEH 20WERBEH english19

Because HEBREW18 must be read before english19, it is on the line above english19. Just breaking the long line from the earlier formatting would not have worked. Note also that the first syllable from english19 might have fit on the previous line, but hyphenation of left-to-right words in a right-to-left context, and vice versa, is usually suppressed to avoid having to display a hyphen in the middle of a line.

3.5. Script character classification: the 'text-script' property

Many text layout behaviors are relative to the script classification of the text content. The Unicode Technical Report [UAX-24]: "Script names" determines a script identifier for all characters.

Note: There is also an ISO draft standard [ISO15924] addressing script identification.

For some operations, such as baseline alignment, a dominant script is required to determine an alignment strategy for the whole element. A dominant script is established by setting the 'text-script' property to an explicit script identifier in conformance with [UAX-24], or by using the heuristic determination computed by the user agent when the 'text-script' value is set to 'auto'.

In many other cases, such as white space handling or text justification, the script property is used on a character by character basis. In those cases, the 'text-script' property can be used to set an homogeneous value for all characters of the element through the usage of an explicit script identifier. But, if the 'text-script' is set to 'auto', the user agent will establish a script property value for each character of the element.

Name: text-script
Value: auto |