Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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.
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.
This CSS3 module depends on the following other CSS3 modules:
It has non-normative (informative) references to the following other CSS3 modules:
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:
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.
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.
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) |
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:
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:
Horizontal in vertical ("Tate-chu-yoko")
In Japanese, this effect is known as "Tate chu
yoko". In order to achieve it in an XHTML context, the Latin
string should be enclosed 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:
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:
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:
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) |
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:
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:
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> |
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.
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:
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.
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:
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.
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:
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).
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:
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:
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:
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
The diagram below illustrates this mode:
Mixed glyph layout in the last two lines of a newspaper justified element
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.
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
The diagram below illustrates this mode:
Mixed glyph 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
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.
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:
text-justify property value | |||||||
---|---|---|---|---|---|---|---|
Script groups | auto* | inter-word | newspaper | inter-ideograph | distribute | inter-cluster | kashida |
Latin** | word-spacing only* | word-spacing only | prioritization between word-spacing and letter-spacing | word-spacing only | word-spacing and letter-spacing | word-spacing only | word-spacing only |
CJK | no extra spacing* | no extra spacing | letter-spacing | letter-spacing | letter-spacing | no extra spacing | no extra spacing |
Devanagari*** | word-spacing* | word-spacing | word-spacing | word-spacing | word-spacing | word-spacing | word-spacing |
Arabic | kashida and word-spacing* | word-spacing | kashida and word-spacing | word-spacing | kashida and word-spacing | word-spacing | kashida and word-spacing |
SE Asian clusters | inter-cluster spacing* | inter-cluster spacing | inter-cluster spacing | no extra spacing | inter-cluster spacing | inter-cluster spacing | no extra spacing |
Interaction between text-justify values and script groups
*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.
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:
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:
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:
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:
Glyph layout with no compression
Glyph layout with punctuation compression
Glyph layout with punctuation and Kana compression
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:
Kashida applied to Arabic text
In that example no expansion occurs between the word themselves, indicating that the text-kashida-space property is set to 100%.
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.
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:
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'.
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:
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.
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.
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.)
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:
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:
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.
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.
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:
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:
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,
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:
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:
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:
Name: | white-space |
Value: | normal | pre | nowrap | pre-wrap | pre-line |
Initial: | not defined for shorthand properties |
Applies to: | all elements and generated content |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
Computed value: | see individual properties |
This property declares how 'white-space' inside the element is handled. Setting a value on the 'white-space' property sets 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 the following table, which shows the settings of the constituent properties.
white-space: | wrap-option: | linefeed-treatment: | white-space-treatment: | all-space-treatment: |
---|---|---|---|---|
normal | wrap | auto | ignore-if-surrounding-linefeed | collapse |
pre | no-wrap | preserve | preserve | preserve |
nowrap | no-wrap | auto | ignore-if-surrounding-linefeed | collapse |
pre-wrap | wrap | preserve | preserve | preserve |
pre-line | wrap | preserve | ignore-if-surrounding-linefeed | collapse |
Example(s):
The following examples show what white-space behavior is expected from the pre
and p
elements, the "nowrap" attribute in XHTML, and in generated content.
pre { white-space: pre } p { white-space: normal } td[nowrap] { white-space: nowrap } :before, :after {white-space: pre-line }
In addition, the effect of a XHTML pre
element with the non-standard "wrap"
attribute is demonstrated by the following example:
pre[wrap] {white-space: pre-wrap }
Text overflow deals with the situation where some textual content is clipped when it overflows the element's box in its inline-progression direction as determined by the 'writing-mode' property value. This situation only occurs when the 'overflow' property has the values: hidden, scroll or auto (in the latter case only when the user agent introduces a scrolling mechanism).
Text overflow allows the author to introduce a visual hint at the two ending boundaries of the text flow within the element box (after and end). The hint is typically a horizontal ellipsis character (U+2026), although the hint may be some other string or even an image. Setting a non empty string (or an uri for an image) for either text flow boundary enables the presentation of the hint. If both hints are enabled, only the 'after' hint is rendered. Initially, only the end of line hint is shown (correspond to the right of any over flown lines for left to right inline-progression).
Control over text-overflow is divided among properties: 'text-overflow-mode' controls the presence and position of the hint, 'text-overflow-ellipsis' controls what constitutes the hint. The shorthand property 'text-overflow' sets the other text flow properties.
Name: | text-overflow-mode |
Value: | clip | ellipsis | ellipsis-word |
Initial: | clip |
Applies to: | block-level and inline-block elements |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value (except for initial and inherit) |
The overflow hints are active only for textual content. That is, the user agent must not render an overflow hint when only replaced content overflows.
Although the property is not inherited, overflowing children blocks that are either statically or relatively positioned and do not have a specified width or height will be hinted as specified by their parent text-overflow-mode property value.
Consider the following example:
<blockquote> <p class="sentence"><span class="nowrap">I didn't like the play,</span> but then I saw it under adverse conditions - the curtain was up. <div class="attributed-to">_Groucho_Marx_</div> </p> </blockquote>
Here is the style sheet controlling the overflow situations:
blockquote { width:100px; border: thin solid red; overflow: hidden; text-overflow-mode:ellipsis;font-size:14px } span.nowrap { white-space : nowrap; } div.attributed-to { position: relative;left:8px }
This will result in the content of the span to be partially visible and the ellipsis will be shown, the inner div which is relatively positioned will only show a partial ellipsis as it is offset by few pixels:
Other children blocks, like absolute positioned blocks, or blocks with
specified width or height won't show hinting. For example, setting the p
element of the previous figure with the following style:
p.sentence { width :100px; margin-top : 50px; margin-left : 50px; }
will result in the absence of a hint overflow (because the element has a specified width). This would be shown like this:
Name: | text-overflow-ellipsis |
Value: | <ellipsis>{1,2} |
Initial: | U+2026 (value of) |
Applies to: | block-level and inline-block elements |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value (except for initial and inherit) |
The <ellipsis> value is defined as: [<string> | <uri>]. The <string> value determines a textual value for the overflow visual hint. The font-size used for the <string> is the element computed font-size. An empty string disables the hint. The <uri> value determines an image to be used for the overflow visual hint.
When only one <ellipsis> value is set by 'text-overflow-ellipsis', it determines the overflow visual hint at the end of the element box. If two <ellipsis> values area provided, they determine the overflow visual hint at the end and the overflow visual hint after the element box respectively. The visual hint after the element box only appear if there is content which is clipped because of the block-progression dimension of the block, not because the last line cannot fit. If the visual hint after the element box is enabled and would appear at the same location as the visual hint at the end of the element box, only the visual hint after the element box is rendered.
Note: Because the initial value (U+2026) of the overflow visual hint after the element box may not be easily rendered in some situations, the user agent may replace it by a sequence of 3 FULL STOP characters (U+002E).
Name: | text-overflow |
Value: | <'text-overflow-mode'> || <'text-overflow-ellipsis'> |
Initial: | not defined for shorthand properties |
Applies to: | block-level and inline-block elements |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | see individual properties |
This property is the shorthand for 'text-overflow-mode' and 'text-overflow-ellipsis'.
Name: | letter-spacing |
Value: | normal | <length> |
Initial: | normal |
Applies to: | all elements and generated content |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
Computed value: | <length> or 'normal' |
This property specifies spacing behavior between grapheme clusters.
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.
Values have the following meanings:
Because of the visually disruptive effect of modifying this spacing in writing systems, such as Arabic, which use joined glyphs, the usage of this property is discouraged in those cases.
There are cases, like in Japanese or Chinese writing systems, where justification will change all spacing between grapheme clusters, as there is no other opportunity in the line to expand or compress the textual content in order to fit the line.
The user agent determines the exact algorithm for spacing between grapheme clusters. Furthermore this property should not be set to a <length> for scripts and/or fonts that ligate glyphs with connecting strokes; such scripts and fonts include cursive Latin fonts, Arabic, Devanagari. Spacing between grapheme clusters may also be influenced by justification (see the 'text-align' property).
Example(s):
In this example, the space between grapheme clustes in blockquote elements is increased by '0.1em'.
blockquote { letter-spacing: 0.1em }
In the following example, the user agent is requested not to alter spacing within words:
blockquote { letter-spacing: 0cm } /* Same as '0' */
When the resultant spacing is not the default, user agents should consider avoiding the use of ligatures. (There are cases such as Arabic where ligatures may still be used)
Name: | word-spacing |
Value: | normal | <length> |
Initial: | normal |
Applies to: | all elements and generated content |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
Computed value: | <length>, 'normal' or 'none' |
This property specifies spacing behavior between words. Values have the following meanings:
Word spacing algorithms are user agent-dependent. Determining word boundary is typically done by detecting white space characters. There are however many scripts and writing systems that do not separate their words by any character (like Japanese, Chinese, Thai, etc...), detecting word boundaries in these cases require dictionary based algorithms that may not be supported by all user agents. Word spacing is also influenced by justification (see the 'text-align' property).
Example(s):
In this example, the word-spacing between each word in h1
elements is
increased by '1em'.
h1 { word-spacing: 1em }
Name: | punctuation-trim |
Value: | none | start |
Initial: | none |
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 determines whether or not a full-width punctuation mark character should be trimmed if it appears at the beginning of a line, so that its "ink" lines up with the first glyph in the line above and below. In some scenarios, it may be preferable for the author not to allow leading punctuation marks to be trimmed, for example when it is more important that the glyphs tend to line up vertically. In other scenarios such an effect is desirable, for example when it is more important for the author that as much text as possible fits on a single line.
Possible values:
Glyph layout with no leading punctuation compression
Glyph layout with leading punctuation compression
Note: This property may in the future be expanded to cover other punctuation behaviors for other types of punctuation as well, not just wide-cell.)
Name: | text-autospace |
Value: | none | [ideograph-numeric || ideograph-alpha || ideograph-space || ideograph-parenthesis] |
Initial: | none |
Applies to: | all elements and generated content |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value (except for initial and inherit) |
When a run of non-ideographic or numeric characters appears inside of ideographic text, a certain amount of space is often preferred on both sides of the non-ideographic text to separate it from the surrounding ideographic glyphs. This property controls the creation of that space when rendering the text. That added width does not correspond to the insertion of additional space characters, but instead to the width increment of existing glyphs.
(A commonly used algorithm for determining this behavior is specified in JIS X-4051 [JIS-X-4051].)
This property is additive with the 'word-spacing' and 'letter-spacing' [CSS2] properties. That is, the amount of spacing contributed by the 'letter-spacing' setting (if any) is added to the spacing created by 'text-autospace'. The same applies to 'word-spacing'.
Possible values:
The following example:
span.autospace { text-autospace:none; }
<span class="autospace">[ideographs]1997[ideographs]</span>
would appear as:
Mixed glyph layout when autospace is disabled
while changing the style to the following:
span.autospace { text-autospace:ideograph-numeric; }
would make the same text appear more like:
Mixed glyph layout when autospace is enabled
Name: | kerning-mode |
Value: | none | [pair || contextual] |
Initial: | none |
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 all kerning effects. Some kerning effects are based on information located explicitly on fonts (pair-kerning). Others are based on context and typical ink placement within characters and don't rely on font information. Pair kerning is used mainly for Latin, Greek and Cyrillic scripts, while contextual kerning is more common in East Asian context. A typical example of pair kerning is the pair 'Wa'. A good example of contextual kerning is the pair '[[' (when using the wide width variant). Possible values:
Name: | kerning-pair-threshold |
Value: | auto | <'font-size'> |
Initial: | auto |
Applies to: | all elements and generated content |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
Computed value: | <length> or 'auto' |
This property controls the font size threshold for the pair kerning effect. At the threshold value and above, pair kerning is active if enabled by the 'kerning-mode' property. Because pair kerning is not very effective at small font size, this property can be used to adjust the threshold.
Possible values:
In CSS1 and CSS2, the 'text-decoration' property controls text decorations: underline, overline, line-through, and blinking. CSS2 adds text shadows, which the 'text-shadow' property controls. However, the 'text-decoration' property has limitations stemming from its syntax, precluding fine control over each of those formatting effects. Specifically, it offers no way to control the color or line style of the underline, overline or line-through.
CSS3 extends the model by introducing new properties allowing additional controls over those formatting effects. CSS3 also makes turning these formatting effects on or off possible without affecting any other 'text-decoration' settings.
Furthermore, to reflect the usage of underline in East Asian vertical writing, a new control is offered for the underline positioning; this allows the underline to appear before (on the right in vertical text flow) or after (on the left in vertical text flow) the formatted text. The property is called 'text-underline-position'.
Note: In East Asian typography it is typical to 'emphasize' text using glyph elements such as an accent mark, a dot, a hollow circle, etc. This feature is tightly connected to the rendered font and is therefore described in the font module. See 'font-emphasis' [Link TBD to the CS3 fonts module] for more details.
The 'text-decoration' property itself is now a shorthand property for all these new properties. However, the 'text-decoration' values are not composites built from the values of constituent properties. Rather, 'text-decoration' values come from a small set specific to the 'text-decoration' shorthand property.
These properties describe decorations that are added to the text of an element. If they are specified for a block-level element, they affect the root inline box (the anonymous inline box which wraps all the inline children of an element).
If they are specified
for (or affects) an inline-level element, they
affect all boxes generated by the element. If an element is empty or is a
replaced element (e.g., img
element in XHTML), user agents must
refrain from rendering text decorations on the element. In deciding whether an
element is empty, user agents must ignore white-space characters that are collapsed during the white-space processing.
Text decoration properties are not inherited, but descendant boxes must be formatted with the same decoration (e.g., they must all be underlined). The color of decorations must remain the same even if descendant elements have different 'color' values.
When a text decoration could result in text being unintentionally overdrawn by the text decoration style, the user agents may chose to skip the text decoration over the intersecting area by using 'text-underline-mode', 'text-line-through-mode' or 'text-overline-mode' with the appropriate values.
In determining the position of and thickness of text decoration lines, user agents may consider the font sizes of and dominant baselines of children. Of course, user agents may ignore children in these determinations. Such an averaging is done on a line per line basis.
The following figure shows the averaging for underline:
In the three fragments of underlined text, the underline is drawn consecutively lower and thicker as the ratio of large text to small text increases.
Note: User agents typically consider superscript segments but ignore subscript segments. The baseline-shift is not considered for superscript segments.
Names: | text-underline-style, text-line-through-style, text-overline-style |
Value: | none | solid | double | dotted | dashed | dot-dash | dot-dot-dash | wave |
Initial: | none |
Applies to: | all elements with and generated content with textual content |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value (except for initial and inherit) |
These properties specifies the line style for underline, line-through and overline text decoration. Possible values:
The following figure shows the appearance of these various line styles.
The line styles
Names: | text-underline-width, text-line-through-width, text-overline-width |
Value: | auto | <normal> | <number> | <length> | <percentage> thin | medium | thick |
Initial: | auto |
Applies to: | all elements with and generated content with textual content |
Inherited: | no |
Percentages: | computed 'font-size' |
Media: | visual |
Computed value: | <length> |
These property specifies the line width for the underline, line-through and overline text decorations. Possible values:
Names: | text-underline-color, text-line-through-color, text-overline-color |
Value: | auto | <color> |
Initial: | auto |
Applies to: | all elements with and generated content with textual content |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | <color> |
These property specifies the line colors for the underline, line-through and overline text decorations. Possible values:
Names: | text-underline-mode, text-line-through-mode, text-overline-mode |
Value: | continuous | skip-white-space | skip-glyph | skip-glyph-and-white-space |
Initial: | continuous |
Applies to: | all elements with and generated content with textual content |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value (except for initial and inherit) |
These properties set the mode for the underline, line-through and overline text decorations, determining whether the text decoration affects the space characters or not. 'Space characters' are all characters classified by the Unicode Standard [UNICODE] as category 'Zs', in addition to the white-space characters. Possible values:
Name: | text-underline-position |
Value: | auto | before-edge | alphabetic | after-edge |
Initial: | auto |
Applies to: | all elements with and generated content with textual content |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value (except for initial and inherit) |
This property sets the position of the underline when set through the 'text-underline-style' property. It can appear either 'before' (above in an horizontal flow) or after (below in an horizontal flow) the run of text in relation to its baseline orientation. This property is typically used in vertical writing context where it may be desired to have the underline appear 'before' the run of text. This results in having the underline appearing on the right side of the vertical writing column. Possible values:
Name: | text-blink |
Value: | none | blink |
Initial: | none |
Applies to: | all elements with and generated content with textual content |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value (except for initial and inherit) |
This property specifies the blink mode. Possible values:
The 'text-underline' property is the shorthand for 'text-underline-style', 'text-underline-width', 'text-underline-color', 'text-underline-mode' and 'text-underline-position'. Any constituent properties not explicitly assigned values in a 'text-underline' declaration take their respective initial values.
Name: | text-underline |
Value: | <'text-underline-style'> || <'text-underline-color'> || <'text-underline-mode'> || <'text-underline-position'> |
Initial: | not defined for shorthand properties |
Applies to: | all elements with and generated content with textual content |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value (except for initial and inherit) |
The 'line-through' property is the shorthand for 'text-line-through-style', 'text-line-through-width', 'text-line-through-color' and 'text-line-through-mode'. Any constituent properties not explicitly assigned values in a 'text-line-through' declaration take their respective initial values.
Name: | text-line-through |
Value: | <'text-line-through-style'> || <'text-line-through-color'> || <'text-line-through-mode'> |
Initial: | not defined for shorthand properties |
Applies to: | all elements with and generated content with textual content |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | see individual properties |
The 'text-overline' property is the shorthand for 'text-overline-style', 'text-overline-width', 'text-overline-color' and 'text-overline-mode'. Any constituent properties not explicitly assigned values in a 'text-overline' declaration take their respective initial values.
Name: | text-overline |
Value: | <'text-overline-style'> || <'text-overline-color'> || <'text-overline-mode'> |
Initial: | not defined for shorthand properties |
Applies to: | all elements with and generated content with textual content |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | see individual properties |
The 'text-decoration' property is a shorthand that takes its own set of values.
Name: | text-decoration |
Value: | none | [ underline || overline || line-through || blink] |
Initial: | see individual properties |
Applies to: | all elements with and generated content with textual content |
Inherited: | no (see prose) |
Percentages: | N/A |
Media: | visual |
Computed value: | see individual properties |
The 'text-decoration' shorthand sets the properties 'text-underline-style', 'text-underline-width', 'text-underline-color', 'text-underline-mode', 'text-underline-position', 'text-line-through-style', 'text-line-through-width', 'text-line-through-color', 'text-line-through-mode', 'text-overline-style', 'text-overline-width', 'text-overline-color', 'text-overline-mode' and 'text-blink' to their initial values, and then the values of the shorthand change these values as follows:
Conforming user agents may simply not blink the text.
Although the property has no explicit initial value, it is equivalent to the value 'none.
Example(s):
In the following example for XHTML, the text content of all a elements acting as hyperlinks will be underlined and blinking:
a[href] { text-decoration: underline blink }
Name: | text-shadow |
Value: | none | [<shadow>, ] * <shadow> |
Initial: | none |
Applies to: | all elements and generated content |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | specified values (except for initial and inherit) |
<shadow> itself is defined as "[<color> <length> <length> <length>? | <length> <length> <length>? <color>?]".
This property accepts a comma-separated list of shadow effects to be applied to the text of the element. The shadow effects are applied in the order specified and may thus overlay each other, but they will never overlay the text itself. Shadow effects do not alter the size of a box, but may extend beyond its boundaries. The stack level of the shadow effects is the same as for the element itself.
Each shadow effect must specify a shadow offset and may optionally specify a blur radius and a shadow color.
A shadow offset is specified with two <length> terms that indicate the distance from the text. The first length term specifies the horizontal distance to the right of the text. A negative horizontal length term places the shadow to the left of the text. The second length term specifies the vertical distance below the text. A negative vertical length term places the shadow above the text.
A blur radius may be specified after the shadow offset. The blur radius is a length value that indicates the boundaries of the blur effect. The exact algorithm for computing the blur effect is not specified. If no blur radius is specified, the treatment is as if a blur radius of zero were specified and the shadow has the same size and shape as the glyphs that cast it. User agents may only implement only part of this property by ignoring blur effects. Such user agents should consider declarations that specify the blur radius to be parser errors, as described in the Syntax module [link TBD].
A color term may be specified before or after the length terms of the shadow effect. The color term will be used as the basis for the shadow effect. If no color is specified, the value of the 'color' property will be used instead.
Text shadows may be used with the ::first-letter and ::first-line pseudo-elements.
Example(s):
The example below will set a text shadow to the right and below the element's text. Since no color has been specified, the shadow will have the same color as the element itself, and since no blur radius is specified, the text shadow will not be blurred:
h1 { text-shadow: 0.2em 0.2em }
The next example will place a shadow to the right and below the element's text. The shadow will have a 5px blur radius and will be red.
h2 { text-shadow: 3px 3px 5px red }
The next example specifies a list of shadow effects. The first shadow will be to the right and below the element's text and will be red with no blurring. The second shadow will overlay the first shadow effect, and it will be yellow, blurred, and placed to the left and below the text. The third shadow effect will be placed to the right and above the text. Since no shadow color is specified for the third shadow effect, the value of the element's 'color' property will be used:
h2 { text-shadow: 3px 3px red, yellow -3px 3px 2px, 3px -3px }
Example(s):
Consider this example:
span.glow { background: white; color: white; text-shadow: black 0px 0px 5px; }
Here, the 'background' and 'color' properties have the same value and the 'text-shadow' property is used to create a "solar eclipse" effect:
Note: This property is not defined in CSS1. Some shadow effects (such as the one in the last example) may render text invisible in user agents that only support CSS1. The usage of this property is discouraged as much better filter effects are available in SVG [SVG1.0].
It is very common for the glyphs in documents written in East Asian languages, such as Chinese or Japanese, to be laid out on the page according to a specified one- or two-dimensional grid. The concept of grid can also be used in other, non-ideographic contexts such as Braille or monospaced layout.
The diagram below represents a fragment of horizontal text on a page with mixed wide-cell and narrow-cell glyphs that a Japanese user intended to be laid out on a grid which resulted in 9 glyphs per line (gray grid lines shown for clarity):
'Genko' grid applied to mixed text
The grid behavior can be set on the inline-progression, on the block-progression or both. The grid on the block-progression dimension is determined by the following properties:
The block-progression grid is not described in this section as it can be achieved simply by using the properties mentioned above and described in the CSS3 Line module.
The grid on the inline-progression dimension is obtained by altering the glyphs advance width (or inline-progression value) of inline elements. There are several modes:
Two properties control this advance width modification: 'line-grid-mode' enables it and 'line-grid-progression' determines its value. The shorthand 'line-grid' allows setting both together.
Name: | line-grid-mode |
Value: | none | ideograph | all |
Initial: | none |
Applies to: | block-level and inline-block elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value (except for initial and inherit) |
Specifies the line grid behavior. Each line grid mode value entails a different set of rules for rendering inline contents (the term 'horizontal' is used in the following description to indicate the inline-progression dimension). Possible values:
No line grid. Standard text alignments apply to the block element.
Each grapheme cluster with a wide base character is a strip. Each grapheme cluster with a narrow kana character as its base is a strip. Each non-breakable object (e.g. an image) is a strip. Other grapheme clusters are treated as a single strip bounded by the strips described prior. That single strip may be decomposed in several strips if line breaking occurs within it.
The strip are arranged in the grid as follows:
Mixed glyph layout in strict grid
Object layout in strict grid
The 'ideograph' mode disables all special text justification and glyph width adjustment normally applied to the contents of the block element.
If a line break opportunity cannot be found in a text run going over the line boundary, then that text run will be pushed down to the next line and the last part of the previous line will be left blank.
Here is an example of mixed text in 'ideograph' grid mode:
Strict grid applied to mixed text
Each grapheme cluster with a non-joining base character is a strip. Each non-breakable object (e.g. an image) is a strip. Each run of grapheme clusters with joining base characters that join to each other is a strip.
Mixed glyph layout in fixed grid
For example:
Fixed grid applied to mixed text
The 'letter-spacing' property does not apply to characters in a grid but does apply for all characters not in the grid (i.e. all characters for 'line-grid-mode: none', non-ideographs for 'line-grid-mode: ideograph' and all non-connected glyphs for 'line-grid-mode: all').
Name: | line-grid-progression |
Value: | text-height | line-height | <length> |
Initial: | text-height |
Applies to: | block-level and inline-block elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
Computed value: | <length> |
This property affects the inline-progression dimension of characters which are subject to the fixed advance width as determined by the 'line-grid-mode' property.
Possible values:
For example:
div.section1 { line-grid-progression: .5in }
The rule set above would make grid spaces 0.5 inches long in a div element in the section1 class. If the element has horizontal flow, it would like the following (without the grid lines, which are shown for clarity).
Enlarged grid applied to mixed text in horizontal layout
If the element has vertical flow, then 0.5in is the vertical measure of each grid space:
Enlarged grid applied to mixed text in vertical-ideographic layout
Name: | line-grid |
Value: | <'line-grid-mode'> || <'line-grid-progression'> |
Initial: | not defined for shorthand properties |
Applies to: | block-level and inline-block elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
Computed value: | see individual properties |
The 'line-grid' property is a shorthand property for setting 'line-grid-mode' and 'line-grid-progression'.
The following is an example of setting the grid in both progression:
div.grid { line-height:20pt; text-height: max-size; line-stacking-strategy: grid-height; line-grid: ideograph line-height; }
This sets for the div
element a grid with 20pt inline and
block-progression
dimensions. All ideographs will be set in cells sized in multiple of 20pt in
both directions.
Name: | text-transform |
Value: | capitalize | uppercase | lowercase | none |
Initial: | none |
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 capitalization effects of an element's text. Values have the following meanings:
Although limited, the case mapping process has some language dependencies. Some well known examples are Turkish and Greek. See HTML [HTML401] for ways to find the language of an HTML element. XML, and consequently [XHTML1.0], uses an attribute called xml:lang. There may be other ways, specific to certain document languages, to determine the human language.
The case mapping rules for the character repertoire specified by the Unicode Standard 3.2 can be found on the Unicode Consortium web site at [UNICODE-casing].
Conforming user agents must support case mapping rules according to the Unicode Standard 3.2 for all characters specified by that standard.
Note: The conformance rule is more stringent than the ones specified in lower levels of CSS.
Example:
In this example, all text in an h1 element is transformed to uppercase text.
h1 { text-transform: uppercase }
Name: | hanging-punctuation |
Value: | none | start | end | both |
Initial: | none |
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 determines whether a punctuation mark, if one is present, may be placed outside the content area at the start or at the end of a full line of text. Allowing a punctuation to hang at the end of a line is is a common practice in East Asian typography. It is the responsibility of the designer to create meaningful padding and margin areas to allow effective rendering of the punctuation. If the padding and margin are of zero width or not wide enough to show the punctuation, the punctuation may not be rendered.
Note: Compression, including compression of the punctuation characters, may also occur in the line independently of this effect.
Possible values:
In the following example 'hanging-punctuation' has the value 'none':
No hanging punctuation allowed (the punctuation mark and the glyph preceding it shown in blue and the right content edge shown with dashed line for clarity)
In the following example 'hanging-punctuation' has the value 'end'.
Punctuation hanging at the end of line padding area (the punctuation and the glyph preceding it shown in blue and the right content edge shown with dashed line for clarity)
Note: User agents should follow the script-specific and language-specific conventions about which lines allow which hanging punctuation. For example, in Latin text, a leading punctuation mark may overhang only on the first line and a trailing punctuation may overhang only on the last line. It would look improper in other lines. The following figure shows an example of correct usage.
Name: | text-combine |
Value: | none | letters | lines |
Initial: | none |
Applies to: | inline and inline-block elements and generated content |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value (except for initial and inherit) |
This property controls the creation of grapheme clusters ("kumimoji") or lines ("warichu").
Possible values:
No more than five grapheme clusters can combine into a unit. If an element with 'text-combine' set to 'letters' has more than five, only the first five are combined. The rest is rendered as regular text. If the text to be combined has only a single grapheme cluster, no special combination effect occurs. The following texts shows the arrangement for two, three, four and five grapheme clusters:
The valid "Kumimoji" arrangements
The following styling rule:
span.kumimoji { text-combine: letters }
applied to the following fragment:
<span>くみもじ <span class="kumimoji">くみもじ</span></span>
would make the 4 glyphs of the second span element appear as one (shown in blue for clarity):
"Kumimoji" applied to four glyphs
The following figure shows a typical usage for this feature.
Glyph layout in Warichu within a single line box
Glyph layout in Warichu split within two line boxes
The following styling rule:
span.warichu { text-combine: lines }
applied to the following fragment:
<span>割注( <span class="warichu">これは わりちゅです。</span> )です。</span>
would make the enclosed text look like the following (shown in blue for clarity):
"Warichu" applied to 10 characters
In addition to the specified values, all properties take the initial and inherit values.
Property | Values | Initial | Applies to | Inh. | Percentages | Media |
---|---|---|---|---|---|---|
all-space-treatment | preserve | collapse | collapse | all elements and generated content | yes | N/A | visual |
direction | ltr | rtl | ltr | all elements and generated content, but see prose | yes | N/A | visual |
glyph-orientation-horizontal | <angle> | 0deg | all elements and generated content | yes | N/A | visual |
glyph-orientation-vertical | <angle> | auto | auto | all elements and generated content | yes | N/A | visual |
hanging-punctuation | none | start | end | both | none | block-level and inline-block elements | yes | N/A | visual |
kerning-mode | none | [pair || contextual] | none | all elements and generated content | yes | N/A | visual |
kerning-pair-threshold | auto | <'font-size'> | auto | all elements and generated content | yes | N/A | visual |
letter-spacing | normal | <length> | normal | all elements and generated content | yes | N/A | visual |
line-break | normal | strict | normal | all elements and generated content | yes | N/A | visual |
linefeed-treatment | auto | ignore | preserve | treat-as-space | treat-as-zero-width-space | ignore-if-after-linefeed | auto | all elements and generated content | yes | N/A | visual |
line-grid | <'line-grid-mode'> || <'line-grid-progression'> | not defined for shorthand properties | block-level and inline-block elements | yes | N/A | visual |
line-grid-mode | none | ideograph | all | none | block-level and inline-block elements | yes | N/A | visual |
line-grid-progression | text-height | line-height | <length> | text-height | block-level and inline-block elements | yes | N/A | visual |
max-font-size | <'font-size'> | auto | auto | all elements and generated content | yes | element's computed 'font-size' | visual |
min-font-size | <'font-size'> | auto | auto | all elements and generated content | yes | element's computed 'font-size' | visual |
punctuation-trim | none | start | none | block-level and inline-block elements | yes | N/A | visual |
text-align | start | end | left | right | center | justify | <string> | start | block-level and inline-block elements | yes | N/A | visual |
text-align-last | relative | start | end | center | justify | size | auto | block-level and inline-block elements | yes | N/A | visual |
text-autospace | none | [ideograph-numeric || ideograph-alpha || ideograph-space || ideograph-parenthesis] | none | all elements and generated content | yes | N/A | visual |
text-blink | none | blink | none | all elements and generated content | no | N/A | visual |
text-block-indent | none | auto | none | block-level and inline-block elements | no | N/A | visual |
text-combine | none | letters | lines | none | all elements and generated content | no | N/A | visual |
text-decoration | none | [ underline || overline || line-through || blink] | not defined for shorthand properties | all elements with and generated content with textual content | no (see prose) | N/A | visual |
text-first-indent | <length> | <percentage> | 0 | block-level and inline-block elements | yes | refers to width of containing block | visual |
text-indent | <length> | <percentage> | not defined for shorthand properties | block-level and inline-block elements | yes | refers to width of containing block | visual |
text-justify | auto | inter-word | inter-ideograph | distribute | newspaper | inter-cluster | kashida | auto | block-level and inline-block elements | yes | N/A | visual |
text-justify-trim | none | punctuation | punctuation-and-kana | punctuation | block-level and inline-block elements | yes | N/A | visual |
text-kashida-space | <percentage> | 0% | block-level and inline-block elements | yes | as described | visual |
text-line-through | <'text-line-through-style'> || <'text-line-through-color'> || <'text-line-through-mode'> | not defined for shorthand properties | all elements with and generated content with textual content | no | N/A | visual |
text-line-through-color | auto | <color> | auto | all elements with and generated content with textual content | no | N/A | visual |
text-line-through-mode | continuous | skip-white-space | skip-glyph | skip-glyph-and-white-space | continuous | all elements with and generated content with textual content | no | N/A | visual |
text-line-through-style | none | solid | double | dotted | thick | dashed | dot-dash | dot-dot-dash | wave | none | all elements with and generated content with textual content | no | N/A | visual |
'text-line-through-width' | auto | <normal> | <number> | <length> | <percentage> thin | medium | thick | auto | all elements with and generated content with textual content | no | computed 'font-size' | visual |
text-overflow | <'text-overflow-mode'> || <'text-overflow-ellipsis'> | not defined for shorthand properties | block-level and inline-block elements | no | N/A | visual |
text-overflow-ellipsis | <ellipsis>{1,2} | U+2026 (value of) | block-level and inline-block elements | no | N/A | visual |
text-overflow-mode | clip | ellipsis | ellipsis-word | clip | block-level and inline-block elements | no | N/A | visual |
text-overline | <'text-overline-style'> || <'text-overline-color'> || <'text-overline-mode'> | not defined for shorthand properties | all elements with and generated content with textual content | no | N/A | visual |
text-overline-color | auto | <color> | auto | all elements with and generated content with textual content | no | N/A | visual |
text-overline-mode | continuous | skip-white-space | skip-glyph | skip-glyph-and-white-space | continuous | all elements with and generated content with textual content | no | N/A | visual |
text-overline-style | none | solid | double | dotted | thick | dashed | dot-dash | dot-dot-dash | wave | none | all elements with and generated content with textual content | no | N/A | visual |
'text-overline-width' | auto | <normal> | <number> | <length> | <percentage> thin | medium | thick | auto | all elements with and generated content with textual content | no | computed 'font-size' | visual |
text-script | auto | <script> | auto | all elements and generated content | yes | N/A | visual |
text-shadow | none | [<color> || <length> <length> <length>? ,]* [<color> || <length> <length> <length>?] | none | all elements and generated content | no (see prose) | N/A | visual |
text-transform | capitalize | uppercase | lowercase | none | none | all elements and generated content | yes | N/A | visual |
text-underline | <'text-underline-style'> || <'text-underline-color'> || <'text-underline-mode'> || <'text-underline-position'> | not defined for shorthand properties | all elements with and generated content with textual content | no | N/A | visual |
text-underline-color | auto | <color> | auto | all elements with and generated content with textual content | no | N/A | visual |
text-underline-mode | continuous | skip-white-space | skip-glyph | skip-glyph-and-white-space | continuous | all elements with and generated content with textual content | no | N/A | visual |
text-underline-position | auto | before-edge | after-baseline | after-edge | auto | all elements with and generated content with textual content | no | N/A | visual |
text-underline-style | none | solid | double | dotted | dashed | dot-dash | dot-dot-dash | wave | none | all elements with and generated content with textual content | no | N/A | visual |
'text-underline-width' | auto | <normal> | <number> | <length> | <percentage> thin | medium | thick | auto | all elements with and generated content with textual content | no | computed 'font-size' | visual |
unicode-bidi | normal | embed | bidi-override | normal | all elements and generated content, but see prose | no | N/A | visual |
white-space | normal | pre | nowrap | pre-wrap | pre-line | not defined for shorthand properties | all elements and generated content | yes | N/A | visual |
white-space-treatment | ignore | preserve | ignore-if-before-linefeed | ignore-if-after-linefeed | ignore-if-surrounding-linefeed | ignore-if-surrounding-linefeed | all elements and generated content | yes | N/A | visual |
word-break | <'word-break-cjk'> || <'word-break-inside'> | see individual properties | all elements and generated content | yes | N/A | visual |
word-break-cjk | normal | break-all | keep-all | normal | all elements and generated content | yes | N/A | visual |
word-break-inside | normal | hyphenate | normal | all elements and generated content | yes | N/A | visual |
word-spacing | normal | <length> | normal | all elements and generated content | yes | N/A | visual |
wrap-option | wrap | no-wrap | soft-wrap | emergency | wrap | all elements and generated content | yes | N/A | visual |
writing-mode | lr-tb | rl-tb | tb-rl | tb-lr | bt-rl | bt-lr | lr | rl | tb | lr-tb | all elements and generated content | yes | N/A | visual |
The following properties are defined in other specifications:
This document defines three modules: The CSS1 text module, the CSS2 text module and the CSS3 text module.
The CSS1 text module has the following properties and values:
Name | Values | Initial | Applies to | Inherited | Percentages | Media groups |
---|---|---|---|---|---|---|
'letter-spacing' | normal | <length> | normal | all elements | yes | N/A | N/A |
'text-align' | left | right | center | justify | depends on user agent and writing direction | block-level elements | yes | N/A | N/A |
'text-decoration' | none | [ underline || overline || line-through || blink ] | none | all elements | no (see prose) | N/A | N/A |
'text-indent' | <length> | <percentage> | inherit | 0 | block-level elements | yes | refers to width of containing block | N/A |
'text-transform' | capitalize | uppercase | lowercase | none | inherit | none | all elements | yes | N/A | N/A |
'word-spacing' | normal | <length> | normal | all elements | yes | N/A | N/A |
'white-space' | normal | pre | nowrap | normal | all elements | yes | N/A | N/A |
Concerning the 'text-align' property, a conforming CSS1 user agent my interpret the value 'justify' as 'left' or 'right', depending on whether the element's current text direction is left-to-right or riht-to-left respectively.
The following table describes the CSS2 text module. Because all properties have added the 'inherit' value and have a media type, all CSS1 properties have been specified below as well. The properties added are 'direction', 'text-shadow' and 'unicode-bidi'. In addition, the 'text-align' has a new value: <string>.
.Name | Values | Initial | Applies to | Inherited | Percentages | Media groups |
---|---|---|---|---|---|---|
'direction' | ltr | rtl | inherit | ltr | all elements and generated content, but see prose | yes | N/A | visual |
'letter-spacing' | normal | <length> | inherit | normal | all elements and generated content | yes | N/A | visual |
'text-align' | left | right | center | justify | <string> | inherit | depends on user agent and writing direction | block-level elements | yes | N/A | visual |
'text-decoration' | none | [ underline || overline || line-through || blink] | inherit | none | all elements and generated content | no (see prose) | N/A | visual |
'text-indent' | <length> | <percentage> | inherit | 0 | block-level elements | yes | refers to width of containing block | visual |
'text-shadow' | none | [<color> || <length> <length> <length>? ,]* [<color> || <length> <length> <length>?] | inherit | none | all elements and generated content | no (see prose) | N/A | visual |
'text-transform' | capitalize | uppercase | lowercase | none | inherit | none | all elements and generated content | yes | N/A | visual |
'unicode-bidi' | normal | embed | bidi-override | inherit | normal | all elements and generated content, but see prose | no | N/A | visual |
'white-space' | normal | pre | nowrap | inherit | normal | block-level elements | yes | N/A | visual |
'word-spacing' | normal | <length> | inherit | normal | all elements and generated content | N/A | visual |
The CSS3 module adds the following properties:
It also modifies the following properties as described:
In general, the existing [CSS2] properties that imply directionality or position are absolute, i.e. "left" means "left" and "top" means "top" regardless of the writing mode of the page. The purpose of this appendix however is to list the exceptions to that rule and clarify ambiguities. If a property does not appear in this list, it is intended to be interpreted as absolute, i.e. it does not rotate when the layout mode changes.
CSS Property | Effect in vertical layout |
---|---|
'clear' | 'float' and 'clear' property values interpretation is absolute in horizontal flow and logical in vertical flow (left is start, right is end). |
'direction' | relative (logical), i.e. ltr implies top-to-bottom character progression in vertical layout. |
'display' | relative (logical), i.e. the values that are directional (table-) are relative to the element orientation as specified by the writing mode. |
'float' | [see the text about 'clear'] |
'line-height' | relative (logical), i.e. this controls the "height" of a line if horizontal, or the "width", if vertical. In other words, this controls the size of the line in the dimension perpendicular to the baseline. |
'quotes' | relative (logical), the concept of open-quotes and close-quotes is already used in CSS. (Note that the quote glyph may vary depending on the glyph-orientation.) |
'text-align' | 'left' and 'right' are physical in horizontal inline-progression and depend on the user agent in vertical inline-progression. 'start' and 'end' are always relative. |
'unicode-bidi' | relative (logical), i.e. it affects glyph progression regardless of layout. |
'vertical-align' | relative (logical), i.e. 'top' and 'bottom' values maps to 'before-edge' and 'after-edge' values in baseline alignment properties. |
This specification would not have been possible without the help from:
Ayman Aldahleh, Stephen Deach, Martin Dürst, Laurie Anna Edlund, Ben Errez, Yaniv Feinberg, Arye Gittelman, Richard Ishida, Koji Ishii, Masayasu Ishikawa, Michael Jochimsen, Eric LeVine, Chris Pratley, Rahul Sonnad, Frank Tang, Chris Thrasher, Etan Wexler, Masafumi Yabe.