Abstract

CSS Writing Modes Level 3 defines CSS 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.
CSS is a language for describing the rendering of structured documents
(such as HTML and XML)
on screen, on paper, in speech, etc.

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 www-style@w3.org (see
instructions) is preferred
for discussion of this specification. When sending e-mail, please put the
text “css-writing-modes” in the subject, preferably like this:
“[…summary of comment…”

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, 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.

1.1
Module Interactions

1.2
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.

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.

User agents that support bidirectional text must apply the Unicode
bidirectional algorithm to every sequence of inline-level boxes uninterrupted
by any block boundary or
“bidi type B”
forced paragraph break.
This sequence forms the paragraph unit
in the bidirectional algorithm.
Additionally, any such sequence forming part or all of the contents of a
bidi-isolated inline element also forms a bidi paragraph.

Two CSS properties, direction and unicode-bidi,
provide explicit embedding, isolation, and override controls in the CSS layer.
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 instead and not
specify CSS rules to override them.

In general, the paragraph embedding level is set according to
the direction property of the paragraph’s containing block
rather than by the heuristic given in steps P2 and P3 of the Unicode algorithm. [UAX9]
When the computed unicode-bidi of the paragraph’s containing block is plaintext,
however, the Unicode heuristics (rules P2 and P3) are used instead.

This property specifies the inline base direction or directionality
of any bidi paragraph, embedding, isolate, or override established by the element.
(See unicode-bidi.) table column layout,
the direction of horizontal overflow,
and the default alignment of text within a line, and other layout effects
that depend on the element’s 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, because the element does not open an additional level
of embedding with respect to the bidirectional algorithm.

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.

Normally (i.e. when unicode-bidi is normal)
an inline element is transparent to the unicode bidi algorithm;
content is ordered as if the element’s boundaries were not there.
Other values of the unicode-bidi property cause inline elements
to create scopes within the algorithm,
and to override the intrinsic directionality of text.

The following informative table summarizes the element-internal and
element-external effects of unicode-bidi:

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 creates a directional embedding
by opening 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

On an inline element, this bidi-isolates its contents.
This is similar to a directional embedding (and increases the embedding level accordingly)
except that each sequence of inline-level boxes
uninterrupted by any block boundary or forced paragraph break
is treated as an isolated sequence:

the content within the sequence is ordered
as if inside an independent paragraph
with the base directionality specified by the element’s direction property.

for the purpose of bidi resolution in its containing bidi paragraph,
the sequence is treated as if it were a single Object Replacement Character (U+FFFC).

In effect, neither is the content inside the element bidi-affected
by the content surrounding the element,
nor is the content surrounding the element bidi-affected by the
content or specified directionality of the element.
However, forced paragraph breaks within the element still create
a corresponding break in the containing paragraph.

In Unicode 6.3 and beyond,
this will correspond to adding an LRI (U+2066), for direction: ltr,
or RLI (U+2067), for direction: rtl, at the start of the element,
and a PDI (U+2069) at the end of the element.

This value has no effect on elements that are not inline.

bidi-override

This value puts the element’s immediate content in a directional override.
For an inline, this means that the element acts like a directional embedding
in the bidirectional algorithm,
except that reordering within it 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.
If the element is a block container,
the override is applied to an anonymous inline element
that surrounds all of its content.

This value behaves as isolate except that for the purposes of
the Unicode bidirectional algorithm, the base directionality of each
of the element’s bidi paragraphs (if a block container)
or isolated sequences (if an inline)
is determined by following the heuristic in rules P2 and P3
of the Unicode bidirectional algorithm
(rather than by using the direction property of the element).

In Unicode 6.3 and beyond, for inline elements
this will correspond to adding an FSI (U+2068) at the start of the element,
and a PDI (U+2069) at the end of the element.

Because the unicode-bidi property does not inherit,
setting bidi-override or plaintext on a block element will
not affect any descendant blocks. Therefore these values are best
used on blocks and inlines that do not contain any block-level
structures.

The final order of characters within 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.

In this process, replaced elements with display: inline
are treated as neutral characters,
unless their unicode-bidi property is either embed or bidi-override,
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.

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 assigned to the end of the element
are added before the interruption and the codes assigned 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.)

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 the display is changed to inline
(see example below).

2.3
Example of Bidirectional Text

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.

The first <section> element is a block with a right-to-left base direction,
the second <section> element is a block with a left-to-right base direction.
The <para>s are blocks that inherit the base direction from their parents.
Thus, the first two <para>s are read starting at the top right,
the final three are read starting at the top left.

The <emphasis> 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 <quote> element, on the other hand,
creates an isolated sequence with the given internal directionality.

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

Since bidi reordering can split apart and reorder text that is
logically contiguous, bidirectional text can cause an inline box
to be split and reordered within a line.

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), anonymous inline boxes may have to be created.

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). The start-most box on the first line box
in which the element appears has the start edge’s margin, border,
and padding; and the end-most box on the last line box in which the
element appears has the end edge’s margin, border, and padding.
For example, in the horizontal-tb writing mode:

When the parent’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 parent’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

This subsection is non-normative.

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.

For Chinese and Japanese lines are ordered either right
to left or top to bottom, while for Mongolian and Manchu lines are
ordered 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:

The writing-mode property specifies the block flow direction,
which determines the progression of block-level boxes in a block formatting
context; the progression of line boxes in a block container that contains
inlines; the progression of rows in a table; etc. By virtue of determining
the stacking direction of line boxes, the writing-mode property also
determines whether the line boxes' orientation (and thus the writing mode)
is horizontal or vertical. The text-orientation property then determines
how text is laid out within the line box.

The principal writing mode of the
document is determined by the writing-mode and direction values
specified on the root element. This writing mode is used, for example,
to determine the default page progression direction. (See [CSS3PAGE].)
Like direction, 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 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 block 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):

In the following example, some form controls are rendered inside
a block with vertical-rl writing mode. The form controls are
rendered to match the writing mode.

In this example, writing-mode sets the list markers upright
using the ::marker pseudo-element. Vertical alignment ensures
that longer numbers will still align with the right of the first
line of text. [CSS3LIST]

The SVG1.1 values were also present in an older revision
of the CSS writing-mode specification, which is obsoleted by this
specification. The additional tb-lr value of that revision is
replaced by vertical-lr.

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.

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. UAs should use the vertical
tables in vertical writing modes and the horizontal tables
otherwise.

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.

central

The central baseline, which typically crosses the center
of the em box. 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.

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
(which can change based on the writing mode)
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 in their corresponding fonts.

Aligning a child inline-level box within its parent.
For the vertical-align value of baseline, 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.)
For values of sub, super, <length>, and
<percentage>, the baselines are aligned as for baseline,
but the child is shifted according to the offset given by its
vertical-align value.

Given following sample markup:

<p><span class="outer">Ap <span class="inner">ji</span></span></p>

And the following style rule:

span.inner { font-size: .75em; }

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.

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.

span.inner { vertical-align: super; font-size: .75em; }

5
Introduction to Vertical Text Layout

Each writing system has one or more native orientations. Modern scripts
can therefore be classified into three orientational categories:

Scripts that have vertical, but not horizontal, native orientation.
Includes: Mongolian, Phags Pa

bi-orientational

Scripts that have both vertical and horizontal native orientation.
Includes: Han, Hangul, Japanese Kana

A vertical script is one that has a native vertical orientation:
i.e. one that is either vertical-only or that is bi-orientational.
A horizontal script is one that has a native horizontal orientation:
i.e. one that is either horizontal-only or that is bi-orientational.
(See Appendix B for a categorization of
scripts by native orientation.)

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: most CJK (Chinese/Japanese/Korean) characters translate,
that is, they are always upright. Characters from other scripts,
such as Mongolian, rotate.

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 mixed and upright values
are provided to specify rotation vs. translation of horizontal-only text.

In vertical writing modes, characters 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.
See Vertical Orientations for further details.

This value is typical for layout of primarily vertical-script text.

upright

In vertical writing modes, characters from horizontal-only
scripts are rendered upright, i.e. in their standard horizontal
orientation.
Characters from vertical scripts are set with their intrinsic orientation
and shaped normally.
See Vertical Orientations for further details.

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.

sideways-right

In vertical writing modes, this causes text to be set as if
in a horizontal layout, but rotated 90° clockwise.

sideways-left

In vertical writing modes, this causes text to be set as if
in a horizontal layout, but rotated 90° counter-clockwise.

If set on a non-replaced inline whose parent is not sideways-left,
this forces bidi isolation: the normal and embed values of
unicode-bidi compute to isolate, and bidi-override computes
to isolate-override.
Layout of text is exactly as for sideways-right except that the
baseline table of each of the element’s inline boxes
is mirrored around a vertical axis along the center of its content box
and text layout is rotated 180° to match.
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 sideways-left, an analogous transformation (and
bidi isolation) is applied.

In the following example, the root element of a horizontal-only document
is set to use sideways. 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.

5.1.1
Vertical Typesetting and Font Features

Are typeset upright with vertical font metrics.
The UA must synthesize vertical font metrics for fonts that lack them.
(This specification does not define heuristics for synthesizing such metrics.)
Additionally, font features (such as alternate glyphs and other transformation)
intended for use in vertical typesetting must be used.
(E.g. the OpenType vert feature must be enabled.)
Furthermore, characters from horizontal cursive scripts (such as Arabic)
are shaped in their isolated forms when typeset upright.

Note that even when typeset "upright",
some glyphs should appear rotated.
For example, dashes and enclosing punctuation
should be oriented relative to the inline axis.
In OpenType, this is typically handled by glyph substitution,
although not all fonts have alternate glyphs for all relevant codepoints.
(East Asian fonts usually provide alternates for East Asian codepoints,
but Western fonts typically lack any vertical typesetting features
and East Asian fonts typically lack vertical substitutions for Western codepoints.)
Unicode published draft data on which characters should appear sideways
as the SVO property in this data file;
however, this property has been abandoned for the current revision of [UTR50].

Characters which are classified as Tr or Tu in [UTR50]
are expected to have alternate glyphs or positioning for typesetting upright in vertical text.
In the case of Trcharacters,
if such vertical alternate glyphs are missing from the font,
the UA may (but is not required to)
fall back to typesetting them sideways
in order to synthesize the missing glyphs.

There is an ongoing discussion of whether UAs should be allowed, required, or forbidden from synthesizing vertical alternate glyphs for Tr codepoints.

sideways characters

Are typeset rotated 90° sideways with horizontal metrics,
and vertical typesetting features are not used.
However, if the font has features meant to be enabled
for sideways text that is typeset in vertical lines
(e.g. to adjust brush stroke angles or alignment),
those features are used.

All text in sideways, sideways-right, and sideways-left orientations is
typeset using horizontal font metrics and the normal set of features
used for horizontal text runs.
Vertical metrics, vertical glyph variations, and any other features meant
for text typeset in vertical lines are not used.

The OpenType vrt2 feature, which is intended for mixed-orientation typesetting,
is not used by CSS.
It delegates the responsibility for orienting glyphs to the font designer.
CSS instead dictates the orientation through [UTR50]
and orients glyphs by typesetting them sideways or upright as appropriate.

6
Abstract Box Terminology

CSS2.1 [CSS21] defines the box layout model of CSS in detail,
but only for the horizontal-tb writing mode. Layout is analogous
in writing modes other than horizontal-tb; however directional
and dimensional terms in CSS2.1 must be 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. (The next section explains how to apply them to
CSS2.1 layout calculations and how to handle
orthogonal flows.)
Although they derive from the behavior of text, these abstract
mappings 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.

There are three sets of directional terms in CSS:

physical

Interpreted relative to the page, independent of writing mode.
The physical directions are left, right, top, and
bottom.

The physical dimensions are width and height,
which correspond to measurements along the x-axis
(vertical dimension) and y-axis (horizontal dimension),
respectively. Abstract dimensions
are identical in both flow-relative and line-relative terms, so there
is only one set of these terms.

A measurement in the block 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
Flow-relative Directions

The flow-relative directions,
block-start, block-end, inline-start, and inline-end,
are defined relative to the flow of content on the page.
In an LTRhorizontal-tb writing mode, they correspond to the
top, bottom, left, and right directions, respectively.
They are defined as follows:

Nominally the side from which text of its inline base direction will start.
For boxes with a used direction value of ltr, this means the line-left side.
For boxes with a used direction value of rtl, this means the line-right side.

6.3
Line-relative Directions

The line orientation determines which side of a line
box is the logical “top” (ascender side). It is given by a combination
of text-orientation and writing-mode. Usually the line-relative “top”
corresponds to the block-start side, but this is not always the case:
in Mongolian typesetting (and thus by default in vertical-lr writing
modes), the line-relative “top” corresponds to the block-end side.
Hence the need for distinct terminology.

A primarily Mongolian document, such as the one above, is written in
vertical lines stacking left to right, but lays its Latin text with
the tops of the glyphs towards the right. This makes the text run in
the same inline direction as Mongolian (top-to-bottom) and face the
same direction it does in other East Asian layouts (which have vertical
lines stacking right to left), but the glyphs' tops are facing the
bottom of the line stack rather than the top, which in an English
paragraph would be upside-down. (See this
Diagram of Mongolian
Text Layout.)

In addition to a line-relative “top” and “bottom” to map things like
'vertical-align: top', CSS also needs to refer to a line-relative
“left” and “right” in order to map things like text-align: left.
Thus there are four line-relative directions, which are
defined relative to the line orientation as follows:

over

Nominally the side that corresponds to the ascender side or “top”
side of a line box. (The side overlines are typically drawn on.)

under

Opposite of over: the line-relative “bottom” or descender side.
(The side underlines are typically drawn on.)

line-left

Nominally the side from which LTR
text would start.

line-right

Nominally the side from which RTL
text would start. (Opposite of line-left.)

See the table below for the exact
mappings between physical and line-relative directions.

7
Abstract Box Layout

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 example, in vertical writing modes,
table rows are vertical and table columns are horizontal.
In a vertical-rlmixedrtl table,
the first column would be on the bottom (the inline-start side),
and the first row on the right (the block-start side).
The table’s margin-right and margin-left would collapse
with margins before (on the right) and after (on the left) the table, respectively,
and if the table had auto values for margin-top and margin-bottom
it would be centered vertically within its block flow.

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 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.

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:

When an element has a writing mode that is perpendicular to its containing block
it is said to be in, or establish, an orthogonal flow.

To handle this case, CSS layout calculations are divided into
two phases: sizing a box, and positioning the box within its flow.

In the sizing phase—calculating the width and height of the
box—the dimensions of the box and the containing block
are mapped to the measure and extent and calculations are performed
accordingly using the writing mode of the element.

In the positioning phase—calculating the positioning offsets,
margins, borders, and padding—the dimensions of the box and
its containing block are mapped to the measure and extent and
calculations are performed according to the writing mode of the
containing block.

Since auto margins are resolved consistent with the containing
block’s writing mode, a box establishing an orthogonal flow can,
once sized, be aligned or centered within its containing block just
like other block-level elements by using auto margins.

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 as the child’s containing block measure, even
though the physical height is the extent, not the measure, of
the parent block.

On the other hand,
because the containing block is in a horizontal writing mode,
the vertical margins on the child participate in margin-collapsing,
even though they are in the inline-axis of the child,
and horizontal auto margins will expand to fill the containing block,
even though they are in the block-axis of the child.

Add a picture.

7.3.1
Auto-sizing in Orthogonal Flows

It is common in CSS for a containing block to have a definite
measure, but not a definite 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 as the measure of the
containing block; but the available extent, which
would otherwise be the extent of the containing block, is
infinite.

Putting a box in an orthogonal flow allows the opposite to happen:
for the available extent to be defined, but the available
measure to be indefinite. In such cases a percentage of the
containing block measure cannot be defined, and inline-axis
computations cannot be resolved. In these cases, the initial
containing block’s size is used as a fallback variable
in place of the available measure for calculations that
require a definite available measure.

This section needs careful review for whether it is a) correct and b) sensible.

7.3.2
Auto-measure formula for orthogonal flows

If the UA does not support CSS Multi-column Layout [CSS3COL]
and the element is a block container,
when the computed measure of the element establishing an orthogonal flow is auto,
then the used inner measure is calculated as:

7.3.3
Automatic Multi-column Layout in Orthogonal Flows

If the UA supports CSS Multi-column Layout [CSS3COL]
and the element is a block container or multi-column element,
for the case where the element’s extent or available extent is
definite but the element’s measure is auto:

The used column-count then follows from filling the resulting columns with the element’s content.

The used measure of the resulting multi-column element is then calculated:
if the content neither line-wraps nor fragments within the multi-column element,
then the used measure is the max-content measure of the element’s contents;
else it is 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 max-content 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.4
Auto-sizing Orthogonal Flows

In order to limit the length of lines,
block containers have special auto-sizing behavior
when their available measure is infinite
(which typically occurs when they establish an orthogonal flow).

Other layout models simply shrink-wrap (as floats do) into the infinite available measure;
but pass through the infinite limit to block containers they contain:

A table or flex container establishing an orthogonal flow is laid out into the given available space.
If the available measure is infinite, this effectively lays the element out at its max-content size.
However, any table cells or flex items that are block containers are laid out assuming infinite available space
and so behave accordingly, possibly limiting their measure to the size of the initial containing block
or triggering multi-column layout so that they grow in the direction of the infinite measure.

7.3.5
Fragmenting Orthogonal Flows

This section is informative.

With regards to fragmentation, the rules in CSS2.1 still hold in
vertical writing modes and orthogonal flows: break opportunities
do not occur inside line boxes, only between them.
UAs that support [CSS3COL] may break in the (potentially zero-width)
gap between columns, however.

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 containing block of the
element and used to abstract layout rules related to the
box properties (margins, borders, padding) and any properties
related to positioning the box within its containing block
(float, clear, top, bottom, left, right)
For inline-level elements, the writing mode of the parent
element is used instead.

For example, the margin that is dropped when a box’s inline
dimension is
over-constrained
is the end margin as determined by the writing mode of the
containing block.

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:

This module introduces two new values to the caption-side property:
block-start and block-end,
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]

For implementations that support the top-outside
and bottom-outside model, corresponding start-outside and
end-outside are similarly introduced.

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 both top and bottom as block-start,
when the table is in a vertical writing mode.

For implementations that do support side captions
(i.e. the left and right values from the obsolete CSS 2.0 specification [CSS2]),
this module also introduces the inline-start and inline-end values,
which behave similarly and which position the
caption on the inline-start and inline-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.

The CSS2.0 side caption model had some
problems
and will likely have a different definition in CSS3.

8
Page Flow: the page progression direction

In paged media CSS2.1 classifies all pages as either left or right pages.
The page progression direction, which determines whether the left or right
page in a spread is first in the flow and whether the first page is by
default a left or right page, depends on the writing direction as follows:

The WG would appreciate a better (more obvious + easier to type) name for this, if anyone can come up with one.

This property specifies the combination of multiple characters into the space of a single character.
If the combined text is wider than 1em, the UA must fit the contents within 1em, see below.
The resulting composition is treated as a single upright glyph for the purposes of layout and decoration.
This property only has an effect in vertical writing modes. Values have the following meanings:

none

No special processing.

all

Attempt to typeset horizontally
all consecutive characters within the element
such that they take up the space of a single character
within the vertical line box.

digits <integer>?

Attempt to typeset horizontally
each maximal sequence of consecutive ASCII digits (U+0030–U+0039)
that has as many or fewer characters than the specified integer
such that it takes up the space of a single character
within the vertical line box.
If the integer is omitted, it computes to 2.
Integers outside the range 2-4 are invalid.

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:

Example of horizontal-in-vertical tate-chu-yoko

The figure is the result of the rules

and the following markup:

In Japanese, this effect is known as tate-chu-yoko.

The following example shows that applying text-combine-horizontal: digits 2
to an entire document, rather than to a segment with a known type of
numeric content, can have unintended consequences:

<p>あれは10,000円ですよ！</p>

Example of mis-applied tate-chu-yoko

9.1.1
Text Run Rules

To avoid complexity in the rendering and layout,
text-combine-horizontal can only combine plain text:
consecutive characters that are not interrupted by an element boundary.

However, because the property inherits,
the UA must ensure that the contents of the element effecting the combination
are not part of an otherwise-combinable sequence
that happens to begin or end outside the element;
if so, then the text is laid out normally, as if text-combine-horizontal were none.
To avoid combining only part of a sequence:
if the boundary of a potentially-combinable run
is due only to one or more inline element boundaries,
the UA must inspect any characters that appear
immediately before and immediately after the run,
and if these characters would, without the intervening element,
form a sequence that would (if it were not too long) combine,
then the candidate run does not combine.

The above paragraph is at-risk. Comments from implementors are welcome.

For example, given the rule

tcy { text-combine-horizontal: digits 4; }

if the following markup were given:

<tcy>12<span>34</span></tcy>

no text would combine: the 12 and 34 both share an ancestor with the same text-combine-horizontal value,
and therefore are considered part of a sequence of four combinable digits interrupted by an element boundary.
However in these cases:

The 34 would combine, because the 12 immediately previous does not share with the 34 an ancestor with a common text-combine-horizontal,
and therefore the 34 is considered to be the entirety of a sequence of two combinable digits.

If we used the rule

tcy { text-combine-horizontal: all; }

the same results would occur:
the first case not combining because 1234 forms a sequence of four combinable characters interrupted by an element boundary,
and the second combining 34 because it forms the entirety of a sequence of two combinable characters.

Note that the value of text-combine-horizontal (all or digits)
only affects which types of characters can be combined
and what is the maximum length of a combinable sequence.
It does not otherwise change behavior.

9.1.2
Layout Rules

When combining text as for text-combine-horizontal: all,
the glyphs of the combined text are composed horizontally
(ignoring letter-spacing and any forced line breaks, but using the specified font settings),
similar to the contents of an inline-box with a horizontal writing mode and a line-height of 1em.
The effective size of the composition is assumed to be 1em square;
anything outside the square is not measured for layout purposes.
The UA should center the glyphs horizontally and vertically within the measured 1em square.

The baseline of the resulting composition must be chosen such that the square is centered
between the text-over and text-under baselines of its parent inline box prior to any baseline alignment shift (vertical-align).
For bidi reordering, the composition is treated the same as a character with text-orientation: upright.
For line breaking before and after the composition, it is treated as a regular inline with its actual contents.
For other text layout purposes,
e.g. emphasis marks, text-decoration, spacing,
etc. the resulting composition is treated as a single glyph
representing the Object Replacement Character U+FFFC.

9.1.3
Compression Rules

The UA must ensure that the combined advance width of the composition
fits within 1em by compressing the combined text if necessary.
(This does not necessarily mean that the glyphs will fit within 1em,
as some glyphs are designed to draw outside their geometric boundaries.)
OpenType implementations must use width-specific variants
(OpenType features hwid/twid/qwid)
to compress text
in cases where those variants are available for all characters in the composition.
Otherwise, the UA may use any means to compress the text,
including substituting half-width, third-width, and/or quarter-width glyphs provided by the font,
using other font features designed to compress text horizontally,
scaling the text geometrically,
or any combination thereof.

For example, a simple OpenType-based implementation might compress the text as follows:

Horizontally scale the result to 1em if it is not yet 1em or narrower.

A different implementation that utilizes OpenType layout features
might compose the text first with normal glyphs to see if that fits,
then substitute in half-width or third-width forms as available and necessary,
possibly adjusting its approach or combining it with scaling operations
depending on the available glyph substitutions.

In some fonts, the ideographic glyphs are given a compressed design
such that they are 1em wide but shorter than 1em tall.
To accommodate such fonts, the UA may vertically scale the the composition
to match the advance height of 水 U+6C34.

9.1.3.1
Full-width Characters

In order to preserve typographic color when compressing the text to 1em,
when the combined text consists of more than one character,
then any full-width characters must first be converted to their non-full-width equivalents
by reversing the algorithm defined for text-transform: full-width in [CSS3TEXT]
before applying other compression techniques.

The "2010" is too long to be combined (4 digits), but the "2" and "23" will be affected.
Since "23" is more than one character, it will not be affected by text-transform: full-width.
However since the "2" is only one character, it will be transformed to a fullwidth "２".
Since the "2010" was not combined, its digits, too, will be transformed to fullwidth "２０１０";
and being fullwidth, they will be typeset upright, giving the following result:

Properties that affect glyph selection,
such as the font-variant and font-feature-settings properties defined in [CSS3-FONTS],
can potentially affect the selection of variants for characters included in combined text runs.
Authors are advised to use these properties with care when text-combine-horizontal is also used.

Defined in [UTR50] as the Vertical_Orientation property
and given in the UTR50 data file.

In several sections (as noted), the term
character is defined as extended grapheme cluster
per [UAX29]. It is roughly equivalent to what a language user
considers to be a character or a basic unit of the script (which
might not be a single Unicode codepoint).
The UA may further tailor this definition as appropriate to match
typographic convention. For example, when typesetting upright,
Tibetan tsek and shad marks are kept with the preceding letters,
rather than treated as an independent cluster.

Appendix B: Bidi Rules for HTML 4

The style sheet rules that would achieve the bidi behaviors specified
in [HTML401] for the HTML Strict doctype are given below:

Appendix C:
Vertical Scripts in Unicode

This section is informative.

This appendix lists the vertical and bi-orientational scripts in Unicode 6.0
[UNICODE] and their transformation from horizontal to vertical orientation.
Any script not listed explicitly is assumed to be horizontal-only.
The script classification of Unicode characters is given by [UAX24].

Vertical Scripts in Unicode

Code

Name

Transform (Clockwise)

Vertical Intrinsic Direction

Bopo

Bopomofo

0°

ttb

Egyp

Egyptian Hieroglyphs

0°

ttb

Hira

Hiragana

0°

ttb

Kana

Katakana

0°

ttb

Hani

Han

0°

ttb

Hang

Hangul

0°

ttb

Merc

Meroitic Cursive

0°

ttb

Mero

Meroitic Hieroglyphs

0°

ttb

Mong

Mongolian

90°

ttb

Ogam

Ogham

-90°

btt

Orkh

Old Turkic

-90°

ttb

Phag

Phags Pa

90°

ttb

Yiii

Yi

0°

ttb

Exceptions:
For the purposes of this specification, all fullwidth (F) and wide (W) characters
are treated as belonging to a vertical script,
and halfwidth characters (H) are treated as belonging ot a horizontal script.
[UAX11]

CSS3 Writing Modes cannot correctly handle either Ogham or Old Turkic.
It is recommended that text-orientation: sideways-left be used to typeset these scripts.
A future version of CSS may define automatic handling of these scripts.

Note that for vertical-only characters (such as Mongolian and Phags Pa letters),
the glyphs in the Unicode code charts are shown in their vertical orientation.
In horizontal text, they are typeset in a 90° counter-clockwise
rotation from this orientation.

Conformance

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.

Conformance classes

Conformance to this specification
is defined for three conformance classes:

A style sheet is conformant to this specification
if all of its statements that use syntax defined in this module are valid
according to the generic CSS grammar and the individual grammars of each
feature defined in this module.

A renderer is conformant to this specification
if, in addition to interpreting the style sheet as defined by the
appropriate specifications, it supports all the features defined
by this specification by parsing them correctly
and rendering the document accordingly. However, the inability of a
UA to correctly render a document due to limitations of the device
does not make the UA non-conformant. (For example, a UA is not
required to render color on a monochrome monitor.)

An authoring tool is conformant to this specification
if it writes style sheets that are syntactically correct according to the
generic CSS grammar and the individual grammars of each feature in
this module, and meet all other conformance requirements of style sheets
as described in this module.

Partial implementations

So that authors can exploit the forward-compatible parsing rules to
assign fallback values, CSS renderers must
treat as invalid (and ignore
as appropriate) any at-rules, properties, property values, keywords,
and other syntactic constructs for which they have no usable level of
support. In particular, user agents must not selectively
ignore unsupported component values and honor supported values in a single
multi-value property declaration: if any value is considered invalid
(as unsupported values must be), CSS requires that the entire declaration
be ignored.

Experimental implementations

To avoid clashes with future CSS features, the CSS2.1 specification
reserves a prefixed
syntax for proprietary and experimental extensions to CSS.

Prior to a specification reaching the Candidate Recommendation stage
in the W3C process, all implementations of a CSS feature are considered
experimental. The CSS Working Group recommends that implementations
use a vendor-prefixed syntax for such features, including those in
W3C Working Drafts. This avoids incompatibilities with future changes
in the draft.

Non-experimental implementations

Once a specification reaches the Candidate Recommendation stage,
non-experimental implementations are possible, and implementors should
release an unprefixed implementation of any CR-level feature they
can demonstrate to be correctly implemented according to spec.

To establish and maintain the interoperability of CSS across
implementations, the CSS Working Group requests that non-experimental
CSS renderers submit an implementation report (and, if necessary, the
testcases used for that implementation report) to the W3C before
releasing an unprefixed implementation of any CSS features. Testcases
submitted to W3C are subject to review and correction by the CSS
Working Group.