CSS Writing Modes Module Level 3

-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.
2.4.
Applying the Bidirectional Reordering Algorithm
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.
2.4.1.
Bidi Paragraph Embedding Levels
In CSS,
the paragraph embedding level must be set
(following
UAX9 clause HL1
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.
There is, however, one exception:
when the computed
unicode-bidi
of the paragraph’s containing block is
plaintext
the Unicode heuristics in P2 and P3 are used as described in
[UAX9]
without the HL1 override.
2.4.2.
CSS–Unicode Bidi Control Translation, Text Reordering
The final order of characters within each
bidi paragraph
is the
same as if the bidi control codes had been added as described for
unicode-bidi
(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.
Note that bidi control codes in the source text are still honored,
and might not correspond to the document tree structure.
This can split inlines or interfere with bidi start/end control pairing
in interesting ways.
2.4.3.
Bidi Treatment of Atomic Inlines
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.
(This is so that, in case the replaced element falls back to rendering inlined text content,
its bidi effect on the surrounding text is consistent with its replaced rendering.)
All other atomic inline-level boxes are treated as neutral characters
always.
2.4.4.
Paragraph Breaks Within Embeddings and Isolates
If an inline box is broken around a
bidi paragraph
boundary
(e.g. if split by a block or
forced paragraph break
),
then the
HL3
bidi control codes assigned to the end of the box
are also added before the interruption
and the codes assigned to the start of the box are also added after it.
(In other words, any embedding levels, isolates, or overrides started by the box
are closed at the paragraph break and reopened on the other side of it.)
For example, where
is a
forced paragraph break
the bidi ordering is identical between
......
......
and
......
......
for all values of
unicode-bidi
on inline elements and .
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.
2.4.5.
Reordering-induced Box Fragmentation
Since bidi reordering can split apart and reorder text
that is logically contiguous,
bidirectional text can cause an
inline box
containing such text
to be split and its fragments reordered within a line.
For each line box, UAs must take the fragments of each inline box
and assign the margins, borders, and padding in visual order (not logical order).
The
start
-most fragment on the first line box in which the box appears
has the
start
edge’s margin, border, and padding;
and the end-most fragment on the last line box in which the box 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 box fragment on the first line box in which the box appears
has the left margin, left border and left padding,
and the right-most box fragment on the last line box in which the box appears
has the right padding, right border and right margin.
When the parent’s
direction
property is
rtl
the right-most fragment of the first line box in which the box appears
has the right padding, right border and right margin,
and the left-most fragment of the last line box in which the box appears
has the left margin, left border and left padding.
Analogous rules hold for vertical writing modes.
The
box-decoration-break
property can override this behavior
to draw box decorations on both sides of each fragment.
[CSS3-BREAK]
3.
Vertical Writing Modes
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.
3.1.
Introduction to Vertical Writing
This subsection is non-normative.
Unlike languages that use the Latin script which are primarily laid out
horizontally, Asian languages such as Chinese and Japanese can be laid out
vertically. The Japanese example below shows the same text laid out
horizontally and vertically. In the horizontal case, text is read
from left to right, top to bottom. For the vertical case, the text is
read top to bottom, right to left.
Indentation from the left edge in the left-to-right horizontal case
translates to indentation from the top edge in the top-to-bottom vertical
case.
Comparison of vertical and horizontal Japanese: iBunko application (iOS)
For Chinese and Japanese lines are ordered either right
to left 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.
3.2.
Block Flow Direction: the
writing-mode
property
Name:
writing-mode
Value:
horizontal-tb
vertical-rl
vertical-lr
Initial:
horizontal-tb
Applies to:
All elements except table row groups, table column groups, table rows, 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
This property specifies whether lines of text are laid out horizontally
or vertically and the direction in which blocks progress. Possible
values:
horizontal-tb
Top-to-bottom
block flow direction
Both the
writing mode
and the
typographic mode
are horizontal.
vertical-rl
Right-to-left
block flow direction
Both the
writing mode
and the
typographic mode
are vertical.
vertical-lr
Left-to-right
block flow direction
Both the
writing mode
and the
typographic mode
are vertical.
The
writing-mode
property specifies the
block flow direction
which determines the ordering direction of block-level boxes in a block formatting context;
the ordering direction of line boxes in a block container that contains inlines;
the ordering direction 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 content of
replaced elements
do not rotate due to the writing mode:
images and external content such as from