CSS3 module: text

Abstract

This document presents a set of text formatting properties for CSS3. Many of these properties already existed in CSS 2CSS2 [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 document is a working draft of the CSS working group which is part of the Style activity. It contains a proposal for features to be included in CSS level 3.

This is the second last call for comments, beforecomments. All comments in response to the working group will decide ifprevious call have been processed: see the draftdisposition of comments. It is ready forexpected that a Candidate Recommendation.Recommendation will follow shortly. The deadline for comments on this draft is 27 November 2002.5 March 2003.

Feedback is very much welcome. Comments can be sent directly to the editor, but the mailing list www-style@w3.org (see instructions) is also open and is preferred for discussion of this and other drafts in the Style area. The mailing list is archived.

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

This working draft may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". Its publication does not imply endorsement by the W3C membership or the CSS Working Group (members only).

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
• 2. Introduction
• 3. Text layout
  • 3.1. Text layout introduction
  • 3.2. Setting the inlineinline-progression and block progressions:block-progression: the 'writing-mode' and 'direction' properties
  • 3.3. Glyph orientation within a text run: the 'glyph-orientation-vertical' and 'glyph-orientation-horizontal' properties
  • 3.4. Embedding and override: the 'unicode-bidi' property
  • 3.5. Script character classification: the 'text-script' property
• 4. Text alignment and justification
  • 4.1. Text alignment: the 'text-align' property
  • 4.2. Justification: the 'text-justify' property
  • 4.3. Last line alignment: the 'text-align-last' property'property
  • 4.4. Minimum and maximum font size: the 'min-font-size' and 'max-font-size' property
  • 4.5. Additional compression: The 'text-justify-trim' property
  • 4.6. Kashida effect: the 'text-kashida-space' property'
• 5. Text indentation
  • 5.1. Summary
  • 5.2. First Line indentation: the 'text-first-indent' property
  • 5.3. Block Line indentation: the 'text-block-indent' property
  • 5.4. All Lines indentation: the 'text-indent' shorthand property
• 6. Line breaking
  • 6.1. Types of line breaking
  • 6.2. Line breaking: the 'line-break' property
  • 6.3. Word breaking: the 'word-break-cjk', 'word-break-inside' properties and the shorthand 'word-break' property
• 7. Text Wrapping, White-space Control and Text Overflow
  • 7.1. Text wrapping: the 'wrap-option' property
  • 7.2. White-space control: the 'linefeed-treatment', 'white-space-treatment', 'all-space-treatment' properties and the 'white-space' shorthand property
  • 7.3. Text overflow: the 'text-overflow-mode', 'text-overflow-ellipsis' properties and the shorthand 'text-overflow' property
• 8. Text spacing
  • 8.1. Letter spacing: the 'letter-spacing' property
  • 8.2. Word spacing: the 'word-spacing' property
  • 8.3. Punctuation trimming: the 'punctuation-trim' property
  • 8.4. Adding space: the 'text-autospace' property
  • 8.5. Text kerning: the 'kerning-mode' and 'kerning-pair-threshold' property
• 9. Text decoration
  • 9.1. Introduction
  • 9.2. Text decoration style: the 'text-underline-style', 'text-line-through-style' and 'text-overline-style' properties
  • 9.3. Text decoration color: the 'text-underline-width', 'text-line-through-width' and 'text-overline-width' properties
  • 9.4. Text decoration color: the 'text-underline-color', 'text-line-through-color' and 'text-overline-color' properties
  • 9 .4..5. Text decoration mode: the 'text-underline-mode', 'text-line-through-mode' and 'text-overline-mode' properties
  • 9 .5..6. Other text decoration simple properties: 'text-underline-position' and 'text-blink'
  • 9 .6..7. Text decoration shorthand properties: 'text-underline', 'text-line-through', 'text-overline-mode' and 'text-decoration'
  • 9 .7..8. Text shadows: the 'text-shadow' property
• 10. Document grid
  • 10.1. What is document grid?
  • 10.2. Line grid mode: the 'line-grid-mode' property
  • 10.3. Line grid progression: the 'line-grid-progression' property
  • 10.4. line-grid:Line grid: the shorthand'line-grid' shorthand property
• 11. Miscellaneous text formatting
  • 11.1. Capitalization: the 'text-transform' property
  • 11.2. Hanging punctuation: the 'hanging-punctuation' property
  • 11.3. Combining text: the 'text-combine' property'
• 12. Properties index
• 13. Profiles
• 14. Glossary
• Appendix A: Vertical Layout Effect on CSS Properties
• Acknowledgments
• References
  • Normative references
  • Other references

1. Dependencies on other modules

This CSS3 module depends on the following other CSS3 modules:

• Fonts
• Line
• Syntax and grammar
• Values and unit

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

• Multi-column layout
• Ruby

2. Introduction

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

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

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

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

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

- 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 character.glyph. All characters described by the Unicode Standard [UNICODE] can be categorized by a width property. This is covered by the Unicode Standard Annex [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 charactersglyphs 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 each of theproperty value enumeration.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 positioning 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 lowercase 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., RomanLatin scripts), right-to-left (e.g., Hebrew or Arabic), bidirectional (e.g., mixing RomanLatin with Arabic) and vertical (e.g., Asian scripts).

The 'writing-mode' property determines an inline progressioninline-progression and a block (line to line) progression. For example, RomanLatin scripts are typically written left to right and top to bottom. The 'direction' property, already defined in CSS2, is a subset of the 'writing-mode' property as it only determines an inline-progression. The 'direction' property may still be used when no block-progression change is desired.

The glyph orientation determines the orientation of the rendered visual shape of characters relative to the inline progression.inline-progression.

Within a line, the adjustment to the current text position is based on the current glyph orientation relative to the inline progression,inline-progression, the metrics of the glyph just rendered, kerning tables in the fontfont, and the current values of various attributes and properties, such as the spacing properties.

Bi-directionalityBidirectionality introduces another level of complexity in text layout, as in many combinations of 'writing-mode' and glyph orientation valuesvalues, the proper directionality and ordering of text will beare determined by anthe Unicode Standard ([UNICODE] bidirectional algorithm. CSS relies on that algorithm to achieve proper bidirectional text rendering and possible reordering. Furthermore, using the 'unicode-bidi' property, the user agent can influence the bidirectional algorithm by allowing new embedding levels and direction overrides.

Note: The Unicode Standard ([UNICODE], section 3.12) defines such ana bidirectional algorithm consisting of an implicit part based on character properties, as well as explicit controls for embeddings and overrides. It is also possible to overridedetermining the inherentdirectionality offor bidirectional text. The content characters by using of combinationdisplay ordering of the 'writing-mode' and 'unicode-bidi' properties. CSS3 relies on this algorithm to achieve proper textbidirectional rendering. However reordering of characters only occurs for specific values of the glyph orientation properties. See their description for the exact conditions. CSS2 specifiedtext depends upon the 'direction' property which is a subsetdirectional properties of the 'writing-mode' property as it only determines an inline progression. The 'direction' property may still be used when no block progression change is desired.characters in the text.

 The HTML 4.01 specification ([HTML401], section 8.2) defines bi-directionalitybidirectionality behavior for HTML elements. Conforming HTML user agents may therefore ignore the 'direction' and 'unicode-bidi' properties in author and user style sheets. The style sheet rules that would achieve the bidibidirectionality 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 thatNote: HTML 4.01 does not cover the more general case described by the 'writing-mode' property.

3.2. Setting the inlineinline-progression and block progressions:block-progression: the 'writing-mode' and 'direction' properties

The 'writing-mode' property specifies whether the inline progressioninline-progression shall be left-to-right, right-to-left, or top-to-bottom. (Note thatThis property also changes the 'direction' property for the element. For more on bidirectional text, see the section about Embedding and override.

Note: Even when the inline progressioninline-progression is left-to-right or right-to-left, some or all of the content within a given element might advance in the opposite direction because of the Unicode [UNICODE] bidirectional algorithm or because of explicit text advance overrides due to this property or 'direction' and 'unicode-bidi'.

lr-tb | lr

Sets the inline progressioninline-progression to left-to-right, and the block progressionblock-progression to top-to-bottomtop-to-bottom, as is common in most Roman-basedthe Latin-based documents. For most characters, the current text position is advanced from left to right after each glyph is rendered. The 'direction' property is set to 'ltr'.

rl-tb | rl

Sets the inline progressioninline-progression to right-to-left, and the block progressionblock-progression to top-to-bottomtop-to-bottom, as is common in Arabic or Hebrew scripts. The direction'direction' property is set to 'rtl'.

tb-rl | tb

Sets the inline progressioninline-progression to top-to-bottom, and the block progressionblock-progression to right-to-leftright-to-left, as is common in some East Asian scripts. The baseline alignment may be different in this context. Typically, the dominant baseline runs through the center of the upright glyphs. The direction'direction' property is set to 'ltr'.

tb-lr

Sets the inline progressioninline-progression to top-to-bottom, and the block progressionblock-progression to left-to-rightleft-to-right, as is common in the Mongolian script. This type of vertical layout also occurs in Latin basedLatin-based documents, particularly in table column or row labels. The baseline alignment may be different in this context. Typically, the dominant baseline runs through the center of the upright glyphs. The direction'direction' property is set to 'ltr'.'rtl'.

bt-rl

Sets the inline progressioninline-progression to bottom-to-top, and the block progressionblock-progression to right-to-left. This value onlyexists only to cover the case of the direction'direction' property value 'rtl' applied to an element where the current writing-mode property value is 'tb-rl' or 'tb'. The direction'direction' property is set to 'rtl'.

bt-lr

Sets the inline progressioninline-progression to bottom-to-top, and the block progressionblock-progression to left-to-right. This value onlyexists only to cover the case of the direction'direction' property value 'rtl' applied to an element where the current writing-mode property value is 'tb-lr'. The direction'direction' property is set to 'rtl'.'ltr.

The combination of inline progressioninline-progression and block progressionblock-progression set by the writing-mode'writing-mode' property is also referred as a flow orientation. In such contexts, the values: lr-tb, lr, rl-tb and rlvalues 'lr-tb', 'lr', 'rl-tb', 'rl' correspond to horizontal flow orientations, and the others (tb-rl, tb, tb-lr, bt-rl, bt-lr)'tb-rl', 'tb', 'tb-lr', 'bt-rl', 'bt-lr' correspond to vertical flow orientations.

For 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"Collapsing margins" in the CSS3 Box module [forthcoming] for the details of collapsing margins.

This property also specifies the direction of table column layout, the direction of the overflow when determined by the inline progressioninline-progression (such as the 'start' and 'end' value 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'.

For the 'writing-mode' property to have any effect on inline-level elements, one or both of the following conditions must be met:

• the new inline progressioninline-progression is perpendicular to the parent's own inline progression or the glyph orientation of the characters within the element is 'auto' or 90/-90 degree in vertical layoutinline-progression or
• 0/180 degree in horizontal layout andthe 'unicode-bidi' property's value is 'embed' or 'bidi-override'. An inline-level element that has'bidi-override' and one of the following conditions is met:
  • the flow is vertical and the 'glyph orientation' is 'auto', '90deg (or equivalent), or -90eg (or equivalent)
  • the flow is horizontal and the 'glyph orientation' is '0deg (or equivalent), or 180deg (or equivalent).

An inline-level element that has a different writing-mode valueblock-progression than its parent becomes an inline-block'inline-block' element.

 .hinv.date {writing-mode:  lr-tb; display: inline-block;}lr-tb;}
<span  class="hinv">1996</span>class="date">1996</span>

Values for this property have the following meanings:

ltr

Left-to-right direction.

rtl

Right-to-left direction.

This property specifies the inline progressioninline-progression and the direction of embeddings and overrides (see 'unicode-bidi') for the Unicode bidirectional algorithm. The block progressionblock-progression is not affected by this property. The values 'ltr' and 'rtl' have to be interpreted 'relatively'relative to the line direction. In addition, it specifies the direction of table column layout, the direction of the overflow when determined by the inline progressioninline-progression (such as the 'start' and 'end' valuevalues 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'.

For the 'direction''writing-mode' property to have any effect on inline-level elements, the 'unicode-bidi' property's value must be 'embed' or 'bidi-override' and the glyph orientation'bidi-override' and, in addition, one of the characters within the elementfollowing conditions must be 'auto' or 90/-90 degree inmet:

• the flow is vertical layoutand the 'glyph orientation' is 'auto', '90deg (or equivalent), or 0/180 degree in-90eg (or equivalent)
• the flow is horizontal layout. Note.and the 'glyph orientation' is '0deg (or equivalent), or 180deg (or equivalent).

Note: The 'writing-mode' and 'direction' properties, when specified for table column elements, are not inherited by cells in the column since columns don't exist incolumn elements are never the document tree.ancestors of their constituent cell elements. Thus, CSS cannot easily capture the "dir" attribute inheritance rules described in [[HTML4.01], section 11.3.2.

Note.Note: The 'writing-mode' and 'direction' properties interact with each other. As such, 'writing-mode' resets the 'direction' value. Similarly, if modifying 'direction' after 'writing-mode' changes effectivelyintroduces a change of inline-progression, the 'writing-mode' value will be updated to reflect the opposite inline progression.new inline-progression. For example, 'direction:rtl''direction: rtl' applied to an element with 'writing-mode:lr-tb''writing-mode: lr-tb' effectively makes 'writing-mode:rl-tb''writing-mode: rl-tb'. This is one of the main reason why the mixed usage of these two properties is discouraged or at least they should be used with great caution. To illustrate the case, in the following example, the computed value of 'writing-mode' is 'rl-tb':

  e { writing-mode: lr-tb; direction: rtl;}

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 characters relative to the inline progression.inline-progression. The requirement is particularly applicable to vertical layouts of East Asian documents, where sometimes half-width RomanLatin text is to be displayed horizontally and other times vertically.

Two properties control the glyph orientation relative to the inline progression.inline-progression. 'glyph-orientation-vertical' controls glyph orientation when the inline progressioninline-progression is vertical. 'glyph-orientation-horizontal' controls glyph orientation when the inline progressioninline-progression is horizontal. It is necessary to distinguish between vertical and horizontal for the following reasons:

• When the inline progressioninline-progression is vertical the typical glyph orientation depends on the related character. See the description of the 'auto' value. This value is not necessary in horizontal layout.
• The initial value is different for the two properties.

<angle>

The user agent may round the value of the angle to the values of glyph rotation supported by the user agent. This does not affect the computed value. Conforming user agents may onlymust at least support either the value 90deg or all of the following values: 0deg, 90deg, 180deg and 270deg,270deg. User agents may support other values can also be supported..values.

A value of "0deg" indicates that all glyphs are oriented with the bottom of the glyphs toward the inline progression,inline-progression, resulting in glyphs which are stacked vertically on top of each other. A value of "90deg" indicates a rotation of 90 degrees clockwise from the "0deg" orientation. For characters which have this property set to 90 or 270 degree, reordering is first applied according to the Unicode Bidi algorithm and then the resulting glyphs are rotated according to the <angle> value. The rotation specified by this value is applied to the glyph representations of all assigned Unicode character codes.

auto

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

Full-width ideographic and full-width RomanLatin glyphs (excluding some ideographic punctuation)punctuation and bracket symbol) are oriented as if an <angle> of "0deg" had been specified for top to bottom inline progressioninline-progression and "180deg" for bottom to top inline progressioninline-progression (resulting in glyphs which are stacked vertically on top of each other).

Ideographic punctuation and other ideographic characters having alternate horizontal and vertical glyph shapes shall use the vertical shape of the glyph.

Text which is not full-width will be set as if an <angle> of "90deg" had been specified; thus, half-width RomanLatin text will be rotated 90 degree clockwise versus full-width ideographic and full-width RomanLatin text.

Hebrew and Arabic text are also rotated 90 degree clockwise. The visual order of this text is determined by the bidirectional algorithm applied prior to the rotation.

Note.Note: A value of auto will generally produce the expected results in common uses of mixing Japanese with European characters; however, the exact algorithms are based on complex interactions between many factors, including font design, and thus different algorithms might be employed in different processing environments. For precise control, specify explicit <angle> values.

This property specifies the orientation of glyphs relative to the inlineinline-progression and block progressionsblock-progression determined by the 'writing-mode' property. This property is applied only to text written in a vertical writing-mode. Conforming user agents may do the following in increasing levels of supports:

1. support only the 90deg value,
2. support only the 'auto' and 90deg value,
3. support the 'auto', 0deg, 90deg, 180deg and 270deg values,
4. support all values above and any number of additional values.

The value of this propertyglyph orientation affects boththe alignment and height of the glyph area generated foramount that the affected glyphs. If acurrent text position advances as each glyph is oriented so that the normal orientation ofrendered. It also affects how the glyph is parallelaligned relative to the dominant-baseline, thenbaseline. When the inline-progression is vertical alignment-point ofand the rotated'glyph-orientation-vertical' value results in a glyph orientation angle which is aligned witha multiple of 180deg, then the alignment-baseline appropriatecurrent text position is incremented according to that glyph.the baseline to whichvertical metrics of the glyph, and the rotatedglyph is aligned isusing the vertical baseline identifiedalignment-point as determined by 'alignment-adjust' [link to the "alignment-baseline" for the scriptCSS3 line module] and 'alignment-baseline' [link to whichthe glyph belongs.CSS3 line module]. Otherwise, the heighttext position is incremented according to the horizontal metrics of the glyph area is determined from the height font characteristic forand the glyph.glyph is aligned using the horizontal alignment points, baselines and heights (computedalignment-point as glyph advance width) are used ifdetermined by 'alignment-adjust' and 'alignment-baseline'.

Note: The normal orientationconcepts of alignment-point and alignment-baseline are described in the glyph is perpendicular to the dominant-baseline.CSS3 line module.

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 half-width Romannormal-width Latin characters when 'glyph-orientation-vertical' for the Romanspan containing the Latin characters is either auto or "90deg". The diagram on the right show the result of mixing full-width ideographic characters with half-width Romannormal-width Latin characters when Romanthe span containing the Latin characters areis 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.

The bidi algorithm and the 'glyph-orientation-vertical' property have the following interaction:

1. The bidi algorithm is applied separately to each contiguous text range having the same glyph-orientation-vertical value. In other words a change in the property value resets the bidi algorithm.
2. When the glyph-orientation-vertical value is 270 degree, all mirroring symbols after all due bidi processing are mirrored before being rotated 270 degree clockwise. This is done to achieve the desired rendering result, which is to have the mirroring characters pointing 'inward' the text they are enclosing.

<angle>

The user agent may round the value of the angle to the values of glyph rotation supported by the user agent. This does not affect the computed value. Conforming user agents must at least support either the 0 deg value or all of the following values: 0deg, 90deg, 180deg and 270deg. User agents may support other values.

A value of "0deg" indicates that all glyphs are oriented with the righttop edge of the glyphs toward the inline progression,before edge of the line box, resulting in glyphs which are positioned side by side. A value of "90deg" indicates an orientation of 90 degrees clockwise from the "0" orientation. For characters which have this property set to 0 or 180 degree, reordering is first applied according to the Unicode Bidi algorithm and then the resulting glyphs are rotated clockwise according to the <angle> value.

This property specifies the orientation of glyphs relative to the inline progressioninline-progression determined by the 'writing-mode' property. This property is applied only to text written in a horizontal writing-mode.

Conforming user agents may doThe following in increasing levels of supports: support onlyglyph orientation affects the 0deg value, support the 0deg, 90deg, 180deg and 270deg values, support all values above and any number of additional values. The value of this property affects both the alignment and width of the glyph area generated foramount that the affected glyphs. If acurrent text position advances as each glyph is oriented so that the normal orientation ofrendered. It also affects how the glyph is parallelaligned relative to the dominant-baseline, thenbaseline. When the vertical alignment-point ofinline-progression is horizontal and the rotated'glyph-orientation-horizontal' value results in a glyph orientation angle which is aligned witha multiple of 180deg, then the alignment-baseline appropriatecurrent text position is incremented according to that glyph.the baseline to whichhorizontal metrics of the glyph, and the rotatedglyph is aligned isusing the horizontal baseline identifiedalignment-point as determined by 'alignment-adjust' [link to the "alignment-baseline" for the scriptCSS3 line module] and 'alignment-baseline' [link to whichthe glyph belongs.CSS3 line module]. Otherwise, the widthtext position is incremented according to the vertical metrics of the glyph areaand the glyph is determined fromaligned using the vertical width font characteristic for the glyph. The horizontal alignment points, baselinesalignment-point as determined by 'alignment-adjust' and widths are used if'alignment-baseline'.

Note: The normal orientationconcepts of alignment-point and alignment-baseline are described in the glyph is perpendicular to the dominant-baseline.CSS3 line module.

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

This property allows further control of the Unicode bidirectional algorithm 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

If the element is inline-level or a block-level element that contains only continuous stretches of inline elements, this creates an override. 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 bidi control codes had been added as described above, mark-up had been stripped, non-textual entities such as images treated as neutral characters, and the resulting character sequence had been passed to an implementation of the Unicode bidirectional algorithm for plain text that produced the same line-breaks as the styled text.

In this process,Note: For non-textual entities such as images are treated as neutral characters, unlessimages, when their 'unicode-bidi' property has a value other than 'normal', in which case they are treated as strong characters inand the 'direction' specified forhas the element. Note.value 'rtl', the resulting directionality is equivalent to character type R (according to the types defined by the Unicode Bidirectional algorithm).

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 bidi into account both in the language proper (elements and attributes) and in any accompanying style sheets. The style sheets should be designed so that bidi rules are separate from other style rules. The bidi rules should not be overridden by other style sheets so that the document language's or DTD's bidi behavior is preserved.

 <hebrew><div xml:lang="he">
  <par>HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5</par>
  <par>HEBREW6 <emph>HEBREW7</emph> HEBREW8</par>
 </hebrew> <english></div>
<div xml:lang="en">
  <par>english9 english10 english11 HEBREW12 HEBREW13</par>
  <par>english14 english15 english16</par>
  <par>english17  <he-quo>HEBREW18<quo xml:lang=he">HEBREW18 english19  HEBREW20</he-quo></par> </english>HEBREW20</quo></par>
</div>

/* Rules for bidi */
 hebrew, he-quodiv:lang(he)   {direction: rtl}
quo:lang(he)   {direction: rtl; unicode-bidi:  embed}
 englishpar:lang(en)   {direction:  ltr; unicode-bidi: embed}ltr}

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

               5WERBEH 4WERBEH english3 2WERBEH 1WERBEH

                                8WERBEH 7WERBEH 6WERBEH

english9 english10 english11 13WERBEH 12WERBEH

english14 english15 english16

english17 20WERBEH english19 18WERBEH

       2WERBEH 1WERBEH
  -EH 4WERBEH english3
                 5WERB

   -EH 7WERBEH 6WERBEH
                 8WERB

english9 english10 en-
glish11 12WERBEH
13WERBEH

english14 english15
english16

english17 18WERBEH
20WERBEH english19

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

In text layout, many of the behaviors are related to a character classification based on scripts.

For example, line breaking or text justification behaviors depend on the 'dominant'some operations, such as baseline alignment, there is a requirement for a dominant script of the textual content ofwhich is used to determine an element. Furthermore, baselinealignment may be processed based onstrategy for the same dominant script. Thatwhole element. A dominant script can be heuristically determinedis established by findingsetting the first character (after reordering) that has'text-script' property to an unambiguousexplicit script identifier in an element. It can also be explicitly specifiedconformance with the Unicode Technical Report [UTR-24]: "Script names", or by using the heuristic determination computed by the user agent when the 'text-script' property.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.

Values have the following meanings:

auto

Use the first character descendant, after any reordering due to character direction and bi-directionality ,descendant which has an unambiguous script identifier [UTR-24] to determine the dominant script of the element's content. This determines the computedAn unambiguous script value. Each textual component of the element may however behave in typographical related behaviors as dictated by itsidentifier is any script identifier.value other than 'COMMON' or 'INHERITED'. In the absence of any textual components with a clearan unambiguous script identifier (or no textual content at all), the computed value is 'Latin'. none Indicates thedominant script is unknown or is'LATIN'. For operations that do not significant to the proper formatting of this element. <script>require a script definition indominant scrip, but instead use a script determination on a character by character basis within the element, the user agent will determine a script value for each character based on its inherent script property as established by [UTR-24]. In such cases, the values 'COMMON' or 'INHERITED' are valid.

<script>

A script identifier in conformance with [ISO15924][UTR-24]. If the script identifier is either 'COMMON' or 'INHERITED' the dominant script value is 'LATIN', otherwise the dominant script value is the specified value. For operations not using the dominant script value, all textual componentscharacters of the element mustwill behave in typography related behaviorsas dictated by thisif their script property was the set value, not thetheir inherent script value of these textual components. Note 1 .value.

Note: The Unicode technical report [UTR-24]: Script Names'Script Names' specifies an inherent script allocationsvalue for the wholeeach character repertoire covered byof the Unicode Standard character repertoire [UNICODE]. Note 2 .There is also an ISO draft standard [ISO15924] addressing script identification.

Note: Setting an explicit script property value on an element reclassifies all its textual content to the given script. For example setting the script to a script belonging to the CJK group (Chinese, Japanese, Korean) makes the content behave as a CJK content for line-breaking rules. And setting an Arabic text to Latin would prevent the context to be affected by the Kashida justification effect. Typically, this property should be set to an explicit script value only when the textual content is script ambiguous and a specific behavior is sought.

4. Text alignment and justification

4.1. Text alignment: the 'text-align' property

This property describes how inline content of a block is aligned. Values have the following meanings:

start

The text is aligned on the start of the inline progression.inline-progression.

end

The text is aligned on the end of the inline progression. left ,inline-progression.

left, right

In horizontal inline progression,inline-progression, the text is aligned on the left or right respectively. In vertical inline progression,inline-progression, the alignment is UA dependent. Because these two values are not related to the current inline progression,inline-progression, the values 'start' and 'end' are typically preferred.

center

The text is center aligned.

justify

The text is justified. The justification algorithm can be further refined by using the 'text-justify' property. Although conforming CSS2 user agents could interpret the value 'justify' as 'start',  conforming CSS3 user agents may not, unless a profile specifies otherwise.

<string>

Specifies a string on which cells in a table column will align (see the section on horizontal alignment in a column for details and an example). This value applies only to table cells. If set on other elements, it will be treated asthe computed value is 'start'.

A block of text is a stack of line boxes. In the case of 'start', 'end', 'left', 'right' and 'center', this property specifies how the inline boxes within each line box align with respect to the line box's start and end sides; alignment is not with respect to the viewport. In the case of 'justify', the UA may stretch the inline boxes in addition to adjusting their positions. (See also 'letter-spacing' and 'word-spacing'.)

Example(s):

In this example, note that since 'text-align' is inherited, all block-level elements inside the div element with 'class=important' will have their inline content centered.

div.important { text-align: center }

Note.Note: The property initial value has changed between CSS2 and CSS3 from being UA dependent in CSS2 to be related to the current text advance direction in CSS3 (through the usage of the 'start' value).

4.2. Justification: the 'text-justify' property

This property selects the type of justify alignment. It affects the text layout only ifalignment for last lines when 'text-align-last' is set to 'justify' and other lines when 'text-align' is set to 'justify'. That way, UA's that do not support this property will still render the text as fully justified, which most of the time is at least partially correct. Typically the text-justify property does not affect the last line, unless the last line itself is justified.Most of the text-justify values affects writing systems in very specific ways. These writing systems (or group of) are:

• CJK and Hangul and by extension all 'wide' characters,
• Devanagari and all South Asian scripts using baseline connector likesuch as Bengali and Gurmukhi,
• South Eastern Asian scripts that do not use space between words (Thai,(such as Thai, Lao, Khmer, Myanmar),
• Cursive scripts like Arabic,
• Scripts using space between word without connector (Latin-based,(such as Latin, Greek, Cyrillic, Hebrew, etc...) and symbol characters.

The text-justification behavior of textual components is guided by theDepending on script classification of the characters.value (controlled by the 'text-script' property allows to modify the behavior of these components. Depending onvalue) and the text-justify'text-justify' property value, spacing may be altered between words or letters. The possibleletters or both.

The possible values for the text-justify property are:

auto

The UA determines the justification algorithm to follow, based on a balance between performance and adequate presentation quality. Inter-word expansion is typically used for all scripts that use space as word delimiter. However,The concept of a word is script dependent, although the user agent determines the exact algorithm. If the kashida-space'text-kashida-space' property has a non zero percent value it is recommended to use kashida elongation for Arabic text.

inter-word

Selects the simplest and fastest full justification behavior, which spreads the text evenly across the line by increasing the width of the space between words only. The concept of a word is script dependent, the exact algorithm is determined byalthough the user agent.agent determines the exact algorithm. At minimum, justification is expected to occur at each white space boundary. No expansion or compression occurs within the words, i.e. no additional letter spacing is created. No kashida effect takes place.

Note: White space does not include zero-width-space, therefore justification is not expected for these characters. However justification is expected for white space with explicit width set by the 'word-spacing' property.

The diagram below illustrates this mode, by showing how the charactersglyphs are laid out in the last two lines of an element:

Mixed glyph layout in the last two lines in an inter-word justified element

For example a viewer could render an 'inter-word' justified paragraph in the following way:

Inter-word justification applied to mixed text

newspaper

Selects the justification behavior in which both inter-word and inter-letter spacing can be expanded or reduced to spread the text across the whole line. Also, text distribution on any given line may depend on the layout or the contents of the previous or the following several lines. This is the significantly slower and more sophisticated type of the full justify behavior preferred in newspaper and magazines, as it is especially useful for narrow columns. For example, typically, compression is tried first. If unsuccessful, expansion occurs: inter-word spaces are expanded up to a threshold, and finally inter-letter expansion is performed. ThisInter-letter spacing is not applied to all scripts groups exceptDevanagari and other South Asian writing systems using baseline connectors. The threshold value may be related to the ratio of column width (in number of characters).to font size. The exact layout algorithm is determined by the user agent. Further explanation about multi-column layout can be found in the CSS3 Multi-layoutMulti-column layout module.

The diagram below illustrates this mode:

Mixed characterglyph layout in the last two lines of a newspaper justified element

Note.Note: In CSS3 a value of 'letter-spacing: 0' no longer strictly inhibits spacing-out of words for justification. The letter-spacing value is just an entry to the letter-spacing process that occurs prior to the possible justification process. Justification may alter the initial spacing between letters, especially with the 'text-justify: newspaper' value.

inter-ideograph

In this mode, letter-spacing modification only occurs for the CJK group. Others only use inter-word expansion. No kashida effect takes place. This is the preferred justification in the context of the Japanese writing system, but not Latin nor Korean.

The diagram below illustrates this mode:

Mixed glyph layout in the last two lines in an inter-ideograph justified element

Below is an example of how this mode would work:

Inter-ideograph justification applied to mixed text

distribute

Like 'newspaper' it allows letter spacing modification for most script groups (except Hindi),the Devanagari group), but unlike newspaper, it does not prioritize between word spacing and letter spacing, i.e. the space character gets the same letter spacing modification as others. And by consequence there are no variations between narrow and wide columns. This value is best used in East Asian context.

The diagram below illustrates this mode:

Mixed characterglyph layout in the last two lines of a distribute justified element

For example a viewer could render a 'distribute' justified paragraph in the following way:

Distribute justification applied to mixed text

inter-cluster

PlaysThis is the same role as inter-ideograph but for South EasternSoutheast Asian scripts.counterpart to 'inter-ideograph'. That is letter spacing only occurs forbetween script-defined grapheme clusters belonging to thoseoccurring in Southeast Asian scripts.

Note: A grapheme cluster is defined aswhat a group of characters formatted aslanguage user consider to be a single unit.character or a basic unit of the language. The term is described in detail in the Unicode technical report [UTR-29]: Text Boundaries.

kashida

PlaysThis is the same role as inter-ideograph but forArabic throughcounterpart to 'inter-ideograph'. Letter spacing may be increased between Arabic letters, the extra space being filled by kashida. The amount of kashida elongation is controlled by the 'text-kashida-space' property. If 'text-kashida-space' is set to '0%' (which is the initial value), there will be no kashida effect. That is,No letter spacing occurs for other scripts.

The following table describes the expansion/compression strategy for the combination of each script groups and the text-justify property value for each relevant text-justify property value:

*The values shown for the auto column are only a recommendation. The UAs might implement a different strategy.

*The**The Latin entry represents as well other scripts and writing systems used in Europe and America that use the same typographic convention for justification such as Greek, Cyrillic, etc.

***The Devanagari entry represents as well other scripts and writing systems used in India that use baseline connectors likesuch as  Bengali and Gurmukhi.

4.3. Last line alignment: the 'text-align-last' property'property

This property describes how the last line of the inline content of a block is aligned. This also applies to the only line of a block if it contains a single line, the line preceding a <br>br element in a XHTML context, or a hard line break in other languages, and to last lines of anonymous blocks. Typically the last line is aligned likeDepending on the other linesvalue of the block element, this is set byproperty, the 'text-align' property. However, in some situations like whenlast line alignment may also be influenced by the value of  the  'text-align' and 'text-justify' properties. Possible values:

relative

If the 'text-align' property is set to 'justify', the last line may be aligned differently. Values havethe following meanings: autovalue 'justify', the last line will be aligned like the other lines, that is determined byto the valuestart of the 'text-align' property. However,inline-progression. If the 'text-align' property is set to the value 'justify',any other values, the last line alignment will be aligned todetermined by the startvalue of the inline progression. start ,'text-align' property.

start, end and center

Start, end and center text respectively.

justify

The last line will be justified like the other lines, using the justification type set byaccording to the 'text-justify' property. Note however thatproperty value. However, if there is no expansion opportunity in the last line, the line might not appear justified.

size

The line content is scaled to fit on the line. All the fonts on the line must be scaled by the same factor. Typically this value is used for single line element. Finally, this value, unlike the others, may change (i.e. decrease) the number of lines in a block element.

p.distributealllines
 { text-align: justify;
   text-justify: distribute;
   text-align-last: justify }

4.4. Minimum and maximum font size: the 'min-font-size' and 'max-font-size' property

The two following properties are only used in conjunction with the 'text-align-last' property set to 'size'. They control the font-size adjustments allowed to to fit the line content within the line.

If 'text-align-last' is 'size',Possible values:

<'font-size'>

The fontsfont sizes of the last line of an element are not allowed to become smaller than the smaller of the computed 'font-size' value and the <'font-size'> value set to 'min-font-size'.

'auto' means thatauto

The user agent determine the minimum readable font-size for the media. For example, a value is 9pxof '8px' (relative to the viewing device) is recommended for Latin scripts.

If 'text-align-last' is 'size',Possible values:

<font-size>

The fontsfont sizes of the last line of an element are not allowed to become larger than the larger of the computed 'font-size' value and the value <'font-size'> set to 'max-font-size'.

'auto' means thatauto

There is no limit.upper limit to the font sizes of the last line of an element.

4.5. Additional compression: The 'text-justify-trim' property

This sets the individual font blank space compression permissions for the text justification algorithm, when 'text-justify' is anything other than 'inter-word'. This special type of space compression occurs on the font level, i.e. the blank space within the character area itselfglyphs themselves may be reduced without affecting the appearance of the glyph.filled parts of glyphs. This applies to wide-cell glyphs only. Possible values:

none

No wide-cell font space compression is allowed.

Glyph layout with no compression

punctuation

Space can be taken away only from wide-cell punctuation glyphs.

Glyph layout with punctuation compression

punct-and-kana

Space compression is allowed on wide-cell punctuation and wide-cell Kana glyphs.

CharacterGlyph layout with punctuation and Kana compression

4.6. Kashida effect: the 'text-kashida-space' property'

Kashida is a typographic effect used in Arabic writing systems that allows characterglyph elongation at some carefully chosen points in Arabic.points. Each elongation can be accomplished using a number of kashida glyphs, a single graphic or character elongation on each side of the kashida point. (The UAuser agent may use either mechanism based on font or system capability). The text-kashida-space'text-kashida-space' property expresses the ratio of the kashida expansion size to the white space expansion size, 0%size. The value '0%' means no kashida expansion, 100%expansion. The value '100%' means kashida expansion only .only. This property can be usedhas a visible effect with any justification style where kashida expansion is usedallowed (currently text-justify:if the 'text-justify' property is set to: auto, kashida, distribute andor newspaper).

In the diagram below showing two identical paragraphs of Arabic text, the blue line in the second line (not justified) shows the length that is used for kashida and divided among the elongation opportunities in the first line (justified), as indicated by the red underlines:

In that example no expansion occurs between the word themselves, indicating that the text-kashida-space property is set to 100%.

5. Text indentation

: the 'text-indent' property Name: text-indent Value: <length> | <percentage> Initial: 0 Applies to: block-level elements Inherited: yes Percentages: refers5.1. Summary

Since CSS1 it has been possible to widthindent the first line of containinga block element using the 'text-indent' property. However until now there was no easy way to indent the other lines of the block element. Changing margin or padding values was possible, but while indentation is always on the starting edge of the text, margin and padding are always given in absolute terms (independent from the layout direction of the block). Furthermore, unlike text indentation, the margin and padding effects are not inherited. Because of all of this, creating a hanging indent was not easy as it implied a mix of properties controlling text indent and padding or margin with different inheritance rules.

CSS3 solves the problem by making 'text-indent' a shorthand property of two new properties: 'text-first-indent' which controls the text indent of the first line within a block element and 'text-block-indent' which controls the text-indent of the other lines. To maintain compatibility with prior version of CSS and to facilitate authoring,  'text-block-indent' does not take length values but instead strategy hints. This allows 'text-indent' to be use in a compatible way or in a new way allowing hanging indent without resorting to margin or padding.

5.2. First Line indentation: the 'text-first-indent' property

This property specifies the indentation of the first line of text in a block. More precisely, it specifies the indentation of the first box that flows into the block's first line box. The box is indented with respect to the starting edge of the line box. User agents should render this indentation as blank space. When the 'text-align' property is not set to align the text at the starting edge, this property only specifies a minimum indentation. When the 'text-align' property is set to 'center', the content of the first line is centered within the whole line box with the additional constraint created by the indentation.

Values have the following meanings:

<length>

The indentation is a fixed length.

<percentage>

The indentation is a percentage of the containing block width.

The value of 'text-indent''text-first-indent' may be negative, but there may be implementation-specific limits.

Note: Note :Since the 'text-indent''text-first-indent' property inherits, when specified on a block element, it will affect descendent inline-block elements. For this reason, it is often wise to specify 'text-indent:'text-first-indent: 0' (or 'text-indent: 0', see below) on elements that are specified 'display: inline-block'.

Example(s): The following example causes a '3em' text indent. p { text-indent: 3em } 6. Line breaking 6.1. Types of5.3. Block Line breaking In documents written in Latin-based languages, where runs of characters make up words and words areindentation: the 'text-block-indent' property

This property specifies the indentation of all lines of text in a block except the first line to allow the creation of an 'hanging indent' effect. User agents should render this indentation as blank space. When the 'text-align' property is not set to align the text at the starting edge, this property only specifies a minimum indentation. When the 'text-align' property is set to 'center', the content of the lines is centered within the whole line box with the additional constraint created by the indentation.

Values have the following meanings:

auto

All lines are indented the minimum length necessary to keep the first line inside the starting text edge. If the computed value of

'text-first-indent' is negative, the computed value of 'text-block-indent' is the corresponding positive value. If the computed value of 'text-first-indent' is positive, the computed value of 'text-block-indent' is zero.

For example, if 'text-first-indent' were set to '-2em', the computed value of the 'text-block-indent' would be 2em, but if 'text-first-indent' were set to '2em', the computed value would be zero.

none

There is no indentation for the remaining lines of the block.  The computed value is zero.

5.4. All lines indentation: the 'text-indent' shorthand property

This property specifies the indentation of the lines of text in a block. It sets the value of 'text-first-indent' to the input value and 'text-block-indent' to 'inherit' (note that this is not its initial value).

Note: Since the 'text-indent' property inherits, when specified on a block element, it will affect descendent inline-block elements. For this reason, it is often wise to specify 'text-indent: 0' (or 'text-first-indent: 0', see above) on elements that are specified 'display: inline-block'.

     :root {text-block-indent: auto} 
     p     { text-indent: -3em }

The 'float-displace' property [link TBD from CSS3 box] determines the line wrapping policy in the presence of floats. As such it is influenced by text indentation. When that property is set to the 'line' value, a float may appear within a hanging indent created by text indentation. When the same property is set to the 'content' value, and the 'indent-edge-reset' property [link from CSS3 box] which determines the reference indent edge is set to 'content-edge', the actual reference edge is the starting content edge of the least indented line or lines of the block element.

6. Line breaking

6.1. Types of line breaking

In documents written in Latin-based languages, where runs of characters make up words and words are separated by spaces or hyphens, line breaking is relatively simple. In the most general case, (assuming no hyphenation dictionary is available to the UA), a line break can occur only at whitespacewhite-space characters or hyphens, including U+00AD SOFT HYPHEN.

In ideographic typography, however, where what appears as a single glyph can represent an entire word and no spaces nor any other word separating characters are needed, a line breaking opportunity is not as obvious as a space. It can occur after or before many other characters. Certain line breaking restrictions still apply, but they are not as strict as they are in Latin typography.

Thai is another interesting example with its own special line breaking rules. Since Thai words are made up of runs of characters, it resembles Latin in that respect. But the lack of spaces as word delimiters, or in fact any consistent word delimiters, makes it similar to CJK. Thai, like Latin in the absence of a hyphenating dictionary, never breaks inside of words. In fact, a knowledge of the vocabulary is necessary to be able to correctly break a line of Thai text. Finally,To specify an explicit line breaking opportunity, the Unicode character:character U+200B ZERO WIDTH SPACE can be inserted in suchdocuments of Thai and similar scripts to specify an explicit line breaking opportunity..

A number of levels of line-breaking "strictness"strictness can be used in Japanese typography. These levels add or remove line breaking restrictions. The model presented in this specification distinguishes between two most commonly used line breaking levels for Japanese text, using the 'line-break' property.

In ideographic typography, it is also possible, though not always preferred, to allow line breaks to occur inside of quoted Latin and Hangul (Korean) words without following the line breaking rules of those particular scripts. The model proposed in this document gives the author control over that behavior through the 'word-break-cjk' property.

In addition, hyphenation is controlled by 'word-break-inside'.

All these properties are also available throughThe 'word-break' short hand property.shorthand property sets 'word-break-cjk' and 'word-break-inside'.

Finally, there is an additional property 'wrap-option' which may influence line-breaking, especially the property value 'wrap-option: emergency' which provides for emergency word-breaking for long words.

Note: Line breaking is alsocovered by the Unicode Standard Annex [UAX-14], available from the Unicode Web site. It contains a detailed recommendation and corresponding data for each Unicode character. The line breaking data for a character is formally independent from its inherent script value, although both are tightly correlated. Consequently, the 'text-script' property has no influence on line breaking and word breaking processing.  The following properties descriptions use commonly script classification because the classification conveniently describes the specific cases of line breaking and word breaking.

6.2. Line breaking: the 'line-break' property

This property selects the set of line breaking rules to be used for text. The values described below are especially useful to CJK authors, but the property itself is open to other, not yet specified settings for non-CJK authors as well. (This is an area for future expansion.)

normal

Selects the normal line breaking mode for CJK. While the UA is free to define its own line breaking restrictions for the 'normal' mode, it is recommended that breaks between smalla standard katakana or hiragana character and a small katakana or hiragana characters(respectively) character be allowed. That is the preference in modern Japanese typography, and is especially desirable for narrow columns. Japanese katakanakana words tend tomay be long, and it is preferable to allow line breaks to occur among such characters than to have excessive expansion due to justification.

strict

Selects a more restrictive line breaking mode for CJK text. While the UA is free to define its own line breaking restrictions for the 'strict' mode, it is recommended that the restrictions specified by the JIS X-4051 [JIS-X-4051]Unicode Standard Annex [UAX-14] be followed. That implies that in this mode, small katakana and hiragana characters are not allowed to start a line.line if they follow a standard katakana or hiragana character.

Note: In Japanese, a set of line breaking restrictions is referred to as "Kinsoku". JIS X-4051 [JIS-X-4051] is a popular source of reference for this behavior using the strict set of rules. This architecture involves character classification into line breaking behavior classes. Those classes are then analyzed in a two dimensional behavior table where each row-column position represents a pair action to be taken at the occurrence of these classes. For example, given a closing character class and an opening character class, the intersection in that table of these two classes (the first character belonging to the opening class and the second belonging to the closing class) will indicate no line breaking opportunity.The rules described by JIS X-4051 have been superseded by the Unicode Technical Report #14 mentioned earlier. Note that#14.

Note: Both values,values: 'normal' and 'strict' imply that a set of line-breaking restrictions is in use.

In fact, there appears to be no valid line breaking mode in CJK in which line breaks can appear just anywhere among ideographs.6.3. Word breaking: the 'word-break-cjk', 'word-break-inside' properties and the shorthand 'word-break' property

This property controls line-breaking behavior inside of words from a CJK point of view. Possible values:

normal

Keeps non-CJK scripts together (according to their own rules), while Hangul and CJK ideographs (including the Korean Hanja characters) break everywhere oraccording to the rules of the 'line-break' mode. Note however thatHowever, the behavior of non-CJK scripts can be superseded by using the value 'emergency' in the 'wrap-option' property, or the value 'hyphenate' in the 'word-break-inside' property.

break-all

Same as 'normal' for CJK ideographs and Hangul, but non-CJK scripts can break anywhere. This option is used mostly in a context where the text is predominantly using CJK characters with few non-CJK excerpts and it is desired that the text be better distributed on each line. The UAs may however limit the break everywhere behavior for script using clusters likesuch as Thai.

keep-all

Same as 'normal' for all non-CJK scripts. CJK ideographs and Hangul are kept together. This option should only be used in the context of CJK ideographs used in small clusters like in the Korean writing system.

p.anywordbreaks { word-break: break-all }

This property controls the hyphenation behavior inside of words. Possible values:

normal

A word should always stay in a single line. Note however thatHowever, this can be superseded by using the value 'break-all' in the 'word-break-cjk' property, or the value 'emergency' in the 'wrap-option' property. Moreover, explicit hyphenation characters (hyphen, soft hyphen, etc...) still create line breaking opportunities.

hyphenate

Words can be broken at an appropriate hyphenation point. It requires that the user agent have an hyphenation dictionary for the language of the text being broken. Setting this value activates the hyphenation engine in the user agent.

Note: Intra-word breaks may or may not be indicated by a visible hyphen, depending on the language. The hyphenation glyph may appear at the end of the line or at the start of the next line, and its actual shape may depend on the text language.

The 'word-break' property is a shorthand property for setting 'word-break-cjk', and 'word-break-inside', at the same place in the style sheet.

All word-break relatedThe properties 'word-break-cjk' and 'word-break-inside' are first reset to their initial values (all 'normal'). Then, those properties that are given explicit values in the 'word-break' shorthand are set to those values.

7. Text Wrapping, White-space Control and Text Overflow

The following section describes text wrapping, white-space handling and text overflow. Text wrapping and white-space handling are interrelated through the CSS2 'white-space' property combining these two effects together. Text wrapping and text overflow both deal with situation where the text reaches the flow after-edge of its containing box.

CSS3 clearly separates these three effects in different sets of property while keeping the 'white-space' property for compatibility reason.

The following section frequently use the term line feed character to specify the normalized newline indicator. In XML and HTML context, the line feed character is the LINE FEED (U+000A). In other contexts, it may be represented differently, for example by a CARRIAGE RETURN (U+000A). The term 'line feed character' represents the normalized newline character native to a given framework.

7.1. Text wrapping: the 'wrap-option' property

This property controls whether or not text wraps when it reaches the flow edge of its containing block box. Several value descriptions use the term preserved line feed characters (U+000A).characters. A preserved line-feed character (either from the source content or from occurrence of "\A" in generated content) is maintained for presentation purpose and may therefore influence text wrapping. The preserved status of line-feed characters is determined by the 'linefeed-treatment' property. The 'wrap-option' possible values are:

wrap

The text is wrapped at the best line-breaking opportunity (if required) within the available block inline progressioninline-progression dimension (block width in horizontal text flow). The best line-breaking opportunity is determined in priority by the existence of preserved line-feed characters (U+000A),characters, or by the line-breaking algorithm controlled by the 'line-break' and word-break' properties.

hard-wrapno-wrap

The text is only wrapped where explicitly specified by preserved line feed characters (U+000A).characters. In the case when lines are longer than the available block width, the overflow will be treated in accordance with the 'overflow' property specified in the element.

soft-wrap

The text is wrapped exactly atafter the block widthlast character which can fit before the ending-edge of the line and where explicitly specified by preserved line feed characters (U+000A).characters. No line-breaking algorithm is invoked. The intended usage is the rendering of a character terminal emulation.

emergency

The text is wrapped like for the 'wrap' case, except that the line-breaking algorithm will allow as a last resort option a text wrap after the last character which can fit before the ending-edgeending edge of the line,line box, independently of 'line-break', 'word-break-cjk' and word-break''word-break-inside' properties. For example, this deals withaddresses the situation of very long words constrained in a fixed-width container with no scrolling allowed.

7.2. White-space control: the 'linefeed-treatment', 'white-space-treatment', 'all-space-treatment' properties and the 'white-space' shorthand property

White-space processing in the context of CSS is the mechanism by which all white-space characters are interpreted for rendering purpose. The white-space set is determined by the XML [XML1.0] specification as being a combination of one or more space characters (Unicode value U+0020), carriage returns (U+000D), line feeds (U+000A), or tabs (U+0009).

Note: [HTML401] also defines the form feed character (U+000C) as a white space character, but that character is not part of any XHTML versions as they are all based on XML.

The amount of white space processing that can be achieved by a user agent that supports CSS is directly related to the CSS processing model, especially the document parsing and validation. After parsing and possible validation, the document tree may contain text nodes that contain unprocessed white space characters, or the document tree may already have been processed in a way that white space characters have been collapsed and partially removed (white space normalization).

In that respect, the CSS properties related to white space processing can only be effective if the CSS processor has access to the white space characters that were originally encoded in the document. However, end-of-line characters are typically handled (like by XML processors) in such a way that any arbitrary combination of end-of-line characters is replaced by a single line feed character.

Note: The first version of XML [XML1.0] only normalizes two characters sequences of (U+000D U+000A) or any U+000D not followed by U+000A to a single U+000A. The forthcoming version of XML [XML1.1] adds U+0085 (NEL) and U+2028 (LINE SEPARATOR) to the linefeed normalization process. However the set of white-space characters is unchanged. Notably, the character (U+000A).U+2029 (PARAGRAPH SEPARATOR) is not part of that set. If the characters U+2028 and U+2029 appears in text, they are treated as zero-width characters without semantic meaning.

Note: XML Schema, through its 'whiteSpace' facet can constrain exactly the type of white space characters still available to a rendering process like CSS for elements containing string datatype. In addition, some XML languages like [XHTML1.0] may have their own white-space processing rules when parsing and validating documents with white-space characters. Therefore, some of the behaviors described below may be affected by these limitations and may be user agent dependent in these contexts.

In addition, line feed characters can be inserted in generated content by using the '\A' string. The behavior of these inserted line feed characters is identical to original line feed characters part of the source document and is controlled by the same set of properties.

The initialWhite-space processing, similar to [XHTMLMOD]processing

Any text that is as follows: Leading and trailing white spacedirectly contained inside a block element(not inside an inline) should be treated as an anonymous inline element.

For each inline (including anonymous inlines), the following steps are not rendered. Line feedperformed, ignoring bidirectional formatting characters are renderedas oneif they were not there:

1. Each non-linefeed white-space character is treated as per the 'white-space-treatment' property.
2. If 'all-space-treatment' is set to 'preserve', any sequence of spaces (U+0020) unbroken by an element boundary is treated as a sequence of non-breaking spaces. However, a line breaking opportunity exists at the end of the sequence.
3. Each linefeed character is treated as per the 'linefeed-treatment' property.
4. If 'all-space-treatment' is set to 'collapse',
   1. every tab (U+0009) is converted to a space (U+0020)
   2. any space (U+0020) following characters:another space (U+0020)--even a space character,before the inline, if that space also has 'all-space-treatment' set to collapse--is removed.

Then, the entire block is rendered. Inlines are laid out, taking bidirectional reordering into account, and wrapping as specified by the 'wrap-option', 'line-break' and 'word-break' properties.

As each line is laid out,

1. If a zero widthspace character (U+200B), or no character (i.e. not rendered).(U+0020) at the beginning of a line has all-space-treatment' set to 'collapse', it is removed.
2. All tabs (U+0009) are rendered as a horizontal shift that lines up the choicestart edge of the resulting character is conditioned bynext glyph with the script propertynext tab stop. Tab stops occur at points that are multiples of 8 times the characters preceding and following the line feed character. A sequencewidth of whitea space characters without any line feed characters is(U+0020) rendered asin the block's font from the block's starting content edge.
3. If a singlespace character. A sequence(U+0020) at the end of white space characters with one or more line feed character is rendered similarly toa singleline feed character.has 'all-space-treatment' set to 'collapse', it is also removed.

Note: Tab stops line up in the block regardless of font change.

These rendering rules make no assumption about the storage model of these white-space character sequences. It is outside the scope of CSS to determine the character code values accessible through programming interface such as DOM. These rules do not apply to elements that have an explicit white-space rendering behavior (like the pre element in XHTML).

Note: In determining how to convert a LINE FEED character a user agent should consider the following cases, whereby the script ofWhen white-space characters on either side ofare collapsed for rendering purpose, the LINE FEED determinestext decoration style applied to the choice ofcollapsed set is the replacement. Characters of COMMON script (such as punctuation) are treated asone that would be applied to the same asfirst white-space character of the script onoriginal sequence.

The other side: If'white-space' property is a shorthand property for 'linefeed-treatment', 'white-space-treatment', 'all-space-treatment' and 'wrap-option'.

This property specifies the treatment of linefeed characters preceding andfor rendering purpose. Values have the following meanings:

auto

The user agent either transforms each line feed character belongto a script in which thespace character is used as a word separator, the(U+0020), transforms each line feed character should be converted intoto a zero width space character. Examples of such scripts are Latin, Greek, and Cyrillic. Ifcharacter (U+200B), or removes the characters preceding andline feed characters, following the line feed conversion algorthim. The choice of the resulting character belong to an ideographic-based script or writing system in which thereis no word separator,conditioned by the LINE FEED should be converted into no character. Examplesscript value of such scripts or writing systems are Chinese, Japanese. Ifthe characters preceding and following the line feed character belong to a non ideographic-based script inwhich there is no word separator, the LINE FEED should be converted into a ZERO WIDTH SPACE character (&#x200B;) or no character. Examples of such scriptsare Thai, Khmer. If nonepart of the conditionssame inline text flow in (1) through (3) are true,the LINE FEEDsame block element. The script value of each character should be convertedis determined by the 'text-script' property.

ignore

Linefeed characters are ignored. They are removed and are not rendered.

preserve

Linefeed characters indicate an end of line of boundary.

treat-as-space

Linefeed characters are transformed for rendering purpose into a space character.character (U+0020). The Unicode [UNICODE] technical report TR#24 (Script Names) [UTR-24] provides an assignmentresult of script names to all characters. When white-spacethe transformation can be treated by subsequent CSS processing (including white space collapsing).

treat-as-zero-width-space

Linefeed characters are collapsedtransformed for rendering purpose,purpose into a zero width space character (U+200B). The style applied toresult of the collapsed set istransformation can be treated by subsequent CSS processing (including white space collapsing).

ignore-if-after-linefeed

Specifies that any linefeed characters that immediately follows a linefeed character, shall be discarded. This collapses multiple consecutive linefeed characters into a single linefeed.

Note: The oneUnicode Standard [UNICODE] specifies that would be applied to first white-space character ofthe set.zero width space is considered a valid line-break point and that if two characters with a zero width space in between are placed on the following properties: 'linefeed-treatment' , 'white-space-treatment'same line they are placed with no space between them; and 'all-space-treatment' allow precise control ofthat behavior.if they are placed on two lines no additional glyph area, such as for a hyphen, is created at the line-break.

Line feed conversion algorithm

This algorithm is used when 'linefeed-treatment' determines the rendering of theis set to 'auto'. In determining how to convert a line feed characters.character, a user agent should consider the 'white-space-treatment' determinesfollowing cases, whereby the renderingscripts value of white space character (except line feed).characters preceding and following the 'all-space-treatment' property determinesline feed determine the treatment of consecutive white-space characters after considerationchoice of the two prior properties.replacement. The 'white-space' propertyscript value of each character is a shorthand property for these three properties as well asdetermined by the 'wrap-option''text-script' property. Name: linefeed-treatment Value: auto | ignore | preserve | treat-as-space | treat-as-zero-width-space | ignore-if-after-linefeed 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) This property specifies(Note that if 'text-script' is set to 'auto', the treatment of linefeeds (U+000A characters). Values havedetermination is done character by character within the following meanings: auto Linefeedelement, otherwise all characters are transformed for rendering purpose into one ofshare the following characters: a space character, a zero width space character (U+200B), or no character (i.e. not rendered).same script value within the choiceelement.) Characters of COMMON script (such as punctuation) are treated as the resulting character is conditioned bysame as the script property ofon the other side:

1. If the characters preceding and following the line feed character have a script value in which the same line flow elements part of the same block element. The result of the transformation can be treated by subsequent CSS processing (including white space collapsing). ignore Linefeed characters are ignored. i.e. they are transformed for rendering purpose into no character. preserve Linefeed characters indicate an end of line of boundary. treat-as-space Linefeed characters are transformed for rendering purpose into aspace character (U+0020). The result of(U+0020) is used as a word separator, the transformation canline feed character should be treated by subsequent CSS processing (including white space collapsing). treat-as-zero-width-space Linefeed characters are transformed for rendering purposeconverted into a zero widthspace character (U+200B). The resultcharacter. Examples of such scripts are Latin, Greek, and Cyrillic.

2. If the transformation can be treated by subsequent CSS processing (including white space collapsing). ignore-if-after-linefeed Specifies that any linefeedcharacters that immediately followspreceding and following the line feed character have either a linefeed character, shall be discarded. This allows multiple consecutive linefeed characters to be collapsed intoideographic-based script value or a single linefeed. Note: The Unicode Standard [UNICODE] recommends that the zero width spacescript value which make them part of an ideographic-based writing system in which there is considered a valid line-break point and thatno word separator, the line feed should be converted into no character. Examples of such scripts or writing systems are Chinese, Japanese.

3. If twothe characters withpreceding and following the line feed character have a non ideographic-based script vale in which there is no word separator, the line feed should be converted into a zero width space character (U+200B) or no character. Examples of such scripts are Thai, Khmer.

4. If none of the conditions in between(1) through (3) are placed ontrue, the sameline they are placed with no space between them; and that if they are placed on two lines no additional glyph area, such as forfeed character should be converted into a hyphen, is created at the line-break.space character (U+0020).

This property specifies the treatment for rendering purpose of the space character (U+0020) and other white-space characters except(except for linefeeds (U+000A),linefeed characters, since their treatment is determinedetermined by the linefeed-treatment property.'linefeed-treatment' property). White-space characters, when rendered as an advance width, use the width of the empty glyph normally used for the space character (U+0020). Values have the following meanings:

ignore

White spaceWhite-space characters, except for linefeeds,linefeed characters, are ignored. i.e.They are transformed for rendering purpose into no character.removed and are not rendered.

preserve

All white spacewhite-space characters other than line feed are rendered as intended (advancethey are (with advance width).

The treatment of linefeeds is not determined by this property.ignore-if-before-linefeed

Specifies that any white spacewhite-space characters, except for linefeeds, that immediately precedes a linefeed character, shall be discarded. This action shall take place regardless of the setting of the linefeed-treatment property.

ignore-if-after-linefeed

Specifies that any white space characters, except for linefeeds, that immediately follows a linefeed character, shall be discarded. This action shall take place regardless of the setting of the linefeed-treatment property.

ignore-if-surrounding-linefeed

Specifies that any white space characters, except for linefeeds, that immediately precedes or follows a linefeed character, shall be discarded. This action shall take place regardless of the setting of the linefeed-treatment property.

The "all-space-treatment"'all-space-treatment' property specifies the treatment of all consecutive white-space characters (with no exception for linefeed characters, unlike the "white-space-treatment"'white-space-treatment' property). Values have the following meanings:

preserve

All white-space characters are rendered as intended.they are. The rendering of tab charactercharacters (U+0009) is rendered asdescribed in the smallest non-zero number of spaces necessary to line characters up along tab stops that are every 8 characters.white-space processing section.

collapse

Specifies that a character is not rendered if:

• it is a white-space character (according to XML), and
• it is not a preserved linefeed (due to 'linefeed-treatment: preserve' ),preserve'), and
• the immediately preceding (non-ignored) character is a white-space character or the immediately following (non-ignored) character is a preserved linefeed.

This property declares how 'white-space' inside the element is handled. Setting a value on the 'white-space' property setsets the respective values on 'wrap-option', 'linefeed-treatment', 'white-space-treatment' and 'all-space-treatment'. Although, strictly speaking, the property has no initial value, it is equivalent to 'normal'. The definition of the property values are established by referring tothe individual white-space properties set as follows:following table, which shows the settings of the constituent properties.