CSS3 Writing Modes defines CSS features to support for various
international writing modes, such as left-to-right (e.g. Latin or Indic),
right-to-left (e.g. Hebrew or Arabic), bidirectional (e.g. mixed Latin and
Arabic) and vertical (e.g. Asian scripts).
Inherently bottom-to-top scripts are not handled in this version. See [UTN22] for an
explanation of relevant issues.
Status of this document
This section describes the status of this document at the time of
its publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical report
can be found in the W3C technical reports
index at http://www.w3.org/TR/.
Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress.
The (archived) public
mailing list [email protected] (see
instructions) is preferred
for discussion of this specification. When sending e-mail, please put the
text “css3-writing-modes” in the subject, preferably like
this: “[css3-writing-modes] …summary of
comment…”
CSS3 Writing Modes defines CSS features to support for various
international writing modes, such as left-to-right (e.g. Latin or Indic),
right-to-left (e.g. Hebrew or Arabic), bidirectional (e.g. mixed Latin and
Arabic) and vertical (e.g. Asian scripts).
The inline base direction is the
primary direction in which content is ordered on a line and defines on
which sides the "start" and "end" of a line are. The ‘direction’
property specifies the inline base direction of an element and, together
with the ‘unicode-bidi’ property and the inherent
directionality of any text content, determines the ordering of
inline-level content within a line.
The block flow direction is the
direction in which block-level boxes stack and the direction in which line
boxes stack within a block container. The ‘writing-mode’
property determines the block flow direction.
A horizontal writing mode is one
with horizontal lines of text, i.e. a downward or upward block flow. A
vertical writing mode is one with
vertical lines of text, i.e. a leftward or rightward block flow.
These terms should not be confused with vertical block flow (which is a downward or
upward block flow) and horizontal block
flow (which is leftward or rightward block flow). To avoid
confusion, the CSS specifications avoid this latter set of terms.
Writing systems typically have one or two native writing modes. Some
examples are:
Latin-based systems are typically written using a left-to-right inline
direction with a downward (top-to-bottom) block flow direction.
Arabic-based systems are typically written using a right-to-left
inline direction with a downward (top-to-bottom) block flow direction.
Mongolian-based systems are typically written using a top-to-bottom
inline direction with a rightward (left-to-right) block flow direction.
Han-based systems are commonly written using a left-to-right inline
direction with a downward (top-to-bottom) block flow direction,
or a top-to-bottom inline direction with a leftward
(right-to-left) block flow direction. Many magazines and newspapers will
mix these two writing modes on the same page.
See Unicode Technical Note #22 [UTN22] (HTML
version) for a more in-depth introduction to writing modes and
vertical text.
Point at Intro to Text Orientation section once it's
written.
1.1. Module Interactions
This module replaces and extends the ‘unicode-bidi’
and ‘direction’ features defined in [CSS21] sections 8.6
and 9.10.
1.2. Document Conventions
Conformance requirements are expressed with a combination of descriptive
assertions and RFC 2119 terminology. The key words “MUST”, “MUST
NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the
normative parts of this document are to be interpreted as described in RFC
2119. However, for readability, these words do not appear in all uppercase
letters in this specification.
All of the text of this specification is normative except sections
explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for
example” or are set apart from the normative text with
class="example", like this:
This is an example of an informative example.
Informative notes begin with the word “Note” and are set apart from
the normative text with class="note", like this:
Note, this is an informative note.
1.3. Values
This specification follows the CSS property
definition conventions from [CSS21]. Value types not defined in
this specification are defined in CSS Level 2 Revision 1 [CSS21]. Other CSS
modules may expand the definitions of these value types: for example [CSS3COLOR],
when combined with this module, expands the definition of the
<color> value type as used in this specification.
In addition to the property-specific values listed in their definitions,
all properties defined in this specification also accept the inherit
keyword as their property value. For readability it has not been repeated
explicitly.
2. Inline Direction and
Bidirectionality
While the characters in most scripts are written from left to right,
certain scripts are written from right to left. In some documents, in
particular those written with the Arabic or Hebrew script, and in some
mixed-language contexts, text in a single (visually displayed) block may
appear with mixed directionality. This phenomenon is called bidirectionality, or "bidi" for short.
با Unicode بنویس.
<----- ------> <-
<================
Bidirectionality
The Unicode standard (Unicode Standard Annex #9)
defines a complex algorithm for determining the proper ordering of
bidirectional text. The algorithm consists of an implicit part based on
character properties, as well as explicit controls for embeddings and
overrides. CSS relies on this algorithm to achieve proper bidirectional
rendering. The ‘direction’
and ‘unicode-bidi’ properties allow
authors to specify how the elements and attributes of a document language
map to this algorithm.
User agents that support bidirectional text must apply the Unicode
bidirectional algorithm to every sequence of inline boxes uninterrupted by
a forced (bidi
class B) paragraph break or block boundary. This sequence forms the
paragraph unit in the bidirectional algorithm.
Except when the ‘plaintext’ value of ‘unicode-bidi’
is in effect, the paragraph embedding level is set according to the value
of the ‘direction’ property of the paragraph's
element rather than by the heuristic given in steps P2 and P3 of the
Unicode algorithm. The paragraph's element is usually the containing
block, but in the case of a paragraph contained by bidi isolation it is the isolating inline element instead.
Because the base directionality of a text depends on the structure and
semantics of the document, the ‘direction’ and ‘unicode-bidi’
properties should in most cases be used only to map bidi information in
the markup to its corresponding CSS styles. If a document language
provides markup features to control bidi, authors and users should use
those features and not specify CSS rules to override them.
The HTML 4 specification ([HTML401], section 8.2) defines
bidirectionality behavior for HTML elements. The HTML 4 specification also
contains more information on bidirectionality issues.
Because HTML UAs can turn off CSS styling, we advise HTML
authors to use the HTML ‘dir’
attribute and <bdo> element to ensure correct bidirectional layout
in the absence of a style sheet.
2.1. Specifying Directionality:
the ‘direction’ property
Name:
direction
Value:
ltr | rtl
Initial:
ltr
Applies to:
all elements
Inherited:
yes
Percentages:
N/A
Media:
visual
Computed value:
specified value
This property specifies the base directionality of text and elements on
a line, and the directionality of embeddings and overrides (see ‘unicode-bidi’)
for the Unicode bidirectional algorithm. In addition, it affects the
ordering of table
column layout, the direction of horizontal overflow, and
the default alignment of text within a line, and other things that depend
on the base inline base direction.
Values for this property have the following meanings:
ltr
Left-to-right directionality.
rtl
Right-to-left directionality.
The ‘direction’ property has no effect on bidi
reordering when specified on inline elements whose ‘unicode-bidi’
property's value is ‘normal’.
The value of the ‘direction’ property on the root element is
also propagated to the initial containing block and, together with the
‘writing-mode’ property, determines the
document's principal writing mode. (See below.)
Note that the ‘direction’ property of the HTML BODY
element is not propagated to the viewport. That special behavior
only applies to the background and overflow properties.
The ‘direction’ property, when specified for
table column elements, is not inherited by cells in the column since
columns are not the ancestors of the cells in the document tree. Thus, CSS
cannot easily capture the "dir" attribute inheritance rules described in
[HTML401],
section 11.3.2.1.
2.2. Embeddings and Overrides:
the ‘unicode-bidi’ property
Values for this property have the following meanings:
normal
The element does not open an additional level of embedding with
respect to the bidirectional algorithm. For inline elements, implicit
reordering works across element boundaries.
embed
If the element is inline, this value opens an additional level of
embedding with respect to the bidirectional algorithm. The direction of
this embedding level is given by the ‘direction’ property. Inside the element,
reordering is done implicitly. This corresponds to adding a LRE (U+202A),
for ‘direction: ltr’, or RLE (U+202B),
for ‘direction: rtl’, at the start of
the element and a PDF (U+202C) at the end of the element. This value has no effect on elements that are not
inline.
isolate
For the purposes of the Unicode bidirectional algorithm, the contents
of the element are considered to be inside a separate, independent
paragraph, and for the purpose of bidi resolution in its containing bidi
paragraph (if any), the element itself is treated as if it were an Object
Replacement Character (U+FFFC). (If the element is broken across multiple
lines, then each box of the element is treated as an Object Replacement
Character.)
plaintext
For the purposes of the Unicode bidirectional algorithm, the base
directionality of each bidi paragraph for which the element forms the
containing block is determined not by the element's computed ‘direction’ as
usual, but by following rules P2 and P3 of the Unicode bidirectional
algorithm. Note this value has no effect on inline elements.
bidi-override
For inline elements this creates an override. For block-container
elements this creates an override for inline-level descendants not within
another block container element. This means that inside the element,
reordering is strictly in sequence according to the ‘direction’
property; the implicit part of the bidirectional algorithm is ignored.
This corresponds to adding a LRO (U+202D), for ‘direction: ltr’, or RLO (U+202E), for ‘direction: rtl’, at the start of the element and a
PDF (U+202C) at the end of the element.
The final order of characters within in each bidi paragraph is the same
as if the bidi control codes had been added as described above, markup had
been stripped, 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. If an inline element is
broken around a bidi paragraph boundary (e.g. if split by a block or
forced paragraph break), then the bidi control codes corresponding to the
end of the element are added before the interruption and the codes
corresponding to the start of the element are added after it. (In other
words, any embedding levels or overrides started by the element are closed
at the paragraph break and reopened on the other side of it.)
In this process, replaced elements with ‘display:
inline’ are treated as neutral characters, unless their
‘unicode-bidi’ property has a value other
than ‘normal’, in which case they are treated as
strong characters in the ‘direction’ specified for the element. All
other atomic inline-level boxes are treated as neutral characters always.
Please note that 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: isolate’ 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: document language 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, and
such rules should not be overridden by other style sheets so that the
document language's bidi behavior is preserved.
2.3. Example of Bidirectional
Text
In this example, lowercase letters stand for inherently left-to-right
characters and uppercase letters represent inherently right-to-left
characters. The text stream is shown in logical backing store order.
Since this is arbitrary XML, the style sheet is responsible for setting
the writing direction. This is the style sheet:
/* Rules for bidi */
HEBREW, HE-QUO {direction: rtl; unicode-bidi: embed;}
ENGLISH {direction: ltr; unicode-bidi: embed;}
/* Rules for presentation */
HEBREW, ENGLISH, PAR {display: block;}
EMPH {font-weight: bold;}
The HEBREW element is a block with a right-to-left base direction, the
ENGLISH element is a block with a left-to-right base direction. The PARs
are blocks that inherit the base direction from their parents. Thus, the
first two PARs are read starting at the top right, the final three are
read starting at the top left. Please note that HEBREW and ENGLISH are
chosen as element names for explicitness only; in general, element names
should convey structure without reference to language.
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 HE-QUO element,
on the other hand, creates an embedding.
The formatting of this text might look like this if the line length is
long:
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.
2.4. Box model for inline
elements in bidirectional context
For each line box, UAs must take the inline boxes generated for each
element and render the margins, borders and padding in visual order (not
logical order).
When the element's ‘direction’ property is ‘ltr’, the left-most generated
box of the first line box in which the element appears has the left
margin, left border and left padding, and the right-most generated box of
the last line box in which the element appears has the right padding,
right border and right margin.
When the element's ‘direction’ property is ‘rtl’, the right-most
generated box of the first line box in which the element appears has the
right padding, right border and right margin, and the left-most generated
box of the last line box in which the element appears has the left margin,
left border and left padding.
3. Introduction to Vertical
Text
In addition to extensions to CSS2.1‘s support for
bidirectional text, this module introduces the rules and properties needed
to support vertical text layout in CSS.
Unlike languages that use the Latin script which are primarily laid out
horizontally, Asian languages such as Chinese and Japanese can be laid out
vertically. The Japanese example below shows the same text laid out
horizontally and vertically. In the horizontal case, text is read from
left to right, top to bottom. For the vertical case, the text is read top
to bottom, right to left. Indentation from the left edge in the
left-to-right horizontal case translates to indentation from the top edge
in the top-to-bottom vertical case.
Comparison of vertical and horizontal Japanese: iBunko
application (iOS)
For Chinese and Japanese lines are ordered either right to
left, while for Mongolian and Manchu left to right.
The change from horizontal to vertical writing can affect not just the
layout, but also the typesetting. For example, the position of a
punctuation mark within its spacing box can change from the horizontal to
the vertical case, and in some cases alternate glyphs are used.
Vertical text that includes Latin script text or text from other scripts
normally displayed horizontally can display that text in a number of ways.
For example, Latin words can be rotated sideways, or each letter can be
oriented upright:
Examples of Latin in vertical Japanese: Daijirin Viewer
1.4 (iOS)
In some special cases such as two-digit numbers in dates, text is fit
compactly into a single vertical character box:
Mac Fan, December 2010, p.49
Layouts often involve a mixture of vertical and horizontal elements:
Mixture of vertical and horizontal elements
Vertical text layouts also need to handle bidirectional text layout;
clockwise-rotated Arabic, for example, is laid out bottom-to-top.
3.1. Block Flow Direction:
the ‘writing-mode’ property
Name:
writing-mode
Value:
horizontal-tb | vertical-rl | vertical-lr
Initial:
horizontal-tb
Applies to:
All elements except table row groups, table column groups, table
rows, and table columns
Inherited:
yes
Percentages:
N/A
Media:
visual
Computed value:
specified value
This property sets the block flow direction. Possible values:
horizontal-tb
Top-to-bottom block flow. The writing mode is horizontal.
vertical-rl
Right-to-left block flow. The writing mode is vertical.
vertical-lr
Left-to-right block flow. The writing mode is vertical.
SVG1.1 [SVG11]
defines some additional values: ‘lr’,
‘lr-tb’, ‘rl’, ‘rl-tb’,
‘tb’, and ‘tb-rl’. These values are deprecated in any
context except SVG1 documents. Implementations that wish to support them
in the context of CSS must treat these values as follows:
SVG1
CSS
lr
horizontal-tb
lr-tb
rl
tb
vertical-rl
tb-rl
In SVG1.1, these values set the inline progression direction, in
other words, the direction the current text position advances each time a
glyph is added. This is a geometric process that happens after bidi reordering, and thus has no effect
on the interpretation of the ‘direction’ property (which is independent
of ‘writing-mode’). (See Relationship
with bidirectionality. [SVG11]) There are varying
interpretations on whether this process causes "writing-mode: rl" to
merely shift the text string or reverse the order of all glyphs in the
text.
See this demo to
check out your implementation's interpretation! (Note that most SVG
implementations don't support the ‘direction’ property, and thus your results
may be skewed on that account. Examine the red line of text: if the
numbers are not in reverse order, your implementation doesn't support
"direction: rtl".)
The ‘writing-mode’ property determines the
direction of block flow. This determines the progression of block-level
boxes in a block formatting context; the progression of line boxes in a
block container that contains inlines; and the progression of rows in a
table. By virtue of determining the stacking direction of line boxes, the
‘writing-mode’ property also determines
whether line boxes and thus the writing mode is horizontal or vertical.
When set on the root element, the ‘writing-mode’ property together with the
‘direction’ property determines the principal writing mode of the document.
This writing mode is used, for example, to determine the default page
progression direction. (See [CSS3PAGE].) The ‘writing-mode’
value of the root element is also propagated to the initial containing
block and sets the block flow direction of the initial block formatting
context.
Note that the ‘writing-mode’ property of the HTML BODY
element is not propagated to the viewport. That special behavior
only applies to the background and overflow properties.
If an element has a different block flow direction than its containing
block:
If the element has a specified ‘display’ of ‘inline’, its ‘display’ computes to ‘inline-block’. [CSS21]
If the element has a specified ‘display’ of ‘run-in’, its ‘display’ computes to ‘block’. [CSS21]
If such an element is a block container, then it establishes a new block
formatting context.
The content of replaced elements do not rotate due to the writing mode:
images, for example, remain upright. However replaced content involving
text (such as MathML content or form elements) should match the replaced
element's writing mode and line orientation if the UA supports such a
vertical writing mode for the replaced content.
In the following example, two blocks elements (1 and 3) separated by an
image (2) are presented in various flow writing modes.
Here is a diagram of horizontal writing mode (writing-mode:
horizontal-tb):
Here is a diagram for the right-to-left vertical writing mode commonly
used in East Asia (writing-mode: vertical-rl):
And finally, here is a diagram for the left-to-right vertical writing
mode used for Manchu and Mongolian (writing-mode:
vertical-lr):
4. Inline-level Alignment
When different kinds of inline-level content are placed together on a
line, the baselines of the content and the settings of the ‘vertical-align’ property control how they are
aligned in the transverse direction of the line box. This section
discusses what baselines are, how to find them, and how they are used
together with the ‘vertical-align’
property to determine the alignment of inline-level content.
4.1. Introduction to
Baselines
This section is non-normative.
A baseline is a line along the inline axis
of a line box along which individual glyphs of text are aligned. Baselines
guide the design of glyphs in a font (for example, the bottom of most
alphabetic glyphs typically align with the alphabetic baseline), and they
guide the alignment of glyphs from different fonts or font sizes when
typesetting.
[Picture of alphabetic text in two font sizes with the
baseline and emboxes indicated.]
Different writing systems prefer different baseline tables.
Preferred baselines in various writing systems
A well-constructed font contains a baseline
table, which indicates the position of one or more baselines within
the font's design coordinate space. (The design coordinate space is scaled
with the font size.)
In a well-designed mixed-script font, the glyphs are
positioned in the coordinate space to harmonize with one another when
typeset together. The baseline table is then constructed to match the
shape of the glyphs, each baseline positioned to match the glyphs from
its preferred scripts.
The baseline table is a property of the font, and the positions of the
various baselines apply to all glyphs in the font.
Different baseline tables can be provided for alignment in horizontal
and vertical text.
4.2. Text Baselines
In this specification, only the following baselines are considered:
alphabetic
The alphabetic baseline, which
typically aligns with the bottom of uppercase Latin glyphs. In horizontal
typographic mode, this is the dominant baseline.
central
The central baseline, which typically
crosses the center of the em box. In vertical typographic mode, this is
the dominant baseline. If the font is missing this baseline, it is
assumed to be halfway between the ascender (over) and descender (under) edges of the em box.
A future CSS module will deal with baselines in more detail
and allow the choice of other dominant baselines and alignment options.
4.2.1. Baselines in
TrueType/OpenType fonts
This section is non-normative.
The alphabetic baseline is listed as the romn baseline in
TrueType/OpenType baseline tables. If missing, it can sometimes be
computed from the ascender and descender metrics. If it cannot be computed
from other metrics, it may be assumed to correspond to the zero
coordinate.
For the ascender and descender metrics, it is recommended to use the
sTypoAscender and sTypoDescender metrics from the
font's OS/2 table. These should match the idtp and
ideo baselines (respectively), which, if present, may be used
instead. In the absence of these metrics, the Ascent and
Descent metrics from the HHEA/VHEA table should be used. The
Win metrics can be used as a fallback; however these are intended as
clipping bounds and are not always appropriate for use as em box
measurements.
4.3. Atomic Inline
Baselines
If an atomic
inline (such as an inline-block, inline-table, or replaced inline
element) is not capable of providing its own baseline information, then
the UA synthesizes a baseline table thus:
alphabetic
The alphabetic baseline is assumed to be at the under margin edge.
central
The central baseline is assumed to be halfway between the under and over margin
edges of the box.
4.4. Baseline Alignment
The dominant baseline is used in CSS for alignment in two cases:
Aligning glyphs from different fonts within the same inline box. The
glyphs are aligned by matching up the positions of the dominant baseline.
Aligning a child inline within its parent. The child is aligned to the
parent by matching the parent's dominant baseline to the same baseline in
the child. (E.g. if the parent's dominant baseline is alphabetic, then
the child's alphabetic baseline is matched to the parent's alphabetic
baseline, even if the child's dominant baseline is something else.)
The baseline tables of the parent (.outer) and the child
(.inner) will not match up due to the font size
difference. Since the dominant baseline is the alphabetic baseline, the
child box is aligned to its parent by matching up their alphabetic
baselines.
Baseline alignment in this fashion is used with the following values
of ‘vertical-align’: ‘baseline’,
‘sub’, ‘super’, <length>, <percentage>. In
the latter cases, the baselines are aligned as for ‘baseline’, but the
child is shifted according to the offset given by its ‘vertical-align’ value.
If we assign ‘vertical-align:
super’ to the .inner element from the example
above, the same rules are used to align the .inner child
to its parent; the only difference is in addition to the baseline
alignment, the child is shifted to the superscript position.
Each writing system has one or more native orientations. Modern scripts
can therefore be classified into three orientational categories:
horizontal-only
Scripts that have horizontal, but not vertical, native orientation.
Includes: Latin, Arabic, Hebrew, Devanagari
vertical-only
Scripts that have vertical, but not horizontal, native orientation.
Includes: Mongolian, Manchu
bi-orientational
Scripts that have both vertical and horizontal native orientation.
Includes: Han, Hangul, Japanese Kana
In modern typographic systems, all glyphs are assigned a horizontal
orientation, which is used when laying out text horizontally. To lay out
vertical text, the UA needs to transform the text from its horizontal
orientation. This transformation is the bi-orientational transform, and there
are two types:
rotate
Rotate the glyph from horizontal to vertical
translate
Translate the glyph from horizontal to vertical
Scripts with a native vertical orientation have an intrinsic
bi-orientational transform, which orients them correctly in vertical text:
CJK (Chinese/Japanese/Korean) characters translate, that is, they are
always upright. Other scripts, such as Mongolian, rotate. (See Appendix A for a list of intrinsic
bi-orientational transforms.)
Scripts without a native vertical orientation can be either rotated (set
sideways) or translated (set upright): the transform used is a stylistic
preference depending on the text's usage, rather than a matter of
correctness. The ‘text-orientation’ property's ‘vertical-right’
and ‘upright’
values are provided to specify rotation vs. translation of horizontal-only
text.
Ideally, punctuation should be either sideways or upright
depending on whether the primary script is horizontal-only or vertical.
However, this information (which, like the base directionality, is a
property of the content) is not available to us. (UTN 22 used the concept
of a vertical directionality, given via ‘direction’ or the HTML dir
attribute to handle this issue.) The current spec works around this by
using the East Asian Width property; but this approach only works if
vertical scripts do not share punctuation with horizontal-only scripts.
all elements except table row groups, rows, column groups, and
columns
Inherited:
yes
Percentages:
N/A
Media:
visual
Computed value:
specified value
This property specifies the orientation of characters within a line and
sets the orientation of the line. Current values only have an effect in
vertical writing modes. Values have the following meanings:
vertical-right
In vertical writing modes, grapheme clusters from horizontal-only
scripts are set sideways, i.e. 90° clockwise from their standard
orientation in horizontal text. Characters from vertical scripts are set
with their intrinsic orientation.
In vertical writing modes, this value puts the element in a
vertical typographic mode and is typical for layout of primarily
vertical-script text.
upright
In vertical writing modes, grapheme clusters from horizonal-only
scripts are rendered upright, i.e. in their standard horizontal
orientation. Shaping characters from such scripts are shaped in their
isolated forms. Characters from vertical scripts are set with their
intrinsic orientation and shaped normally. When available, vertical
glyph variants and vertical font metrics are used to set the text. The
UA must synthesize vertical font metrics for grapheme clusters that do
not have any.
For the purposes of bidi reordering, this value causes all characters
to be treated as strong LTR. This value causes the used value of
‘direction’ to be ‘ltr’.
In vertical writing modes, this value puts the element in a
vertical typographic mode.
rotate-right
In vertical writing modes, this causes text to be set as if in a
horizontal layout (using horizontal glyph variants and metrics), but
rotated 90° clockwise. This value puts the element in a
horizontal typographic mode.
rotate-left
In vertical writing modes, this causes text to be set as if in a
horizontal layout (using horizontal glyph variants and metrics), but
rotated 90° counter-clockwise. This value puts the element in a
horizontal typographic mode.
If set on a non-replaced inline whose parent is not ‘rotate-left’, this
forces ‘isolate’ to be added to the computed value of
‘unicode-bidi’. Layout of text is exactly
as for ‘rotate-right’ except that the text content
and baseline table of each of the element's inline boxes is mirrored
around a vertical axis along the center of its content box. The
positions of text decorations propagated from an ancestor inline
(including the block container's root inline) are not mirrored, but any
text decorations introduced by the element are positioned using the
mirrored baseline table.
Similarly, if an inline child of the element has a ‘text-orientation’ value other than
‘rotate-left’, an analogous transformation is
applied.
rotate-normal
This value is equivalent to ‘rotate-right’ in ‘vertical-rl’
writing mode and equivalent to ‘rotate-left’ in ‘vertical-lr’
writing mode. It can be useful when setting horizontal script text
vertically in a primarily horizontal-only document.
auto
[SVG11] defines
‘glyph-orientation-vertical’ and
‘glyph-orientation-horizontal’
properties that were intended to control text orientation. These
properties are deprecated and do not apply to non-SVG elements.
If an implementation supports these properties, the ‘auto’ value when set on
SVG elements indicates that the SVG ‘glyph-orientation-vertical’ and ‘glyph-orientation-horizontal’ behavior
control the layout of text. Such UAs must set ‘text-orientation: auto’ on all SVG
text content elements in their default UA style sheet for SVG.
In all other contexts, and for implementations that do not support the
glyph orientation properties, the ‘auto’ behavior is the same as for ‘vertical-right’.
text-orientation: vertical-right, upright, rotate-left,
and rotate-right (writing-mode is vertical-rl)
In the following example, the root element of a horizontal-only
document is set to use ‘rotate-normal’. In the rest of the document,
the author can just set ‘writing-mode’ without worrying about
whether the text is ‘vertical-rl’ or ‘vertical-lr’.
In vertical typographic modes, any grapheme clusters belonging to a
vertical script must be set using its base character's intrinsic
orientation. (See Appendix A) Grapheme
clusters belonging to horizontal-only scripts must set sideways (for
‘vertical-right’) or set upright (for ‘upright’) depending on
the ‘text-orientation’ property.
The orientation of characters belonging to the Common, Inherited, and
Unknown script categories may be UA- or font-dependent in vertical
typographic modes. The Unicode East Asian Width property [UAX11] can be used to distinguish
whether a character is typically be set upright or sideways in ‘vertical-right’:
characters classified as fullwidth (F) or wide (W) are typically set
upright (using vertical font settings), whereas characters classified as
neutral (N), narrow (Na) or halfwidth (H) are typically set sideways
(using horizontal font settings).
If the font and font system support mixed-orientation typesetting, the
UA should rely on that feature to set ‘vertical-right’
text. Similarly if the font and font system support upright typesetting
then the UA should rely on that feature to set ‘upright’ text.
If the UA needs to synthesize such features (e.g. if an OpenType font
has only the vert but not the vrt2 feature),
then it should:
for ‘vertical-right’, set all characters with an
East Asian Width of F or W upright (i.e. translated, using vertical font
settings if available), and set sideways the rest (i.e. rotated, using
horizontal font settings).
for ‘upright’, set all characters belonging to the
Mongolian and Phags Pa scripts sideways, and set upright the rest.
Need to define handling of EAW Ambiguous (A) symbols and
punctuation.
Link to definition of grapheme clusters in [UAX29].
Add appendix that describes interaction with OpenType
features and font layout?
6. Abstract Box Terminology
[CSS21] defines
the box layout model of CSS in detail. However, it only defines the box
model for the ‘horizontal-tb’ writing mode. CSS box layout in
writing modes other than ‘horizontal-tb’ is analogous to the box layout
defined in CSS2.1 if directions and dimensions are abstracted and remapped
appropriately. This section defines abstract directional and dimensional
terms and their mappings in order to define box layout for other writing
modes, and to provide terminology for future specs to define their layout
concepts abstractly.
6.1. Logical
Dimensions
block flow dimension
The dimension perpendicular to the flow of text with in a line, the
vertical dimension in horizontal writing modes, and the
horizontal dimension in vertical writing modes.
inline dimension
The dimension parallel to the flow of text within a line, i.e. the
horizontal dimension in horizontal writing modes, and the
vertical dimension in vertical writing modes.
inline-axis
The axis in the block flow dimension, i.e. the vertical axis in
horizontal writing modes and the horizontal axis in vertical
writing modes.
block-axis
The axis in the inline dimension, i.e. the horizontal axis in
horizontal writing modes and the vertical axis in vertical writing
modes.
extent or logical
height
A measurement in the block flow dimension: refers to the physical
height (vertical dimension) in horizontal writing modes, and to the
physical width (horizontal dimension) in vertical writing modes.
measure or logical
width
A measurement in the inline dimension: refers to the physical width
(horizontal dimension) in horizontal writing modes, and to the physical
height (vertical dimension) in vertical writing modes. (The term measure derives from its use in
typography.)
6.2. Abstract and
Physical Directions
The terms left, right, top, and bottom are always interpreted
physically, i.e. with respect to the page independent of writing mode. Two
abstract mappings are possible for these directions: line-relative and
flow-relative, which are defined below.
Although they derive from the behavior of text, these directional terms
exist even for boxes that do not contain any line boxes: they are
calculated directly from the values of the ‘writing-mode’,
‘text-orientation’, and ‘direction’
properties.
6.3. Line-relative
Directions
Although the block flow direction given by ‘writing-mode’
determines whether the line is oriented horizontally or vertically, it
doesn't say anything about how the contents within the line are arranged.
The line orientation determines which
side of the line is the "top" and thus which sides are under (ascender side) and over
(descender side) the line. This determines the interpretation of alignment
in the transverse dimension of the line. It also determines the default
glyph orientation for scripts in a non-native orientation. These
characteristics are controlled by the ‘text-orientation’ property.
In addition to its over and under sides, a line box, even a
vertically-oriented one, also has a "left" and "right" side, which we will
call the line-left and line-right sides of the box (as distinct
from the physical left and physical right sides of the box). The line-left edge of a box is nominally the edge from
which LTR text would start. The line-right edge of a box is nominally the edge from
which RTL text would start. Depending on
the ‘writing-mode’ and ‘text-orientation’ properties, the
line-left side of a box could be on the left, top, or bottom.
Line orientation compass
Typical orientation in vertical
Line orientation with ‘text-orientation: rotate-left’
Note also that while the over and
under directions often map to the same
directions as before and after
respectively, this mapping is reversed for some combinations of ‘writing-mode’
and ‘text-orientation’.
6.4. Flow-relative
Directions
The flow-relative directions are
before, after, start, and end. In an LTR ‘horizontal-tb’ writing mode, they correspond to
the top, bottom, left, and right directions, respectively.
The before edge of a box is nominally the edge that
comes earlier in the block progression, as determined by the ‘writing-mode’
property. Similarly the after edge is the edge that
comes later in the progression.
The start edge of a box is nominally the edge from
which text of its inline base direction will start. For boxes with a used
‘direction’ value of ‘ltr’, this means the line-left edge. For boxes with a used
‘direction’ value of ‘rtl’, this means the line-right edge. The edge opposite the start
edge is the end edge.
<----- width / measure ----->
top side/
before side
+------------------------------+ A
left side/ | ---inline direction ---> | right side/ |
start side | | | end side |
| | block * horizontal * | height/
| | direction *writing mode* | extent
| V | |
+------------------------------+ V
bottom side/
after side
A vertical Japanese block (TTB-RL):
<----- width / extent ------>
top side/
start side
+------------------------------+ A
left side/ | <---block direction--- | right side/ |
after side | | | before side |
| * vertical * inline| | height/
| *writing mode* direction| | measure
| V | |
+------------------------------+ V
bottom side/
end side
6.5.
Abstract-to-Physical Mappings
The following table summarizes the abstract-to-physical mappings:
7.1. Principles of Layout
in Vertical Writing Modes
CSS box layout in vertical writing modes is analogous to layout in the
horizontal writing modes, following the principles outlined below:
Layout calculation rules (such as those in CSS2.1, Section 10.3) that
apply to the horizontal dimension in horizontal writing modes instead
apply to the vertical dimension in vertical writing modes. Likewise,
layout calculation rules (such as those in CSS2.1, Section 10.6) that
apply to the vertical dimension in horizontal writing modes instead apply
to the horizontal dimension in vertical writing modes. Thus:
Layout rules that refer to the width use the height instead, and vice
versa.
Layout rules that refer to the ‘*-left’ and ‘*-right’ box properties (border, margin, padding)
use ‘*-top’ and ‘*-bottom’ instead, and vice versa.
Which side of the box the property applies to doesn't
change: only which values are inputs to which layout calculations
changes. The ‘margin-left’
property still affects the lefthand margin, for example; however in a
‘vertical-rl’ writing mode it takes part in
margin collapsing in place of ‘margin-bottom’.
Layout rules that depend on the ‘direction’ property to choose between
left and right (e.g. overflow, overconstraint resolution, the initial
value for ‘text-align’, table
column ordering) are abstracted to the start and end sides and applied appropriately.
For features such as text alignment, floating, and list marker
positioning, that primarily reference the left or right sides of the line
box or its longitudinal parallels and therefore have no top or bottom
equivalent, the line left and line right sides are used as the reference for the
left and right sides respectively.
Likewise for features such as underlining, overlining, and baseline
alignment (the unfortunately-named ‘vertical-align’), that primarily reference the
top or bottom sides of the linebox or its transversal parallels and
therefore have no left or right equivalent, the over
and under sides are used as the reference for the top
and bottom sides respectively.
The details of these mappings are provided below.
7.2. Dimensional Mapping
Certain properties behave logically as follows:
The first and second values of the ‘border-spacing’ property represent spacing
between columns and rows respectively, not necessarily the horizontal and
vertical spacing respectively. [CSS21]
The ‘line-height’ property
always refers to the logical height. [CSS21]
The height properties (‘height’,
‘min-height’, and ‘max-height’) refer to the physical height, and
the width properties (‘width’,
‘min-width’, and ‘max-width’) refer to the physical width.
However, the rules used to calculate box dimensions and positions are
logical.
For example, the calculation rules in CSS2.1
Section 10.3 are used for the inline dimension measurements: they
apply to the measure (which could be either the physical width or physical
height) and to the the start and end margins, padding, and border.
Likewise the calculation rules in CSS2.1
Section 10.6 are used in the block dimension: they apply to the extent
and to the before and after margins, padding, and border. [CSS21]
As a corollary, percentages on the margin and padding properties, which
are always calculated with respect to the containing block width in
CSS2.1, are calculated with respect to the measure of the containing block in CSS3.
7.3. Orthogonal Flows
When an element has a different ‘writing-mode’ from its containing block
two cases are possible:
The two writing modes are parallel to each other. (For example,
‘vertical-rl’ and ‘vertical-lr’).
The two writing modes are perpendicular to each other. (For example,
‘horizontal-tb’ and ‘vertical-rl’).
To handle the second case, for the purposes of calculating the layout of
the box, the physical dimensions corresponding to the extent and measure
of the containing block are determined using the writing mode of the box
under consideration, not the writing mode of the element associated with
the containing block.
For example, if a vertical block is placed inside a horizontal block,
then when calculating the physical height (which is the measure) of the
child block the physical height of the parent block is used to calculate
the measure of the child's containing block, even though the physical
height is the extent, not the measure, of the parent block.
It is common in CSS for a containing block to have a defined measure,
but not a defined extent. This typically happens in CSS2.1 when a
containing block has an ‘auto’ height, for example: its width is given
by the calculations in 10.3.3, but
its extent depends on its contents. In such cases the available
measure is defined, but the available extent is infinite.
Orthogonal flows allow the opposite to happen: for the available
extent to be defined, but the available measure to be infinite.
In such cases a percentage of the containing block measure cannot be
defined, and thus the initial containing block's measure is used to
calculate such percentages instead. Is this definition
of percentages a good idea?
7.3.1. Auto-sizing in
Orthogonal Flows
If the computed measure of an element establishing an orthogonal flow is
‘auto’, then the
used measure is calculated as the shrink-to-fit (fit-content) value using the initial
containing block's measure as the available size in the shrink-to-fit
algorithm.
As with other shrink-to-fit boxes, the width and height
calculations occur before auto margin calculations in the inline
dimension, and therefore a block box establishing an orthogonal flow, once
sized, can be aligned or centered within its containing block just like
other block-level elements by using auto margins.
7.3.2. Multi-column
Layout in Orthogonal Flows
If the UA supports CSS Multi-column Layout [CSS3COL], then for the case where
the available extent is defined but the available measure is infinite and
the element's measure is unconstrained (is not fixed and has no maximum):
If ‘column-count’ and
‘column-width’ are both ‘auto’, then the
‘column-count’ is assumed to be
‘1’, and the following rules apply.
If the ‘column-width’ is
‘auto’, the column
width is calculated as if the element's containing block were the initial
containing block.
If the column's extent is not defined, the available extent is used to
calculate the column extent by subtracting out the element's margins,
borders, and padding in the block dimension and flooring the result at
zero.
The used column-count then follows from filling the resulting columns
with the element's content.
The used measure of the element is then the max-content measure of the resulting
multi-column element. (If the content neither wraps nor paginates within
the multi-column element, then this will be the intrinsic measure of the
content; else it will be calculated from the used column width, column
count, and column gap.)
The used extent of the element is either the used column extent (if
multiple columns were used) or the intrinsic extent of the content.
This should behave the same as the auto-sizing algorithm
defined in the previous section, except overflowing content, instead of
continuing off the side of the containing block, is wrapped into columns
in the flow direction of the containing block, thus avoiding T-shaped
documents.
7.3.3. Paginating
Orthogonal Flows
This section is informative.
With regards to pagination, the rules in CSS2.1 still hold in vertical
writing modes and orthogonal flows: page break opportunities do not occur
inside line boxes, only between them. Note that UAs that support [CSS3COL] may break
between columns, however. Does CSS3 Multicol specify
this as
requested?
Note that if content spills outside the pagination stream established by
the root element, the UA is not required to print such content. Authors
wishing to mix writing modes with long streams of text are thus encouraged
to use CSS columns to keep all content flowing in the document's
pagination direction.
In other words, if your document would require two scrollbars on the
screen it probably won't all print. Fix your layout, e.g. by using columns so that it all
scrolls (and therefore paginates) in one direction if you want to make
sure it'll all print. T-shaped documents tend not to print well.
7.4.
Flow-Relative Mappings
Flow-relative directions are calculated with respect to the writing mode
of the element and used to abstract layout related to padding and border
properties. For example, if an element had computed values of ‘direction: ltr; writing-mode: vertical-lr; text-orientation:
vertical-right’, ‘padding-top’ would give its start padding, and
‘padding-left’ would give its
before padding.
Flow-relative directions are calculated with respect to the writing mode
of the parent of the element and used to abstract layout related
to the margin properties and the ‘top’, ‘bottom’, ‘left’, and ‘right’ properties. (For the root element,
which has no parent, the values of the writing mode of the element is used
instead.)
The margin
collapsing rules apply exactly with the before margin
substituted for the top margin and the after margin substituted
for the bottom margin. Similarly the padding and border on the same side
as the before margin is substituted for the top padding and border, and
the padding and border on the same side as the after margin for the bottom
padding and border. Note this means only before and after margins ever
collapse.
The parent element is used instead of the containing block,
because the benefit of using the containing block is very rare, but the
cost to implement it is rather high for implementations that do
abstract-physical mapping at cascade time.
The start and end directions are also used for inline layout as follows:
The initial value of the ‘text-align’ property aligns to the start edge
of the line box.
The ‘text-indent’ property
indents from the start edge of the line box.
7.5. Line-Relative Mappings
The line-relative directions are
over, under, line-left, and line-right.
In an LTR ‘horizontal-tb’
writing mode, they correspond to the top, bottom, left, and right
directions, respectively.
The line-right and line-left directions are calculated with respect to
the writing mode of the element and used to interpret the ‘left’ and ‘right’ values of the
following properties:
The line-right and line-left directions are calculated with respect to
the writing mode of the containing block of the element and used
to interpret the ‘left’ and ‘right’ values of the following properties:
The over and under directions are calculated with respect to the writing
mode of the element and used to define the interpretation of the "top"
(over edge) and "bottom" (under edge) of the line box as follows:
For the ‘vertical-align’
property, the "top" of the line box is the over edge; the "bottom" of the
line box is the under edge. Positive length and percentage values shift
the baseline towards the over edge. [CSS21]
For the ‘text-decoration’
property, the underline is drawn on the under side of the text; the
overline is drawn on the over side of the text. [CSS21]Note that
the CSS Text Module defines this in more detail and provides additional
controls for controlling the position of underlines and overlines. [CSS3TEXT]
7.6. Purely Physical
Mappings
The following values are purely physical in their definitions and do not
respond to changes in writing mode:
all values of ‘background-repeat’
the ‘rect()’ notation of the
‘clip’ property [CSS21]
the offsets of the ‘box-shadow’ and ‘text-shadow’ properties
7.7. Table Caption Mappings:
the ‘caption-side’ property
This module introduces two new values to the ‘caption-side’ property: ‘before’ and ‘after’, which position the
caption before and after the table box, respectively. For tables with
‘horizontal-tb’ writing mode, they are
equivalent to the existing ‘top’ and ‘bottom’ values, respectively. [CSS21]
Implementations that support the ‘top’ and ‘bottom’ values of the ‘caption-side’ property but do not support side
captions (i.e. ‘left’ and ‘right’ captions in horizontal writing modes)
must treat ‘top’ and
‘bottom’ as
‘before’, when
the table is in a vertical writing mode.
For implementations that do support side captions (i.e. the ‘left’ and ‘right’ values), this module
also introduces the ‘start’ and ‘end’ values, which behave similarly and which
position the caption on the start and end sides of the table box,
calculated with respect to the writing mode of the table element. For such
implementations, the ‘top’ and ‘bottom’ values must place the caption on the
top and bottom sides of the table box, respectively.
This property allows the combination of multiple characters into the
space of a single character. For text layout purposes, e.g. bidi ordering,
line-breaking, emphasis marks, text-decoration, etc. the resulting
composition is treated as a single glyph representing the Object
Replacement Character U+FFFC. Values have the following meanings:
none
No special processing.
horizontal
In vertical writing mode, attempt to display the text contents of the
element horizontally within the vertical line box, ideally within the
space of one ideographic character (1em square).
The glyphs are stacked horizontally (similar to the contents of an
inline-box with a horizontal writing mode and a line-height of 1em) and
the baseline of the resulting composition chosen such that it is
centered between the content edges of its parent inline box.
The UA should determine how to render the composed glyph into the
space. If the UA has compressed glyphs available for the contents of the
element, then it may use those glyphs to attempt sizing the contents to
1em square. For example, a two digit number may use halfwidth or
proportional glyphs, a three-digit number may use 1/3-em glyphs (if
available, else halfwidth glyphs), etc.
The UA may scale the contents to fit instead, or in addition to the
method above.
In horizontal mode, or if the number of grapheme clusters in the
element exceeds the number specified (if any), this value is equivalent
to ‘none’.
In East Asian documents, the ‘text-combine:
horizontal’ effect is often used to display Latin-based
strings such as components of a date or letters of an initialism, always
in a horizontal writing mode regardless of the writing mode of the line:
In Japanese, this effect is known as tate-chu-yoko.
Some people have requested a way to have numbers
automatically text-combine'd. Maybe a text-auto-combine property? Note
that whether a number should be tate-chu-yoko'd is often
context-sensitive: this would give very weird results when applied to an
arbitrary paragraph.
Acknowledgements
John Daggett, Martin Heijdra, Paul Nelson, Michel Suignard, Steve Zilles
Appendix B: Bidi Rules for HTML
The style sheet rules that would achieve the bidi behaviors specified in
[HTML401] for the
HTML Strict doctype are given below:
This appendix gives the orientational properties of vertical scripts in
[UNICODE]. Any
script not listed explicitly is assumed to be horizontal-only.
Script Name
Transform
Bopomofo
translate
Hiragana
translate
Katakana
translate
Han
translate
Hangul
translate
Mongolian
rotate
Phags Pa
rotate ?
Yi
translate
For the purposes of this specification, all fullwidth characters [UAX11] are treated as
belonging to a vertical script with a translate bi-orientational
transform.
Appendix B: Intrinsic
Sizing
CSS layout has several different concepts of automatic sizing that are
used in various layout calculations. This section defines some more
precise terminology to help connect the layout behaviors of this spec to
the calculations used in other modules.
There are four types of automatically-determined measures in CSS:
min-content
Called the preferred minimum width in CSS2.1§10.3.5
and the minimum content width in CSS2.1§5.2.2,
the min-content measure is defined
roughly as the narrowest measure a box could take while fitting around
its contents if all line break opportunities within the box were
taken.
max-content
Called the preferred width in CSS2.1§10.3.5
and the maximum cell width in CSS2.1§5.2.2,
the max-content measure is defined
roughly as the narrowest measure a box could take while fitting around
its contents if none of the optional line break opportunities
within the box were taken.
fill-available
Called the available width in CSS2.1§10.3.5,
the fill-available measure is
calculated by the rules in CSS2.1§10.3.3
using the available measure as the containing block width. If the
available measure is infinite, then a fallback
measure is used in its place. (In the case of orthogonal flows,
this is the measure of the initial containing block.)
Because they are derived from the content of the element, the min-content and max-content measures are considered to be
types of intrinsic measure.
So far in CSS, there is only one type intrinsic
extent for non-replaced elements: the extent derived from the
content height as defined in CSS2.1§10.6.3.
