Latin-based writing mode
Mongolian-based writing mode
Han-based writing modes
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 a box 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.
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, ora 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.
Ahorizontal 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.
The typographic mode determines whether to use
typographic conventions specific to vertical flow for vertical scripts (vertical typographic mode)
or to use the typographic conventions of horizontal writing modes (horizontal typographic mode).
This concept distinguishes vertical typesetting
from rotated horizontal typesetting.
The text-orientation component of the writing mode
controls the glyph orientationinvertical typographic modes,
dictating whether a particular typographic character unitistypeset uprightortypeset sideways.
See Unicode Technical Note #22 [UTN22] (HTML version)
for a more in-depth introduction to writing modes and vertical text.
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.
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.
The HTML specifications ([HTML401], section 8.2, and HTML § 15.3.5 Bidirectional text) define
bidirectionality behavior for HTML elements.
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.
| Name: | direction |
|---|---|
| Value: | ltr | rtl |
| Initial: | ltr |
| Applies to: | all elements |
| Inherited: | yes |
| Percentages: | n/a |
| Computed value: | specified value |
| Canonical order: | n/a |
| Animation type: | not animatable |
dir attribute and <bdo> element to ensure correct bidirectional layout in the absence of a style sheet. Authors should not use direction in HTML documents.
This property specifies the inline base direction or directionality
of any bidi paragraph, embedding, isolate, or override established by the box.
(See unicode-bidi.)
In addition, it informs the ordering of 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 box’s inline base direction.
Values for this property have the following meanings:
ltr
This value sets inline base direction (bidi directionality)
to line-left-to-line-right.
rtl
This value sets inline base direction (bidi directionality)
to line-right-to-line-left.
The direction property has no effect on bidi reordering
when specified on inline boxes whose unicode-bidi value is normal,
because the box does not open an additional level
of embedding with respect to the bidirectional algorithm.
The direction property, when specified for table column boxes, 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.
| Name: | unicode-bidi |
|---|---|
| Value: | normal | embed | isolate | bidi-override | isolate-override | plaintext |
| Initial: | normal |
| Applies to: | all elements, but see prose |
| Inherited: | no |
| Percentages: | n/a |
| Computed value: | specified value |
| Canonical order: | per grammar |
| Animation type: | not animatable |
dir attribute, <bdo> element,
and appropriate distinction of text-level vs. grouping-level HTML element types to ensure correct bidirectional layout in the absence of a style sheet. Authors should not use unicode-bidi in HTML documents.
Normally (i.e. when unicode-bidiisnormal)
an inline box is transparent to the unicode bidi algorithm;
content is ordered as if the box’s boundaries were not there.
Other values of the unicode-bidi property cause inline boxes
to create scopes within the algorithm,
and to override the intrinsic directionality of text.
The following informative table summarizes the box-internal and
box-external effects of unicode-bidi:
| Outside | |||
|---|---|---|---|
| strong | neutral | ||
| Inside | scoped | embed | isolate |
| override | bidi-override | isolate-override | |
| plaintext | — | plaintext | |
| unicode-bidi value | direction value | |||
|---|---|---|---|---|
| ltr | rtl | |||
| start | end | start | end | |
| normal | — | — | — | — |
| embed | LRE (U+202A) | PDF (U+202C) | RLE (U+202B) | PDF (U+202C) |
| isolate | LRI (U+2066) | PDI (U+2069) | RLI (U+2067) | PDI (U+2069) |
| bidi-override* | LRO (U+202D) | PDF (U+202C) | RLO (U+202E) | PDF (U+202C) |
| isolate-override* | FSI,LRO (U+2068,U+202D) | PDF,PDI (U+202C,U+2069) | FSI,RLO (U+2068,U+202E) | PDF,PDI (U+202C,U+2069) |
| plaintext | FSI (U+2068) | PDI (U+2069) | FSI (U+2068) | PDI (U+2069) |
| * The LRO/RLO+PDF pairs are also applied to the root inline box of a block container if these values of unicode-bidi were specified on the block container. | ||||
<section dir=rtl> <para>HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5</para> <para>HEBREW6 <emphasis>HEBREW7</emphasis> HEBREW8</para> </section> <section dir=ltr> <para>english9 english10 english11 HEBREW12 HEBREW13</para> <para>english14 english15 english16</para> <para>english17 <quote dir=rtl>HEBREW18 english19 HEBREW20</quote></para> </section>Since this is arbitrary XML, the style sheet is responsible for setting the writing direction. This is the style sheet:
/* Rules for bidi */
[dir=rtl] {direction: rtl; unicode-bidi: isolate; }
[dir=ltr] {direction: ltr; unicode-bidi: isolate; }
/* Rules for presentation */
section, para {display: block;}
emphasis {font-weight: bold;}
quote {font-style: italic;}
If the line length is long,
the formatting of this text might look like this:
5WERBEH 4WERBEH english3 2WERBEH 1WERBEH
8WERBEH 7WERBEH 6WERBEH
english9 english10 english11 13WERBEH 12WERBEH
english14 english15 english16
english17 20WERBEH english19 18WERBEH
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-bidiisnormal (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.
Note that this causes HEBREW18 to be to the right of english19.
If lines have to be broken, the same text might format like this:
2WERBEH 1WERBEH
-EH 4WERBEH english3
5WERB
-EH 7WERBEH 6WERBEH
8WERB
english9 english10 en-
glish11 12WERBEH
13WERBEH
english14 english15
english16
english17 18WERBEH
20WERBEH english19
Notice that 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.
<para>...<i1><i2>...<BR/>...</i2></i1>...</para>and
<para>...<i1><i2>...</i2></i1><BR/><i1><i2>...</i2></i1>...</para>for all values of unicode-bidi on inline elements <i1> and <i2>. Note that this behavior is applied by CSS for CSS-declared bidi controls applied to the box tree; it does not apply to Unicode’s bidi formatting controls, which are defined to terminate their effect at the end of the bidi paragraph.
Comparison of vertical and horizontal Japanese: iBunko application (iOS)
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:
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.
| 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, table columns, ruby base containers, ruby annotation containers |
| Inherited: | yes |
| Percentages: | n/a |
| Computed value: | specified value |
| Canonical order: | n/a |
| Animation type: | not animatable |
<iframe>s, for example, remain upright,
and the default object size of 300px×150px does not re-orient.
However embedded 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.
<style>
form { writing-mode: vertical-rl; }
</style>
...
<form>
<p><label>姓名 <input value="艾俐俐"></label>
<p><label>语言 <select><option>English
<option>français
<option>فارسی
<option>中文
<option>日本語</select></label>
</form>
If a box has a different writing-mode value than its parent box
(i.e. nearest ancestor without display: contents):
●If the box would otherwise become an in-flow box
with a computed displayofinline,
its display computes instead to inline-block.
●If the box is a block container,
then it establishes an independent block formatting context.
●More generally, if its specified inner display typeisflow,
then its computed inner display type becomes flow-root. [CSS-DISPLAY-3]
As all other inherited CSS properties do,
the writing-mode property inherits to SVG elements inlined
(rather than linked) into the source document.
This could cause unintentional side effects when, for example,
an SVG image designed only for horizontal flow was embedded into a vertical flow document.
Authors can prevent this from happening by adding the following rule:
svg { writing-mode: initial; }
| Specified | Computed |
|---|---|
| lr | horizontal-tb |
| lr-tb | |
| rl | |
| rl-tb | |
| tb | vertical-rl |
| tb-rl |
Authors who wish to create forwards and backwards-compatible SVG content in CSS syntax can use the CSS forwards-compatible parsing rules to do so, e.g.@namespace svg"http://www.w3.org/2000/svg" ; svg|*[ writing-mode=lr], svg|*[ writing-mode=lr-tb], svg|*[ writing-mode=rl], svg|*[ writing-mode=rl-tb] { writing-mode : horizontal-tb; } svg|*[ writing-mode=tb], svg|*[ writing-mode=tb-rl] { writing-mode : vertical-rl; }
svg|text { writing-mode: tb; writing-mode: vertical-rl; }
Alphabetic text in two font sizes with the baseline and em-boxes
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 typographic modes and the horizontal tables
otherwise.
<p><span class="outer">Ap <span class="inner">ਜੀ</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; }
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.
| Name: | text-orientation |
|---|---|
| Value: | mixed | upright | sideways |
| Initial: | mixed |
| Applies to: | all elements except table row groups, rows, column groups, and columns |
| Inherited: | yes |
| Percentages: | n/a |
| Computed value: | specified value |
| Canonical order: | n/a |
| Animation type: | not animatable |
.vertical-upright-hebrew {
writing-mode: vertical-rl;
text-orientation: upright;
unicode-bidi: bidi-override;
direction: ltr;
}
TrorTuin[UAX50] 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 wish to [RFC6919] (but is not expected to)
synthesize the missing glyphs by typesetting them sideways etc.
sideways typesetting
Typographic character units typeset as a run
rotated 90° clockwise from their upright orientation,
using horizontal metrics and composition,
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.
(An example of such a feature would be the proposed vrtr OpenType font feature.)
Vertical_Orientation property
for the default glyph orientation of mixed-orientation vertical text.
When text-orientationismixed,
the UA must determine the orientation of each typographic character unit by its Vertical_Orientation property: typesetting it upright if its orientation property is U, Tu, or Tr;
or typesetting it sideways (90° clockwise from horizontal)
if its orientation property is R.
Note that UAX50 does not handle scripts that rotate -90° in vertical contexts,
so they will not be typeset correctly with mixed orientation.
The sideways-lr value in Level 4, however,
can correctly display such scripts.
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 [UAX50] and orients glyphs by typesetting them sideways or upright as appropriate.
| Name: | glyph-orientation-vertical |
|---|---|
| Value: | auto | 0deg | 90deg | 0 |90 |
| Initial: | n/a |
| Applies to: | n/a |
| Inherited: | n/a |
| Percentages: | n/a |
| Computed value: | n/a |
| Canonical order: | n/a |
| Animation type: | n/a |
| Shorthand glyph-orientation-vertical value | Longhand text-orientation value |
|---|---|
| auto | mixed |
| 0deg | upright |
| 0 | upright |
| 90deg | sideways |
| 90 | sideways |
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:
overorline-over
Nominally the side that corresponds to the ascender side or “top”
side of a line box. (The side overlines are typically drawn on.)
underorline-under
Opposite of over: the line-relative “bottom” or descender side.
(The side underlines are typically drawn on.)
line-left
The line-relative "left" side of a line box,
which is nominally the side from which LTR text would start.
line-right
The line-relative "right" side of a line box,
which is 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.
Line orientation in horizontal-tb
Line orientation in vertical-rl and vertical-lr
Vertical baseline of an upright glyph
When text-orientation: upright,
the baseline is still vertical,
and the vertical baseline in the font is used,
or the vertical baseline is synthesized if the font does not provide.
Since the baseline is vertical,
the definitions for mixedorsideways above still apply; i.e., line-over is on right, and line-under is on left.
This is in line with font systems such as OpenType which
defines the ascender on right and
the descender on left in their vertical metrics.
| writing-mode | horizontal-tb | vertical-rl | vertical-lr | |||
|---|---|---|---|---|---|---|
| direction | ltr | rtl | ltr | rtl | ltr | rtl |
| block-size | height | width | ||||
| inline-size | width | height | ||||
| block-start | top | right | left | |||
| block-end | bottom | left | right | |||
| inline-start | left | right | top | bottom | top | bottom |
| inline-end | right | left | bottom | top | bottom | top |
| over | top | right | ||||
| under | bottom | left | ||||
| line-left | left | top | ||||
| line-right | right | bottom | ||||
Table in vertical-rl RTL writing mode
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 line-over and line-under sides are used as the reference for the
top and bottom sides respectively.
The details of these mappings are provided below.
An example of orthogonal flow
For example, if a vertical block is placed inside a horizontal block,
then when calculating the physical height (which is the inline size)
of the child block the physical height of the parent block is used
as the child’s containing block inline size,
even though the physical height is the block size, not the inline size,
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.
Note that this section requires that
when a child box auto-sized in its block axis
establishes an orthogonal flow,
the used block size of the child
is calculated to fit its content;
and this resulting content-based size
is used as input to the inline-axis min-content size and max-content size of the parent.
This means that when applying shrink-to-fit formula to a box
such as an inline-block, float, or table-cell,
if its child establishes an orthogonal flow,
the calculation dependency must be changed so that
the sizing phase of the child runs first and
its used block size becomes an input to the inline-size shrink-to-fit formula of the parent.
min(max-content inline size, max(min-content inline size, stretch-fit inline size),
where the available space used to calculate the stretch-fit inline size is
either the size of the containing block if that is definite,
or else the fallback size as defined above.
The automatic sizing of orthogonal multi-column containers (in both axes)
and of other display types not mentioned above
is not defined in this specification.
Note: See also CSS Writing Modes Level 4.
body child element [HTML]
whose display value is not none
,
the used value of the of writing-mode and direction properties on root element
are taken
from the computed writing-mode and direction of the first such child element instead of from the root element’s own values.
The UA may also propagate the value of text-orientation in this manner.
Note that this does not affect the computed values of writing-mode, direction, or text-orientation of the root element itself.
Note: Using containment disables
this special handling of the HTML body element.
See the CSS Containment 1 § 2 Strong Containment: the contain property for details.
Candidate Correction 1: Specify that the body element is ignored for determining the principal writing mode if it has display: none. Issue 3779
Note: Propagation is done on used values rather than computed values
to avoid disrupting other aspects of style computation,
such as inheritance, logical property mapping logic,
or length value computation.
| principal writing mode | page progression |
|---|---|
| horizontal-tb and ltr | left-to-right |
| horizontal-tb and rtl | right-to-left |
| vertical-rl | right-to-left |
| vertical-lr | left-to-right |
| Name: | text-combine-upright |
|---|---|
| Value: | none | all |
| Initial: | none |
| Applies to: | inline boxes and text |
| Inherited: | yes |
| Percentages: | n/a |
| Computed value: | specified keyword |
| Canonical order: | n/a |
| Animation type: | not animatable |
Example of horizontal-in-vertical tate-chu-yoko
The figure is the result of the rules
date span { text-combine-upright: all; }
and the following markup:
<date>平成<span>20</span>年4月<span>16</span>日に</date>
In Japanese, this effect is known as tate-chu-yoko.
Future levels of CSS Writing Modes will introduce values
to automatically detect commonly-affected sequences.
For example, CSS Writing Modes Level 4 introduces the digits value to combine sequences of digits.
tcy { text-combine-upright: all; }
if the following markup were given:
<tcy>12<span>34</span></tcy>no text would combine.
hwid/twid/qwid;
other glyph-width features such as fwidorpwid are not included)
to compress text
in cases where those variants are available for all typographic character units 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:
(一)Enable 1/n-width glyphs for combined text of ntypographic character units (i.e. use OpenType hwid for 2 typographic character units, twid for 3 typographic character units, etc.)
if the number of typographic character units > 1.
Note that the number of typographic character units ≠ number of Unicode codepoints!
(二)If the result is wider than 1em, horizontally scale the result to 1em.
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 composition
to match the advance height of 水 U+6C34
as rendered according to the specified font settings.
In such a case the resulting composition assumes
the advance height of 水 U+6C34 rather than 1em.
body element does not influence the principal writing mode.
(Issue 3779)
●Updated “Applies to” line for text-combine-upright to mention text
(since certain effects like display: contents can strip the box itself).
●Clarified that the central baseline is the ideographic central baseline.
(Issue 5177)
●Reshuffled text in the and improved cross-linking.
| 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 |
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.
Advisements are normative sections styled to evoke special attention and are
set apart from other normative text with <strong class="advisement">, like
this: UAs MUST provide an accessible alternative.
| Name | Value | Initial | Applies to | Inh. | %ages | Animation type | Canonical order | Computed value |
|---|---|---|---|---|---|---|---|---|
| direction | ltr | rtl | ltr | all elements | yes | n/a | not animatable | n/a | specified value |
| glyph-orientation-vertical | auto | 0deg | 90deg | 0 | 90 | n/a | n/a | n/a | n/a | n/a | n/a | n/a |
| text-combine-upright | none | all | none | inline boxes and text | yes | n/a | not animatable | n/a | specified keyword |
| text-orientation | mixed | upright | sideways | mixed | all elements except table row groups, rows, column groups, and columns | yes | n/a | not animatable | n/a | specified value |
| unicode-bidi | normal | embed | isolate | bidi-override | isolate-override | plaintext | normal | all elements, but see prose | no | n/a | not animatable | per grammar | specified value |
| writing-mode | horizontal-tb | vertical-rl | vertical-lr | horizontal-tb | All elements except table row groups, table column groups, table rows, table columns, ruby base containers, ruby annotation containers | yes | n/a | not animatable | n/a | specified value |