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 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. All comments in response to the previous call have been
processed: see the disposition of comments. It
is expected that a Candidate Recommendation will follow shortly. The
deadline for comments on this draft is 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
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:
2. Introduction
In both CSS1 and CSS2, text formatting has been limited to simple effects
like for example: 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-cell glyph (e.g. Han) which is the n-th glyph in the text run,
- - narrow-cell glyph (e.g. 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 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 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 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., Latin scripts), right-to-left (e.g., Hebrew or Arabic),
bidirectional (e.g., mixing Latin with Arabic) and vertical (e.g., Asian
scripts).
The 'writing-mode' property determines an
inline-progression and a block (line to line) progression.
For example, Latin 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.
Within a line, the adjustment to the current text position is based on the
current glyph orientation relative to the
inline-progression, 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.
Bidirectionality introduces another level of complexity in text layout,
as in many combinations of 'writing-mode' and glyph orientation values, the proper
directionality and ordering of text are determined the 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 a bidirectional algorithm determining the 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 agents
may 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
does not cover the more general case described by the
'writing-mode'
property.
3.2. Setting
the inline-progression and block-progression: the 'writing-mode' and 'direction' properties
The 'writing-mode' property specifies whether the
inline-progression shall be left-to-right, right-to-left, or
top-to-bottom. This
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-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'.
| Name:
| writing-mode
|
| Value:
| lr-tb | rl-tb | tb-rl | tb-lr | bt-rl | bt-lr | lr | rl | tb
|
| Initial:
| lr-tb
|
| Applies to:
| all elements and generated content
|
| Inherited:
| yes
|
| Percentages:
| N/A
|
| Media:
| visual
|
| Computed value:
| specified value (except for initial and inherit)
|
- lr-tb | lr
- Sets the inline-progression to left-to-right, and the block-progression to top-to-bottom, as is common in
the
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-progression to right-to-left, and the block-progression to top-to-bottom, as is common in Arabic or Hebrew
scripts. The 'direction' property is set to 'rtl'.
- tb-rl | tb
- Sets the inline-progression to top-to-bottom, and the block-progression to right-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'
property is set to 'ltr'.
- tb-lr
- Sets the inline-progression to top-to-bottom, and the block-progression to left-to-right, as is common in the Mongolian script. This type of vertical layout also occurs in Latin-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' property is set to
'rtl'.
- bt-rl
- Sets the inline-progression to bottom-to-top, and the block-progression to right-to-left. This value
exists only to cover the
case of the 'direction' property value 'rtl' applied to an element where the
current writing-mode property value is 'tb-rl' or 'tb'. The 'direction'
property is set to 'rtl'.
- bt-lr
- Sets the inline-progression to bottom-to-top, and the block-progression to left-to-right. This value
exists only to cover the
case of the 'direction' property value 'rtl' applied to an element where the
current writing-mode property value is 'tb-lr'. The 'direction' property is set
to 'ltr.
The combination of inline-progression and block-progression set by the 'writing-mode'
property is also referred as a flow orientation. In such contexts, the values 'lr-tb',
'lr', 'rl-tb', 'rl' correspond to horizontal flow orientations, and the others '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" 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-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-progression is perpendicular to the parent's
inline-progression
or
- the 'unicode-bidi' property's value is 'embed' or
'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 block-progression than its
parent becomes an 'inline-block' element.
In the following example, two blocks elements (1 and 3) separated by an image
(2) are presented in various text layout. The image shown in the vertical flows
is not turned, but instead illustrates what would be the desired geometry of the image
in such flows.
Here is a diagram of a horizontal flow ("writing-mode: lr-tb"):
Here is a diagram for a vertical flow used in East Asia
("writing-mode: tb-rl"):
And finally, here is a diagram for another flow used for Uighur and
Mongolian ("writing-mode: tb-lr"):
In East Asian documents, it is often preferred to display certain
Latin-based strings, such as numerals in a year, always in a horizontal
layout flow regardless of the flow mode of the line of text these strings
appear in, as in:
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 within a span element with an
horizontal flow orientation, as in:
.date {writing-mode: lr-tb;}
<span class="date">1996</span>
This is an application of changing the flow of an inline element as
described earlier. Line breaking is normally disabled for such runs of text.
This can be accomplished using the 'white-space:
nowrap' property setting.
| 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)
|
Values for this property have the following meanings:
- 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. The block-progression is not affected by this property. The values 'ltr' and 'rtl' have to be interpreted
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-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'.
For the 'writing-mode' property to have any effect on
inline-level elements, the 'unicode-bidi' property's value must be 'embed' or
'bidi-override' and, in addition, one of the following conditions must be 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).
Note: The 'writing-mode' and 'direction' properties, when specified for table
column elements, are 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.
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' introduces a change of
inline-progression, the 'writing-mode' value will be
updated to reflect the new inline-progression. For example, 'direction: rtl' applied to an element with 'writing-mode: lr-tb' effectively makes '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;}
In some cases, it is required to alter the orientation of a sequence of
characters relative to the inline-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
inline-progression. 'glyph-orientation-vertical'
controls glyph orientation when the inline-progression is
vertical. 'glyph-orientation-horizontal'
controls glyph orientation when the inline-progression is
horizontal. It is necessary to distinguish between vertical and horizontal
for the following reasons:
- When the inline-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.
| Name:
| glyph-orientation-vertical
|
| Value:
| <angle> | auto
|
| 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)
|
- <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 value 90deg 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 bottom of the glyphs toward the 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-progression is
determined automatically based on the Unicode character code of the
rendered character.
Full-width ideographic and full-width Latin glyphs (excluding some ideographic
punctuation and bracket symbol) are oriented as if an <angle> of "0deg" had been specified
for top to bottom inline-progression and "180deg" for bottom to top
inline-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 Latin text will be rotated 90 degree
clockwise versus full-width ideographic and full-width Latin 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: 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 inline-progression and
block-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:
- support only the 90deg value,
- support only the 'auto' and 90deg value,
- support the 'auto', 0deg, 90deg, 180deg and 270deg values,
- support all values above and any number of additional values.
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 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 determined
by 'alignment-adjust' [link to the CSS3 line module] and 'alignment-baseline'
[link to the CSS3 line module]. Otherwise, the text position is incremented according to the
horizontal metrics of the glyph and the glyph is aligned using the horizontal alignment-point
as determined by 'alignment-adjust' and 'alignment-baseline'.
Note:
The concepts of alignment-point and alignment-baseline are described in the 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 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.
The bidi algorithm and the 'glyph-orientation-vertical'
property have the following interaction:
- 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.
- 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.
| Name:
| glyph-orientation-horizontal
|
| Value:
| <angle>
|
| Initial:
| 0deg
|
| Applies to:
| all elements and generated content
|
| Inherited:
| yes
|
| Percentages:
| N/A
|
| Media:
| visual
|
| Computed value:
| <angle>
|
- <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
top edge of the glyphs toward the 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-progression determined by the 'writing-mode' property. This property is
applied only to text written in a horizontal writing-mode.
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
determined by 'alignment-adjust' [link to the CSS3 line module] and 'alignment-baseline'
[link to the CSS3 line module]. Otherwise, the text position is incremented according to the
vertical metrics of the glyph and the glyph is aligned using the vertical alignment-point
as determined by 'alignment-adjust' and 'alignment-baseline'.
Note:
The concepts of alignment-point and alignment-baseline are described in the CSS3
line module.
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 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.
Note: For non-textual
entities such as images, when their 'unicode-bidi'
property has a value other than 'normal', and the 'direction'
has the 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.
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:
<div xml:lang="he">
<par>HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5</par>
<par>HEBREW6 <emph>HEBREW7</emph> HEBREW8</par>
</div>
<div xml:lang="en">
<par>english9 english10 english11 HEBREW12 HEBREW13</par>
<par>english14 english15 english16</par>
<par>english17 <quo xml:lang=he">HEBREW18 english19 HEBREW20</quo></par>
</div>
Since this is XML, the style sheet is responsible for setting the writing
direction. This is the style sheet:
/* Rules for bidi */
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
In text layout, many of the behaviors are related to a character
classification based on scripts.
For some operations, such as baseline
alignment, there is a requirement for a dominant script which is used
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 the Unicode Technical Report [UTR-24]: "Script names", 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 | <script>
|
| 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)
|
Values have the following meanings:
- auto
- Use the first character descendant which has an unambiguous script identifier [UTR-24] to
determine the dominant script of the element's content. An unambiguous script
identifier is any script value other than 'COMMON' or 'INHERITED'. In the
absence of any textual components with an unambiguous script identifier (or no
textual content at all), the dominant script is 'LATIN'. For operations that do
not require a dominant 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 [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 characters of the element will behave as if their script property was
the set value, not their inherent value.
Note: The Unicode technical report [UTR-24]: 'Script Names' specifies an inherent script
value for each character of the Unicode Standard character repertoire [UNICODE]. 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
| Name:
| text-align
|
| Value:
| start | end | left | right | center | justify | <string>
|
| Initial:
| start
|
| Applies to:
| block-level and inline-block elements
|
| Inherited:
| yes
|
| Percentages:
| N/A
|
| Media:
| visual
|
| Computed value:
| specified value (except for initial and inherit)
|
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.
- end
- The text is aligned on the end of the inline-progression.
- left, right
- In horizontal inline-progression, the text is aligned on the left or
right respectively. In vertical inline-progression, the alignment is UA
dependent. Because these two values are not related to the current
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, the 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: 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
| Name:
| text-justify
|
| Value:
| auto | inter-word | inter-ideograph | distribute | newspaper |
inter-cluster | kashida
|
| Initial:
| auto
|
| Applies to:
| block-level and inline-block elements
|
| Inherited:
| yes
|
| Percentages:
| N/A
|
| Media:
| visual
|
| Computed value:
| specified value (except for initial and inherit)
|
This property selects the type of justify alignment for last lines when 'text-align-last' is set to 'justify' and other lines when 'text-align' is set to 'justify'. 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 such as
Bengali and Gurmukhi,
- South Eastern Asian scripts that do not use space between words (such as Thai,
Lao, Khmer, Myanmar),
- Cursive scripts like Arabic,
- Scripts using space between word without connector (such as Latin, Greek,
Cyrillic, Hebrew,
etc...) and symbol characters.
Depending on script classification value (controlled by the 'text-script' property value) and the 'text-justify'
property value, spacing may be altered between words
or letters 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.
The concept of a word is script dependent, although the user agent determines
the exact algorithm. If the
'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, although the user 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 glyphs are
laid out in the last two lines of an element:
For example a viewer could render an 'inter-word' justified paragraph in
the following way:
- 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. Inter-letter spacing is not applied to Devanagari and other South Asian writing systems
using baseline connectors. The threshold value may be related to the ratio of
column width 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-column layout module.
The diagram below illustrates this mode:
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:
Below is an example of how this mode would work:
- distribute
- Like 'newspaper' it allows letter spacing modification for most script
groups (except 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:
For example a viewer could render a 'distribute' justified paragraph in
the following way:
- inter-cluster
- This is the Southeast Asian
counterpart to 'inter-ideograph'. That is letter spacing only occurs between
script-defined grapheme clusters occurring in Southeast Asian scripts.
Note: A grapheme cluster is what a language user consider to be a character
or a basic unit of the language. The term is described in detail in the Unicode
technical report [UTR-29]: Text Boundaries.
- kashida
- This is the Arabic counterpart 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. 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 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 such as Bengali and Gurmukhi.
4.3. Last line
alignment: the 'text-align-last' property
| Name:
| text-align-last
|
| Value:
| relative | start | end | center | justify | size
|
| Initial:
| relative
|
| Applies to:
| block-level and inline-block elements
|
| Inherited:
| yes
|
| Percentages:
| N/A
|
| Media:
| visual
|
| Computed value:
| specified value (except for initial and inherit)
|
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 element in a XHTML
context, or a hard line break in other languages, and to last lines of
anonymous blocks. Depending on the value of the property, the last 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 the value 'justify', the last line will be aligned to the start of the
inline-progression. If the 'text-align' property is set to any other values, the last line
alignment will be determined by
the value of the 'text-align' property.
- start, end and center
- Start, end and center text respectively.
- justify
- The last line will be justified according to the 'text-justify' property 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.
The following XHTML example shows the usage of the alignment properties in
a case where all lines are justified in a distributed justification. This is
commonly found in East Asian typography:
p.distributealllines
{ text-align: justify;
text-justify: distribute;
text-align-last: justify }
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.
| Name:
| min-font-size
|
| Value:
| <'font-size'> | auto
|
| Initial:
| auto
|
| Applies to:
| all elements and generated content
|
| Inherited:
| yes
|
| Percentages:
| element's computed 'font-size'
|
| Media:
| visual
|
| Computed value:
| <font-size>
|
Possible values:
- <'font-size'>
- The font 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
- The user agent determine the minimum readable font-size for the media. For
example, a value of '8px' (relative to the viewing device) is recommended for
Latin scripts.
| Name:
| max-font-size
|
| Value:
| <'font-size'> | auto
|
| Initial:
| auto
|
| Applies to:
| all elements and generated content
|
| Inherited:
| yes
|
| Percentages:
| element's computed 'font-size'
|
| Media:
| visual
|
| Computed value:
| <font-size>
|
Possible values:
- <font-size>
- The font 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
- There is no upper limit to the font sizes of the last line of an element.
4.5. Additional
compression: The 'text-justify-trim' property
| Name:
| text-justify-trim
|
| Value:
| none | punctuation | punctuation-and-kana
|
| Initial:
| punctuation
|
| Applies to:
| block-level and inline-block elements
|
| Inherited:
| yes
|
| Percentages:
| N/A
|
| Media:
| visual
|
| Computed value:
| specified value (except for initial and inherit)
|
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 glyphs themselves may be reduced
without affecting the appearance of the filled parts of glyphs. This applies to wide-cell
glyphs only. Possible values:
- none
- No wide-cell font space compression is allowed.
- punctuation
- Space can be taken away only from wide-cell punctuation glyphs.
- punct-and-kana
- Space compression is allowed on wide-cell punctuation and wide-cell Kana glyphs.
| Name:
| text-kashida-space
|
| Value:
| <percentage>
|
| Initial:
| 0%
|
| Applies to:
| block-level and inline-block elements
|
| Inherited:
| yes
|
| Percentages:
| as described
|
| Media:
| visual
|
| Computed value:
| <percentage>
|
Kashida is a typographic effect used in Arabic writing systems that allows
glyph elongation at some carefully chosen 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 user agent may use either mechanism
based on font or system capability). The
'text-kashida-space' property expresses the
ratio of the kashida expansion size to the white space expansion size. The value
'0%'
means no kashida expansion. The value '100%' means kashida expansion only. This property
has a visible effect with any justification style where kashida expansion is
allowed
(currently if the 'text-justify'
property is set to: auto, kashida, distribute or 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
5.1. Summary
Since CSS1 it has been possible to indent the first line of
a 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
| Name:
| text-first-indent
|
| Value:
| <length> | <percentage>
|
| Initial:
| 0
|
| Applies to:
| block-level and inline-block elements
|
| Inherited:
| yes
|
| Percentages:
| refers to width of containing block
|
| Media:
| visual
|
| Computed value:
| <length> |
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-first-indent' may be negative, but there may
be implementation-specific limits.
Note: Since the '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-first-indent: 0' (or
'text-indent: 0', see below) on elements that
are specified 'display: inline-block'.
5.3. Block Line indentation: the 'text-block-indent'
property
| Name:
| text-block-indent
|
| Value:
| none | auto |
| Initial:
| none |
| Applies to:
| block-level and inline-block elements
|
| Inherited:
| yes
|
| Percentages:
| N/A
|
| Media:
| visual
|
| Computed value:
| see prose |
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
| Name:
| text-indent
|
| Value:
| <length> | <percentage>
|
| Initial:
| not defined for shorthand properties |
| Applies to:
| block-level and inline-block elements
|
| Inherited:
| yes
|
| Percentages:
| refers to width of containing block
|
| Media:
| visual
|
| Computed value:
| <length>
|
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'.
Example(s):
The following example causes the first line a XHTML p element flush with the
content edge and the following lines indent by '3em'.
: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 white-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. To specify an explicit line breaking opportunity, the character U+200B ZERO WIDTH SPACE can be
inserted in documents of Thai and similar scripts .
A number of levels of line-breaking 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'.
The 'word-break' 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 covered 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
| Name:
| line-break
|
| Value:
| normal | strict
|
| Initial:
| normal
|
| 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 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 a standard katakana or hiragana character and a small katakana or hiragana
(respectively) character be allowed. That is the preference
in modern Japanese typography, and is especially desirable for narrow
columns. Japanese kana words may 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 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 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.
The rules described by JIS X-4051 have been superseded by the Unicode Technical
Report #14.
Note: Both values: 'normal' and 'strict' imply that a set of
line-breaking restrictions is in use.
| Name:
| word-break-cjk
|
| Value:
| normal | break-all | keep-all
|
| Initial:
| normal
|
| 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 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
according to the rules of the 'line-break' mode. However, 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 such 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.
The following example shows a paragraph style where all non-CJK scripts
can break anywhere.
p.anywordbreaks { word-break: break-all }
| Name:
| word-break-inside
|
| Value:
| normal | hyphenate
|
| Initial:
| normal
|
| 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 controls the hyphenation behavior inside of words. Possible
values:
- normal
- A word should always stay in a single line. However, 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.
| Name:
| word-break
|
| Value:
| <'word-break-cjk'> || <'word-break-inside'>
|
| Initial:
| see individual properties
|
| Applies to:
| all elements and generated content
|
| Inherited:
| yes
|
| Percentages:
| N/A
|
| Media:
| visual
|
| Computed value:
| see individual properties
|
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.
The 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
| Name:
| wrap-option
|
| Value:
| wrap | no-wrap | soft-wrap | emergency
|
| Initial:
| wrap
|
| 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 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. 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-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, or by the line-breaking algorithm controlled by the 'line-break' and
word-break' properties.
- no-wrap
- The text is only wrapped where explicitly specified by preserved line
feed
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 after the last character which can fit before the
ending-edge of the line and where explicitly specified by preserved line feed
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 edge of the line box, independently
of 'line-break',
'word-break-cjk' and 'word-break-inside' properties. For
example, this addresses the situation of very long words constrained in a
fixed-width container with no scrolling allowed.
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+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.
White-space processing
Any text that is directly contained inside a block (not inside an inline)
should be treated as an anonymous inline element.
For each inline (including anonymous inlines), the following steps are
performed, ignoring bidirectional formatting characters as if they were not there:
- Each non-linefeed white-space character is treated as per the
'white-space-treatment' property.
- 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.
- Each linefeed character is treated as per the 'linefeed-treatment' property.
- If 'all-space-treatment' is set to 'collapse',
- every tab (U+0009) is converted to a space (U+0020)
- any space (U+0020) following another space (U+0020)--even a space 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,
- If a space (U+0020) at the beginning of a line has all-space-treatment' set to 'collapse', it is removed.
- All tabs (U+0009) are rendered as a horizontal shift that lines up the
start edge of the next glyph with the next tab stop. Tab
stops occur at points that are multiples of 8 times the width of a space (U+0020)
rendered in the block's font from the block's starting content edge.
- If a space (U+0020) at the end of a line 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).
When white-space characters are collapsed for rendering purpose, the
text decoration style applied to the collapsed set is the one that would be applied to the first
white-space character of the original sequence.
The 'white-space' property is a shorthand property
for 'linefeed-treatment',
'white-space-treatment', 'all-space-treatment' and 'wrap-option'.
| 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 the treatment of linefeed characters for
rendering purpose.
Values have the following meanings:
- auto
- The user agent either transforms each line feed character to a space
character (U+0020), transforms each line feed character to a zero width space character
(U+200B), or removes the line feed characters, following the line feed
conversion algorthim. The choice of the resulting
character is conditioned by the script value of the characters preceding
and following the line feed character which are part of the same inline text flow
in
the same block element. The script value of each character is 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 (U+0020). The result of the transformation can be treated by
subsequent CSS processing (including white space collapsing).
- treat-as-zero-width-space
- Linefeed characters are transformed for rendering purpose into a zero
width space character (U+200B). The result of the transformation 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 Unicode Standard
[UNICODE] specifies that the 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 same line they are
placed with no space between them; and that 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' is set to 'auto'. In determining how to convert a line feed character, a
user agent should consider the following cases, whereby the scripts value of characters
preceding and following the line feed determine the choice of the replacement.
The script value of each character is determined by the 'text-script' property. (Note that if
'text-script' is set to 'auto', the determination is done character by character
within the element, otherwise all characters share the same script value within
the element.) Characters of COMMON script (such as punctuation) are treated as the same as the
script on the other side:
-
If the characters preceding and following the line feed
character have a script value in which the space character (U+0020) is used as a word
separator, the line feed character should be converted into a space character.
Examples of such scripts are Latin, Greek, and Cyrillic.
-
If the characters preceding and following the line feed
character have either a ideographic-based script value or a script value which
make them part of an ideographic-based writing system in which
there is no word separator, the line feed should be converted into no
character. Examples of such scripts or writing systems are Chinese, Japanese.
-
If the characters preceding 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.
-
If none of the conditions in (1) through (3) are true, the
line feed character should be converted into a space character (U+0020).
| Name:
| white-space-treatment
|
| Value:
| ignore | preserve | ignore-if-before-linefeed | ignore-if-after-linefeed
|
ignore-if-surrounding-linefeed
|
| Initial:
| ignore-if-surrounding-linefeed
|
| 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 the treatment for
rendering purpose of the space character (U+0020) and other white-space characters
(except for linefeed
characters, since their treatment is
determined by the '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-space characters, except for linefeed characters, are ignored. They are
removed and are not rendered.
- preserve
- All white-space characters other than line feed are rendered as they are
(with advance width).
- ignore-if-before-linefeed
- Specifies that any white-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.
| Name:
| all-space-treatment
|
| Value:
| preserve | collapse
|
| Initial:
| collapse
|
| Applies to:
| all elements and generated content
|
| Inherited:
| yes
|
| Percentages:
| N/A
|
| Media:
| visual
|
| Computed value:
| specified value (except for initial and inherit)
|
The 'all-space-treatment' property specifies the treatment of
all consecutive white-space characters (with no exception for linefeed characters,
unlike the 'white-space-treatment' property). Values have the
following meanings:
- preserve
- All white-space characters are rendered as they are. The rendering of tab characters
(U+0009) is described in the 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'), and
- the immediately preceding (non-ignored) character is a white-space
character
or the immediately following (non-ignored) char
