drafts: css-writing-modes/Overview.src.html@9a46d52c3a86 (annotated)

css-writing-modes/Overview.src.html@9a46d52c3a86 (annotated)

css-writing-modes/Overview.src.html

Tue, 16 Jul 2013 16:29:52 -0700

author: fantasai <fantasai.cvs@inkedblade.net>
date: Tue, 16 Jul 2013 16:29:52 -0700
changeset 8705: 9a46d52c3a86
parent 8678: 2369a5ba443d
child 8706: 92aa893ac8ca
permissions: -rwxr-xr-x

[css-writing-modes] Require hwid/twid/qwid for OT implementations of TCY compression when they are available for all characters in the composition

 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
 <html lang="en">
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <title>CSS Writing Modes Module Level 3</title>
   <link rel="stylesheet" type="text/css" href="../default.css">
   <style type="text/css">
     object { vertical-align: middle; }
     .sidebar { float: right; background: #eee; border: solid gray; margin: 1em; }
     .sidebar .figure { margin: 1em; }
     .sidebar object { margin: 0 auto; display: block; }
     .figurepair { display: table; margin: 1em auto; }
     .figurepair .figure { display: table-cell; }
      h2, .example { clear: both; }
     .figure img,
     .figure object,
     .example img,
     dd img { max-width: 100%; display: block; margin: 1em auto; }
     div.figure table {
     	margin:auto;
     }
   </style>
   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-ED.css">
   <script src='http://test.csswg.org/harness/annotate.js#CSS3-WRITING-MODES_DEV' type='text/javascript' defer></script>
 </head>
 <body>
 <div class="head">
 <!--logo-->
 <h1>CSS Writing Modes Module Level 3</h1>
 <h2 class="no-num no-toc">[LONGSTATUS] [DATE]</h2>
 <dl>
   <dt>This version:</dt>
     <dd><a href="http://dev.w3.org/csswg/css3-writing-modes/">http://dev.w3.org/csswg/css3-writing-modes/</a>
 <!--
     <dd><a href="http://www.w3.org/TR/[YEAR]/WD-[SHORTNAME]-[CDATE]/">[VERSION]</a>
 -->
   <dt>Latest version:</dt>
     <dd><a
       href="http://www.w3.org/TR/css3-writing-modes/">http://www.w3.org/TR/css3-writing-modes/</a></dd>
   <dt>Latest editor's draft:</dt>
     <dd><a href="http://dev.w3.org/csswg/css3-writing-modes/">http://dev.w3.org/csswg/css3-writing-modes/</a></dd>
   <dt>Previous version:</dt>
     <dd><a href="http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/">http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/</a></dd>
   <dt>Issues List:</dt>
     <dd><a href="http://www.w3.org/Style/CSS/Tracker/products/30">http://www.w3.org/Style/CSS/Tracker/products/30</a>
   <dt>Feedback:</dt>
     <dd><a href="mailto:www-style@w3.org?subject=%5Bcss-writing-modes%5D%20feedback">www-style@w3.org</a>
         with subject line &ldquo;<kbd>[css-writing-modes <var>&hellip; message topic &hellip;</var></kbd>&rdquo;
         (<a rel="discussion" href="http://lists.w3.org/Archives/Public/www-style/">archives</a>)
   <dt>Editors:</dt>
     <dd><a href="http://fantasai.inkedblade.net/contact">Elika J. Etemad</a> (Mozilla)</dd>
     <dd><a href="mailto:koji.a.ishii@mail.rakuten.com">Koji Ishii</a> (Rakuten, Inc.)</dd>
   <dt>Previous Editors:</dt>
     <dd><a href="mailto:murakami@antenna.co.jp">Shinyu Murakami</a> (<a href="http://www.antenna.co.jp/">Antenna House</a>)</dd>
     <dd><a href="mailto:paulnel@microsoft.com">Paul Nelson</a> (<a href="http://www.microsoft.com/">Microsoft</a>)</dd>
     <dd><a href="mailto:michelsu@microsoft.com">Michel Suignard</a> (<a href="http://www.microsoft.com/">Microsoft</a>)</dd>
   <dt>Test Suite:</dt>
         <dd><a href="http://test.csswg.org/suites/css3-writing-modes/nightly-unstable/">http://test.csswg.org/suites/css3-writing-modes/nightly-unstable/</a></dd>
 </dl>
 <!--copyright-->
 <hr title="Separator for header">
 </div>
 <h2 class="no-num no-toc" id="abstract">
 Abstract</h2>
   <p>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).</p>
   <p>Inherently bottom-to-top scripts are not handled in this version. See
     [[UTN22]] for an explanation of relevant issues.</p>
 <h2 class="no-num no-toc" id="status">
 Status of this document</h2>
 <!--status-->
 <p>The following features are at-risk and may be dropped during CR:
 <ul>
   <li>The ''use-glyph-orientation'' of 'text-orientation'
   <li>The ''digits'' value of 'text-combine-horizontal'.
 </ul>
 <h2 class="no-num no-toc" id="Contents">
 Table of Contents</h2>
 <!--toc-->
 <h2 id="text-flow">
 Introduction to Writing Modes</h2>
   <p>CSS Writing Modes Level 3 defines CSS features to support for various international
     writing modes, such as left-to-right (e.g. Latin or Indic), right-to-left
     (e.g. Hebrew or Arabic), bidirectional (e.g. mixed Latin and Arabic) and
     vertical (e.g. Asian scripts).</p>
   <p>A <dfn>writing mode</dfn> in CSS is determined by the 'writing-mode',
     'direction', and 'text-orientation' properties. It is defined primarily
     in terms of its <i>inline base direction</i> and <i>block flow
     direction</i>:
   <div class="sidebar">
     <div class="figure right">
       <a href="diagrams/text-flow-vectors-tb.svg" type="image/svg+xml">
         <img src="diagrams/text-flow-vectors-tb.png" class="landscape"
           alt="Latin-based writing mode"></a>
       <p class="caption">Latin-based writing mode
     </div>
     <div class="figure left">
       <a href="diagrams/text-flow-vectors-lr-reverse.svg" type="image/svg+xml">
         <img src="diagrams/text-flow-vectors-lr-reverse.png" class="landscape"
           alt="Mongolian-based writing mode"></a>
       <p class="caption">Mongolian-based writing mode
     </div>
     <div class="figure right">
       <a href="diagrams/text-flow-vectors-tb.svg" type="image/svg+xml">
         <img src="diagrams/text-flow-vectors-tb.png" class="landscape"
           alt="Han-based writing mode"></a>
       <a href="diagrams/text-flow-vectors-rl.svg" type="image/svg+xml">
         <img src="diagrams/text-flow-vectors-rl.png" class="landscape"
           alt="Han-based writing mode"></a>
       <p class="caption">Han-based writing mode
     </div>
   </div>
   <p>The <dfn>inline base direction</dfn> 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.
   <p>The <dfn>block flow direction</dfn> 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.</p>
   <p>A <dfn>horizontal writing mode</dfn> is one with horizontal lines of
     text, i.e. a downward or upward block flow. A <dfn>vertical writing
     mode</dfn> is one with vertical lines of text, i.e. a leftward or
     rightward block flow.
   <p class="note">These terms should not be confused with
     <dfn>vertical block flow</dfn> (which is a downward or
     upward block flow) and <dfn>horizontal block flow</dfn> (which is
     leftward or rightward block flow). To avoid confusion, CSS
     specifications avoid this latter set of terms.</p>
   <p>Writing systems typically have one or two native writing modes. Some
     examples are:
   <ul>
     <li>Latin-based systems are typically written using a left-to-right inline
       direction with a downward (top-to-bottom) block flow direction.
     <li>Arabic-based systems are typically written using a right-to-left
       inline direction with a downward (top-to-bottom) block flow direction.
     <li>Mongolian-based systems are typically written using a top-to-bottom
       inline direction with a rightward (left-to-right) block flow direction.
     <li>Han-based systems are commonly written using a left-to-right inline direction
       with a downward (top-to-bottom) block flow direction, <strong>or</strong>
       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.
   </ul>
   <p>The 'text-orientation' component of the writing mode determines the
     <i>line orientation</i>, and controls
     details of text layout such as the <i>glyph orientation</i>.
   <p class="note">See Unicode Technical Note #22 [[UTN22]]
     (<a href="http://fantasai.inkedblade.net/style/discuss/vertical-text/paper">HTML version</a>)
     for a more in-depth introduction to writing modes and vertical text.
 <h3 id="placement">
 Module Interactions</h3>
   <p>This module replaces and extends the 'unicode-bidi' and 'direction'
   features defined in [[!CSS21]] sections 8.6 and 9.10.
 <h3 id="values">
 Values</h3>
   <p>This specification follows the
   <a href="http://www.w3.org/TR/CSS21/about.html#property-defs">CSS property
   definition conventions</a> 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 &lt;color&gt; value type as used in this specification.</p>
   <p>In addition to the property-specific values listed in their definitions,
   all properties defined in this specification also accept the
   <a href="http://www.w3.org/TR/CSS21/cascade.html#value-def-inherit">inherit</a>
   keyword as their property value. For readability it has not been repeated
   explicitly.
 <h2 id="text-direction"><a name="bidi">
 Inline Direction and Bidirectionality</a></h2>
   <p>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
     <span class="index-def" title="bidirectionality (bidi)"><dfn>bidirectionality</dfn></span>, or
     "bidi" for short.</p>
   <div class="figure">
     <p><img src="diagrams/bidi.png"
             alt="An example of bidirectional text is a Latin name in an Arabic
                  sentence. The sentence overall is typeset right-to-left, but
                  the letters in the Latin word in the middle are typeset
                  left-to-right.">
     <p class="caption">Bidirectionality</p>
   </div>
   <p>The Unicode standard (<a href="http://www.unicode.org/reports/tr9/">Unicode Standard Annex #9</a>) 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.
   <p>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
     &ldquo;<a href="http://www.unicode.org/reports/tr9/#Bidirectional_Character_Types">bidi type B</a>&rdquo;
     <dfn>forced paragraph break</dfn>.
     This sequence forms the <dfn title="bidi paragraph">paragraph</dfn> unit
     in the bidirectional algorithm.
     Additionally, any such sequence forming part or all of the contents of a
     <a href="#bidi-isolate"><i>bidi-isolated</i></a> inline element also forms a <i>bidi paragraph</i>.
   <p>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.
     <strong>If a document language provides markup features to control
     bidi, authors and users should use those features instead</strong> and not
     specify CSS rules to override them.</p>
   <p>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.
   <p>The HTML specifications ([[HTML401]], section 8.2, and [[HTML5]], section 10.3.5) define
     bidirectionality behavior for HTML elements.</p>
   <p class="note">Because HTML UAs can turn off CSS styling, we advise HTML
     authors to use the HTML 'dir' attribute and &lt;bdo&gt; element to
     ensure correct bidirectional layout in the absence of a style sheet.</p>
 <h3 id="direction">
 Specifying Directionality: the 'direction' property</h3>
   <table class="propdef">
     <tbody>
       <tr>
         <th>Name:</th>
         <td><dfn>direction</dfn></td>
       </tr>
       <tr>
         <th><a href="#values">Value</a>:</th>
         <td>ltr | rtl </td>
       </tr>
       <tr>
         <th>Initial:</th>
         <td>ltr</td>
       </tr>
       <tr>
         <th>Applies to:</th>
         <td>all elements</td>
       </tr>
       <tr>
         <th>Inherited:</th>
         <td>yes</td>
       </tr>
       <tr>
         <th>Percentages:</th>
         <td>N/A</td>
       </tr>
       <tr>
         <th>Media:</th>
         <td>visual</td>
       </tr>
       <tr>
         <th>Computed&#160;value:</th>
         <td>specified value</td>
       </tr>
     </tbody>
   </table>
   <p>This property specifies the inline base direction or directionality
     of any bidi paragraph, embedding, isolate, or override established by the element.
     (See 'unicode-bidi'.) <!-- except plaintext -->
     In addition, it informs the ordering of
     <a href="http://www.w3.org/TR/CSS21/tables.html">table</a> column layout,
     the direction of horizontal <a href="http://www.w3.org/TR/CSS21/visufx.html#overflow">overflow</a>,
     and the default alignment of text within a line, and other layout effects
     that depend on the element's inline base direction.</p>
   <p>Values for this property have the following meanings:</p>
   <dl>
    <dt><dfn>ltr</dfn></dt>
    <dd>Left-to-right directionality.</dd>
    <dt><dfn>rtl</dfn></dt>
    <dd>Right-to-left directionality.</dd>
   </dl>
   <p class="note">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.</p>
   <p>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 <a href="#principal-writing-mode">below</a>.)
   <p class="note">Note that the 'direction' property of the HTML BODY
     element is <em>not</em> propagated to the viewport. That special
     behavior only applies to the background and overflow properties.
   <p class="note">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.
 <h3 id="unicode-bidi">
 Embeddings and Overrides: the 'unicode-bidi' property</h3>
     <table class="propdef">
       <tbody>
         <tr>
           <th>Name:</th>
           <td><dfn>unicode-bidi</dfn></td>
         </tr>
         <tr>
           <th><a href="#values">Value</a>:</th>
           <td>normal | embed | isolate | bidi-override | isolate-override | plaintext
         </tr>
         <tr>
           <th>Initial:</th>
           <td>normal</td>
         </tr>
         <tr>
           <th>Applies to:</th>
           <td>all elements, but see prose</td>
         </tr>
         <tr>
           <th>Inherited:</th>
           <td>no</td>
         </tr>
         <tr>
           <th>Percentages:</th>
           <td>N/A</td>
         </tr>
         <tr>
           <th>Media:</th>
           <td>visual</td>
         </tr>
         <tr>
           <th>Computed&#160;value:</th>
           <td>specified value</td>
         </tr>
       </tbody>
     </table>
   <p>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.
   <p>The following informative table summarizes the element-internal and
     element-external effects of 'unicode-bidi':
   <table class="data">
     <caption>Effect of non-''normal'' values of 'unicode-bidi' on inline elements</caption>
     <colgroup span=2></colgroup>
     <colgroup span=3></colgroup>
     <thead>
       <tr><th colspan=2 rowspan=2>
           <th colspan=3 scope=rowgroup><abbr title="To surrounding contents, the element behaves as if its boundary were...">Outside</abbr>
       <tr><th><abbr title="a strong character of the element's 'direction'.">strong</abbr>
           <th><abbr title="a neutral character.">neutral</abbr>
     </thead>
     <tbody>
       <tr><th rowspan=3 scope=colgroup><abbr title="Within the element, content is ordered as if...">Inside</abbr>
           <th><abbr title="the element's boundaries were strong characters of the element's 'direction'.">scoped</abbr>
           <td>''embed''
           <td>''isolate''
       <tr><th><abbr title="all text consisted of strong characters of the element's 'direction'.">override</abbr>
           <td>''bidi-override''
           <td>''isolate-override''
       <tr><th><abbr title="the element were a standalone paragraph ordered using UAX9 heuristics.">plaintext</a>
           <td>&mdash;
           <td>''plaintext''
     </tbody>
   </table>
   <p>Values for this property have the following (normative) meanings:</p>
   <dl>
     <dt><dfn>normal</dfn></dt>
     <dd>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.</dd>
     <dt><dfn>embed</dfn></dt>
     <dd>If the element is inline, this value creates a <dfn>directional embedding</dfn>
       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.
       <span class="note">This value has no effect on elements that are
       not inline.</span></dd>
     <dt><dfn>isolate</dfn></dt>
     <dd>On an inline element, this <dfn id=bidi-isolate title="bidi-isolate|bidi isolation|isolation">bidi-isolates</dfn> 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 <i>forced paragraph break</i>
       is treated as an <dfn>isolated sequence<dfn>:
       <ul>
         <li>the content within the sequence is ordered
           as if inside an independent paragraph
           with the base directionality specified by the element's 'direction' property.
         <li>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).
       </ul>
       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, <i>forced paragraph breaks</i> within the element still create
       a corresponding break in the containing paragraph.
       <p class="note">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.
       <p class="note">This value has no effect on elements that are not inline.</span>
     <dt><dfn>bidi-override</dfn></dt>
     <dd>This value puts the element's immediate content in a <dfn>directional override</dfn>.
       For an inline, this means that the element acts like a <i>directional embedding</i>
       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.</dd>
     <dt><dfn>isolate-override<dfn></dt>
     <dd>This combines the <i>isolation</i> behavior of ''isolate'' with the
       <i>override</i> behavior of ''bidi-override'': to surrounding content,
       it is equivalent to ''isolate'', but within the element content
       is ordered as if ''bidi-override'' were specified.
     <dt><dfn>plaintext</dfn></dt>
     <dd><p>This value behaves as ''isolate'' except that for the purposes of
       the Unicode bidirectional algorithm, the base directionality of each
       of the element's <i>bidi paragraphs</i> (if a block container)
       or <i>isolated sequences</i> (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).
       <p class="note">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.
   </dl>
   <p class=note>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.
   <p class=note>Note that 'unicode-bidi' does not affect the 'direction'
     property even in the case of ''plaintext'', and thus does not affect
     'direction'-dependent layout calculations.
   <p>The final order of characters within each <i>bidi paragraph</i> 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.
   <p>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.</p>
   <p>If an inline element is broken around a <i>bidi paragraph</i>
     boundary (e.g. if split by a block or <i>forced paragraph break</i>), 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.)
   <div class="example">
     <p>For example, where &lt;BR/&gt; is a <i>forced paragraph break</i>
     the bidi ordering is identical between
     <pre>&lt;para>...&lt;i1>&lt;i2>...&lt;BR/>...&lt;/i2>&lt;i1>...&lt;/para></pre>
     <p>and
     <pre>&lt;para>...&lt;i1>&lt;i2>...&lt;/i2>&lt;i1>&lt;BR/>&lt;i1>&lt;i2>...&lt;/i2>&lt;i1>...&lt;/para></pre>
     <p>for all values of 'unicode-bidi' on inline elements &lt;i1&gt; and &lt;i2&gt;.
   </div>
   <p class="note">
     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).</p>
 <h3 id="bidi-example">
 Example of Bidirectional Text</h3>
   <p>The following example shows an SGML 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.</p>
   <div class="example">
     <p>In this example, lowercase letters stand for inherently left-to-right
       characters and uppercase letters represent inherently right-to-left
       characters. The text stream is shown in logical backing store order.</p>
     <pre class="xml-example"><code class="xml">
 &lt;section dir=rtl&gt;
   &lt;para&gt;HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5&lt;/para&gt;
   &lt;para&gt;HEBREW6 &lt;emphasis&gt;HEBREW7&lt;/emphasis&gt; HEBREW8&lt;/para&gt;
 &lt;/section&gt;
 &lt;section dir=ltr&gt;
   &lt;para&gt;english9 english10 english11 HEBREW12 HEBREW13&lt;/para&gt;
   &lt;para&gt;english14 english15 english16&lt;/para&gt;
   &lt;para&gt;english17 &lt;quote dir=rtl&gt;HEBREW18 english19 HEBREW20&lt;/quote&gt;&lt;/para&gt;
 &lt;/section&gt;
     </code></pre>
     <p>Since this is arbitrary SGML, the style sheet is responsible for
       setting the writing direction. This is the style sheet:</p>
     <pre>
 /* Rules for bidi */
 [dir=ltr] {direction: rtl;}
 [dir=rtl] {direction: ltr;}
 quote     {unicode-bidi: isolate;}
 /* Rules for presentation */
 section, para  {display: block;}
 emphasis       {font-weight: bold;}
     </pre>
     <p>The first <code>&lt;section></code> element is a block with a right-to-left base direction,
       the second <code>&lt;section></code> element is a block with a left-to-right base direction.
       The <code>&lt;para></code>s are blocks that inherit the base direction from their parents.
       Thus, the first two <code>&lt;para></code>s are read starting at the top right,
       the final three are read starting at the top left.</p>
     <p>The <code>&lt;emphasis></code> 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 <code>&lt;quote></code> element, on the other hand,
       creates an <i>isolated sequence</i> with the given internal directionality.
     <p>The formatting of this text might look like this if the line length
       is long:</p>
     <pre class="ascii-art">
 WERBEH 4WERBEH english3 2WERBEH 1WERBEH
 WERBEH <b>7WERBEH</b> 6WERBEH
 english9 english10 english11 13WERBEH 12WERBEH
 english14 english15 english16
 english17 20WERBEH english19 18WERBEH
     </pre>
     <p>Note that the <code>&lt;quote></code> embedding causes
       <samp>HEBREW18</samp> to be to the right of <samp>english19</samp>.
     <p>If lines have to be broken, it might be more like this:</p>
     <pre class="ascii-art">
 WERBEH 1WERBEH
   -EH 4WERBEH english3
 WERB
    -EH <b>7WERBEH</b> 6WERBEH
 WERB
 english9 english10 en-
 glish11 12WERBEH
 WERBEH
 english14 english15
 english16
 english17 18WERBEH
 WERBEH english19
     </pre>
     <p>Because <samp>HEBREW18</samp> must be read before english19,
       it is on the line above <samp>english19</samp>.
       Just breaking the long line from the earlier formatting would not have worked.
       Note also that the first syllable from <samp>english19</samp>
       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.
   </div><!-- example -->
 <h3 id="bidi-box-model">
 Box model for inline elements in bidirectional context</h3>
   <p>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.
   <p class="note">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.</p>
 <!-- CSS2.1 8.6 -->
   <p>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 <i>start</i>-most box on the first line box
     in which the element appears has the <i>start</i> edge's margin, border,
     and padding; and the end-most box on the last line box in which the
     element appears has the <i>end</i> edge's margin, border, and padding.
     For example, in the ''horizontal-tb'' writing mode:
     <ul>
       <li>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.
       <li>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.
     </ul>
     <p>Analogous rules hold for vertical writing modes.</p>
   <p class="note">The 'box-decoration-break' property can override this
     behavior to draw box decorations on both sides of each box. [[!CSS3BG]] </p>
 <h2 id="vertical-intro">
 Introduction to Vertical Text</h2>
   <p><em>This subsection is non-normative.</em></p>
   <p>In addition to extensions to CSS2.1&rsquo;s support for bidirectional text,
     this module introduces the rules and properties needed to support vertical
     text layout in CSS.
   <p>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.
   <div class="figure">
     <p><img src="vert-horiz-comparison.png"
             alt="A comparison of horizontal and vertical Japanese shows that
                  although the lines rotate, the characters remain upright.
                  Some glyphs, however change: a period mark shifts from the
                  bottom left of its glyph box to the top right. Running
                  headers, however, may remain
                  laid out horizontally across the top of the page."></p>
     <p class="caption">Comparison of vertical and horizontal Japanese: iBunko application (iOS)</p>
   </div>
   <p class="note">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.</p>
   <p>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.
   <p>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:
   <div class="figure">
     <p><img src="vert-latin-layouts.png"
             alt="A dictionary definition for &#x30F4;&#x30A3;&#x30EB;&#x30B9;
                  might write the English word 'virus' rotated 90&deg; clockwise,
                  but stack the letters of the initialisms 'RNA' and 'DNA' upright."></p>
     <p class="caption">Examples of Latin in vertical Japanese: Daijirin Viewer 1.4 (iOS)</</p>
   </div>
   <p>In some special cases such as two-digit numbers in dates, text is fit
     compactly into a single vertical character box:
   <div class="figure" id="fig-mac">
     <p><img src="vert-number-layouts.png"
             alt="An excerpt from MacFan shows several possible vertical layouts
                  for numbers: the two-digit month and day are written as
                  horizontal-in-vertical blocks; the years are written with
                  each character upright; except in the English phrase
                  &ldquo;for Mac 2011&rdquo;, where the date is rotated to
                  match the rotated Latin."></p>
     <p class="caption">Mac Fan, December 2010, p.49</p>
   </div>
   <p>Layouts often involve a mixture of vertical and horizontal elements:
   <div class="figure">
     <p><img src="vert-horiz-combination.png"
             alt="Magazines often mix horizontal and vertical layout; for
                  example, using one orientation for the main article text
                  and a different one for sidebar or illustrative content."></p>
     <p class="caption">Mixture of vertical and horizontal elements</p>
   </div>
   <p>Vertical text layouts also need to handle bidirectional text layout;
     clockwise-rotated Arabic, for example, is laid out bottom-to-top.
 <h3 id="writing-mode">
 Block Flow Direction: the 'writing-mode' property</h3>
   <table class="propdef">
     <tbody>
       <tr>
         <th>Name:</th>
         <td><dfn>writing-mode</dfn></td>
       </tr>
       <tr>
         <th><a href="#values">Value</a>:</th>
         <td>horizontal-tb | vertical-rl | vertical-lr</td>
       </tr>
       <tr>
         <th>Initial:</th>
         <td>horizontal-tb</td>
       </tr>
       <tr>
         <th>Applies to:</th>
         <td>All elements except table row groups, table column groups, table rows, and table columns</td>
       </tr>
       <tr>
         <th>Inherited:</th>
         <td>yes</td>
       </tr>
       <tr>
         <th>Percentages:</th>
         <td>N/A</td>
       </tr>
       <tr>
         <th>Media:</th>
         <td>visual</td>
       </tr>
       <tr>
         <th>Computed&#160;value:</th>
         <td>specified value</td>
       </tr>
     </tbody>
   </table>
   <p>This property specifies whether lines of text are laid out horizontally
     or vertically and the direction in which blocks progress. Possible
     values:</p>
   <dl>
     <dt><dfn>horizontal-tb</dfn></dt>
     <dd>Top-to-bottom <i>block flow direction</i>.
         The <i>writing mode</i> is horizontal.</dd>
     <dt><dfn>vertical-rl</dfn></dt>
     <dd>Right-to-left <i>block flow direction</i>.
         The <i>writing mode</i> is vertical.</dd>
     <dt><dfn>vertical-lr</dfn></dt>
     <dd>Left-to-right <i>block flow direction</i>.
         The <i>writing mode</i> is vertical.</dd>
   </dl>
   <p>The 'writing-mode' property specifies the <i>block flow direction</i>,
     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 <i>writing mode</i>)
     is horizontal or vertical. The 'text-orientation' property then determines
     how text is laid out within the line box.
   <p>The <dfn id="principal-writing-mode">principal writing mode</dfn> 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.
   <p class="note">Note that the 'writing-mode' property of the HTML BODY
     element is <em>not</em> propagated to the viewport. That special
     behavior only applies to the background and overflow properties.
   <p>If an element has a different block flow direction than its containing
     block:
   <ul>
    <li>If the element has a specified 'display' of ''inline'', its 'display'
      computes to 'inline-block'. [[!CSS21]]
    <li>If the element has a specified 'display' of ''run-in'', its 'display'
      computes to 'block'. [[!CSS21]]
    <li>If the element is a block container, then it establishes a new block
      formatting context.
   </ul>
   <p>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.
   <div class="example">
     <p>In the following example, two block elements (1 and 3) separated
       by an image (2) are presented in various flow writing modes.</p>
     <p>Here is a diagram of horizontal writing mode (<code>writing-mode: horizontal-tb</code>):</p>
     <p><img alt="Diagram of horizontal layout: blocks 1, 2, and 3 are stacked top-to-bottom"
             src="horizontal.png" width="219" height="300" ></p>
     <p>Here is a diagram for the right-to-left vertical writing mode commonly
       used in East Asia (<code>writing-mode: vertical-rl</code>):</p>
     <p><img alt="Diagram of a right-to-left vertical layout: blocks 1, 2,
                   and 3 are arranged side by side from right to left"
               src="vertical-rl.png" height="191" width="297" ></p>
     <p>And finally, here is a diagram for the left-to-right vertical
       writing mode used for Manchu and Mongolian (<code>writing-mode: vertical-lr</code>):</p>
     <p><img alt="Diagram of left-to-right vertical layout: blocks 1, 2,
                   and 3 are arranged side by side from left to right"
             src="vertical-lr.png" height="191" width="300" ></p>
   </div>
   <div class="example">
     <p>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.
     <pre>
 <!-- -->&lt;style>
 <!-- -->  form { writing-mode: vertical-rl; }
 <!-- -->&lt;/style>
 <!-- -->...
 <!-- -->&lt;form>
 <!-- -->&lt;p>&lt;label>姓名&#x3000;&lt;input value="艾俐俐">&lt;/label>
 <!-- -->&lt;p>&lt;label>语文&#x3000;&lt;select>&lt;option>English
 <!-- -->                       &lt;option>français
 <!-- -->                       &lt;option>فارسی
 <!-- -->                       &lt;option>中文
 <!-- -->                       &lt;option>日本語&lt;/select>&lt;/label>
 <!-- -->&lt;/form></pre>
     <p><img alt="Screenshot of vertical layout: the input element is
                 laid lengthwise from top to bottom and its contents
                 rendered in a vertical writing mode, matching the
                 labels outside it. The drop-down selection control
                 after it slides out to the side (towards the after
                 edge of the block) rather than downward as it would
                 in horizontal writing modes."
             src="vertical-form.png"></p>
   </div>
   <div class="example">
     <p>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]]
     <pre>::marker { writing-mode: horizontal-tb;
 <!-- -->            vertical-align: text-top;
 <!-- -->            color: blue; }</pre>
     <div class="figure">
       <p><img alt="Diagram showing list markers of '1.', '2.', '3.' sitting
                    upright atop sideways vertical Latin list item text."
               class="example" src="vertical-horizontal-list-markers.png">
       <p class="caption">Example of horizontal list markers in a vertical list</p>
     </div>
   </div>
 <h4 id="svg-writing-mode">
 SVG1.1 'writing-mode' Values</h4>
   <p>SVG1.1 [[!SVG11]] defines some additional values: ''lr'',
     ''lr-tb'', ''rl'', ''rl-tb'', ''tb'', and ''tb-rl''.
   <p>These values are <em>deprecated</em> in any context except SVG1 documents.
     Implementations that wish to support these values in the context of CSS
     must treat them as follows:
   <table class="data">
     <thead>
       <tr><th>SVG1/Obsolete</th> <th>CSS</th></tr>
     </thead>
     <tbody>
       <tr><td>''lr''</td> <td rowspan=3>''horizontal-tb''</td></tr>
       <tr><td>''lr-tb''</td></tr>
       <tr><td>''rl''</td></tr>
       <tr><td>''tb''</td> <td rowspan=2>''vertical-rl''</td></tr>
       <tr><td>''tb-rl''</td></tr>
     </tbody>
   </table>
   <p class="note">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''.
   <p>In SVG1.1, these values set the <dfn>inline progression
     direction</dfn>, in other words, the direction the current text position
     advances each time a glyph is added. This is a geometric process that
     happens <em>after</em> bidi reordering, and thus has no effect on the
     interpretation of the 'direction' property (which is independent of
     'writing-mode'). (See <a href="http://www.w3.org/TR/SVG/text.html#RelationshipWithBiDirectionality">Relationship
     with bidirectionality</a>. [[!SVG11]])
   <p class="note">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.</p>
 <h2 id="inline-alignment">
 Inline-level Alignment</h2>
   <p>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.
 <h3 id="intro-baselines">
 Introduction to Baselines</h3>
   <p><em>This section is non-normative.</em></p>
   <p>A <dfn>baseline</dfn> is a line along the <i>inline axis</i> 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.
   <div class="figure">
     [Picture of alphabetic text in two font sizes with the baseline and
      emboxes indicated.]
   </div>
   <p>Different writing systems prefer different baseline tables.</p>
   <div class="figure">
     <p><img alt="Latin prefers the alphabetic baseline, on top of which most
                  letters rest, though some have descenders that dangle below it.
                  Indic scripts are sometimes typeset with a hanging baseline,
                  since their glyph shapes appear to be hanging from a
                  horizontal line.
                  Han-based systems, whose glyphs are designed to fill a square,
                  tend to align on their bottoms."
             src="script-preferred-baselines.gif"></p>
     <p class="caption">Preferred baselines in various writing systems</p>
   </div>
   <p>A well-constructed font contains a <dfn>baseline table</dfn>, 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.)
   <div class="figure">
     <p><img alt=""
             src="baselines.gif"></p>
     <p class="caption">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.</p>
   </div>
   <p>The baseline table is a property of the font, and the positions
     of the various baselines apply to all glyphs in the font.
   <p>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.
 <h3 id="text-baselines">
 Text Baselines</h3>
   <p>In this specification, only the following baselines are considered:
   <dl>
     <dt>alphabetic</dt>
     <dd>The <dfn>alphabetic baseline</dfn>, which typically aligns with the
       bottom of uppercase Latin glyphs.
     </dd>
     <dt>central</dt>
     <dd>The <dfn>central baseline</dfn>, 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 (<i>over</i>)
       and descender (<i>under</i>) edges of the em box.
     </dd>
   </dl>
   <p>In vertical writing mode, the <i>central baseline</i> is used as the
     dominant baseline when 'text-orientation' is ''mixed'' or ''upright''.
     Otherwise the <i>alphabetic baseline</i> is used.
   <p class="note">A future CSS module will deal with baselines in more
     detail and allow the choice of other dominant baselines and alignment
     options.</p>
 <h3 id="replaced-baselines">
 Atomic Inline Baselines</h3>
   <p>If an <a href="http://www.w3.org/TR/CSS21/visuren.html#inline-boxes">atomic
     inline</a> (such as an inline-block, inline-table, or replaced inline element)
     is not capable of providing its own baseline information, then the
     UA synthesizes a baseline table thus:
   <dl>
     <dt>alphabetic</dt>
     <dd>The alphabetic baseline is assumed to be at the <i>under</i>
       margin edge.</dd>
     <dt>central</dt>
     <dd>The central baseline is assumed to be halfway between the
     <i>under</i> and <i>over</i> margin edges of the box.
   </dl>
 <h3 id="baseline-alignment">
 Baseline Alignment</h3>
   <p>The <dfn>dominant baseline</dfn>
     (which <a href="#text-baselines">can change</a> based on the writing mode)
     is used in CSS for alignment in two cases:
   <ul>
     <li><strong>Aligning glyphs from different fonts within the same inline box.</strong>
       The glyphs are aligned by matching up the positions of the dominant
       baseline in their corresponding fonts.
     <li><strong>Aligning a child inline-level box within its parent.</strong>
       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'', ''&lt;length&gt;'', and
       ''&lt;percentage&gt;'', the baselines are aligned as for ''baseline'',
       but the child is shifted according to the offset given by its
       'vertical-align' value.
       <div class="example">
         <p>Given following sample markup:
         <pre>&lt;p&gt;&lt;span class="outer"&gt;Ap &lt;span class="inner"&gt;<i>ji</i>&lt;/span&gt;&lt;/span&gt;&lt;/p&gt;</pre>
         <p>And the following style rule:
         <pre>span.inner { font-size: .75em; }</pre>
         <p>The baseline tables of the parent (<code>.outer</code>) and the child
           (<code>.inner</code>) 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.
         <div class="figure">
           <p><img alt="" src="baseline-align-sizes.gif">
         </div>
       </div>
     <div class="example">
       <p>If we assign ''vertical-align: super'' to the <code>.inner</code>
         element from the example above, the same rules are used to align
         the <code>.inner</code> child to its parent; the only difference
         is in addition to the baseline alignment, the child is shifted to
         the superscript position.
       <pre>span.inner { vertical-align: super; font-size: .75em; }</pre>
       <div class="figure">
         <p><img alt="In this example, the resulting alignment is equivalent
                      to shifting the parent baseline table upwards by the
                      superscript offset, and then aligning the child's
                      alphabetic baseline to the shifted position of the
                      parent's alphabetic baseline."
                 src="baseline-align-super.gif">
       </div>
     </div>
   </ul>
 <h2 id="intro-text-layout">
 Introduction to Vertical Text Layout</h2>
   <p>Each writing system has one or more native orientations. Modern scripts
     can therefore be classified into three orientational categories:</p>
   <dl>
     <dt>horizontal-only</dt>
       <dd>Scripts that have horizontal, but not vertical, native orientation.
         Includes: Latin, Arabic, Hebrew, Devanagari
     <dt>vertical-only</dt>
       <dd>Scripts that have vertical, but not horizontal, native orientation.
         Includes: Mongolian, Phags Pa
     <dt>bi-orientational</dt>
       <dd>Scripts that have both vertical and horizontal native orientation.
         Includes: Han, Hangul, Japanese Kana
   </dl>
   <p>A <dfn>vertical script</dfn> is one that has a native vertical orientation:
     i.e. one that is either vertical-only or that is bi-orientational.
     A <dfn>horizontal script</dfn> is one that has a native horizontal orientation:
     i.e. one that is either horizontal-only or that is bi-orientational.
     (See <a href="#script-orientations">Appendix B</a> for a categorization of
     scripts by native orientation.)
   <div class="figure">
         <p><img alt="A Venn diagram of these distinctions would show two circles:
                      one labelled 'vertical', the other 'horizontal'. The overlapped
                      region would represent the bi-orientational scripts, while
                      horizontal-only and vertical-only scripts would occupy their
                      respective circles' exclusive regions."
                 src="baseline-align-super.gif">
   </div>
   <p>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 <dfn>bi-orientational
     transform</dfn>, and there are two types:
   <dl>
     <dt>rotate</dt>
       <dd>Rotate the glyph from horizontal to vertical
       <a href="diagrams/glyph-right.svg" type="image/svg+xml">
         <img src="diagrams/glyph-right.png" class="figure"
           alt="Rotate the glyph from horizontal to vertical"></a>
     <dt>translate</dt>
       <dd>Translate the glyph from horizontal to vertical
       <a href="diagrams/glyph-upright.svg" type="image/svg+xml">
         <img src="diagrams/glyph-upright.png" class="figure"
           alt="Translate the glyph from horizontal to vertical"></a>
   </dl>
   <p>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.
   <p>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.
   <p class="note">The ''sideways-left'', ''sideways-right'', and ''sideways''
     values of 'text-orientation' are provided for decorative layout effects
     and to work around limitations in CSS support for bottom-to-top scripts.
 <h3 id="text-orientation">
 Orienting Text: the 'text-orientation' property</h3>
   <table class="propdef">
     <tbody>
       <tr>
         <th>Name:</th>
         <td><dfn>text-orientation</dfn></td>
       </tr>
       <tr>
         <th><a href="#values">Value</a>:</th>
         <td>mixed | upright | sideways-right | sideways-left | sideways
             | use-glyph-orientation
       </tr>
       <tr>
         <th>Initial:</th>
         <td>mixed</td>
       </tr>
       <tr>
         <th>Applies to:</th>
         <td>all elements except table row groups, rows, column groups, and columns</td>
       </tr>
       <tr>
         <th>Inherited:</th>
         <td>yes</td>
       </tr>
       <tr>
         <th>Percentages:</th>
         <td>N/A</td>
       </tr>
       <tr>
         <th>Media:</th>
         <td>visual</td>
       </tr>
       <tr>
         <th>Computed&#160;value:</th>
         <td>specified value</td>
       </tr>
     </tbody>
   </table>
   <p>This property specifies the orientation of text
     within a line. Current values only have an effect in vertical writing
     modes; the property has no effect on elements in horizontal writing modes.
   <p>For readability, the term <i>character</i> is used in place of
     <em>extended grapheme cluster</em> in this section.
     See <a href="#character-properties">Characters and Properties</a>
     for further details.
   <p>Values have the following meanings:</p>
   <dl>
     <dt><dfn>mixed</dfn></dt>
     <dd><p>In vertical writing modes, characters from horizontal-only
       scripts are set sideways, i.e. 90&deg; clockwise from their standard
       orientation in horizontal text.
       Characters from vertical scripts are set with their intrinsic orientation.
       See <a href="#vertical-orientations">Vertical Orientations</a> for further details.
     <p>This value is typical for layout of primarily vertical-script text.
     <dt><dfn>upright</dfn></dt>
     <dd><p>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 <a href="#vertical-orientations">Vertical Orientations</a> for further details.
       <p>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''.
     <dt><dfn>sideways-right</dfn></dt>
     <dd><p>In vertical writing modes, this causes text to be set as if
       in a horizontal layout, but rotated 90&deg; clockwise.
     <dt><dfn>sideways-left</dfn></dt>
     <dd><p>In vertical writing modes, this causes text to be set as if
       in a horizontal layout, but rotated 90&deg; counter-clockwise.
       <p>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&deg; 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.
       <p>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.
     <dt><dfn>sideways</dfn></dt>
     <dd><p>This value is equivalent to ''sideways-right'' in ''vertical-rl''
       writing mode and equivalent to ''sideways-left'' in ''vertical-lr''
       writing mode. It can be useful when setting horizontal script text
       vertically in a primarily horizontal-only document.
     <dt><dfn>use-glyph-orientation</dfn></dt>
     <dd><p>[[!SVG11]] defines 'glyph-orientation-vertical' and
       'glyph-orientation-horizontal' properties that were intended to control
       text orientation. These properties are <em>deprecated</em> and do not
       apply to non-SVG elements. If an implementation supports these properties,
       the ''use-glyph-orientation'' value when set on SVG elements indicates
       that the SVG
       'glyph-orientation-vertical' and 'glyph-orientation-horizontal'
       behavior control the layout of text. Such UAs must set
       ''text-orientation: use-glyph-orientation'' on all
       <a href="http://www.w3.org/TR/SVG/intro.html#TermTextContentElement">SVG
       text content elements</a> in their default UA style sheet for SVG.
       <p>In all other contexts, and for implementations that do not support
       the glyph orientation properties, the ''use-glyph-orientation'' behavior
       is the same as for ''mixed''.
       <p class="note">This value is at-risk and may be dropped during CR.
   </dl>
   <div class="figure" id="fig-text-orientation">
     <table class=data>
       <tr>
         <td>
           <img
             alt="text-orientation: mixed"
             src="text-orientation-vr.png" width="64" height="160" >
         </td>
         <td>
           <img
             alt="text-orientation: upright"
             src="text-orientation-up.png" width="64" height="160" >
         </td>
         <td>
           <img
             alt="text-orientation: sideways-left"
             src="text-orientation-sl.png" width="64" height="160" >
         </td>
         <td>
           <img
             alt="text-orientation: sideways-right"
             src="text-orientation-sr.png" width="64" height="160" >
         </td>
       </tr>
       <tr>
         <td>''mixed''</td>
         <td>''upright''</td>
         <td>''sideways-left''</td>
         <td>''sideways-right''</td>
       </tr>
     </table>
     <p class="caption">'text-orientation' values ('writing-mode' is ''vertical-rl'')</p>
   </div>
   <div class="example">
     <p>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''.
     <pre>
       :root { text-orientation: sideways; }
       caption { caption-side: left; writing-mode: vertical-lr; }
       thead th { writing-mode: vertical-lr; }
       h1.banner { position: absolute; top: 0; right: 0; writing-mode: vertical-rl; }
     </pre>
   </div>
   <p class="note">Changing the value of this property may affect inline-level alignment.
     Refer to <a href="#text-baselines">Text Baselines</a> for more details.</p>
 <h4 id='vertical-orientations'>
 Mixed Vertical Orientations</h4>
   <p>
     [[!UTR50]] defines the Vertical_Orientation property for the default character orientation of mixed-orientation vertical text.
     When 'text-orientation' is ''mixed'',
     the UA must render a <i>character</i> upright if its orientation property is
     <code>U</code>, <code>Tx</code>, or <code>Tu</code>;
     or <a href="#typeset-sideways">typeset it sideways</a> (90&deg; clockwise from horizontal)
     if its orientation property is <code>R</code>.
     For <code>Tr</code> <i>characters</i>,
     which are intended to be either transformed or rotated sideways,
     the UA may assume that appropriate glyphs for upright typesetting
     are given in the font and render them upright;
     alternately it may check for such glyphs first,
     and fall back to typesetting them sideways if the appropriate glyphs are missing.
   <p>
     In some systems (e.g. when using OpenType fonts),
     to correctly orient a <i>character</i> belonging to the Mongolian or Phags-pa script upright,
     the UA must actually typeset it <a href="#typeset-sideways">sideways</a>.
   <p class="note">This is because the "upright" orientation
     in the Unicode code charts (which assume vertical typesetting)
     and the "upright" orientation of the glyphs of these scripts
     in most OpenType fonts (which assume horizontal typesetting)
     don't match.
 <h4 id='vertical-font-features'>
 Vertical Typesetting and Font Features</h4>
   <p>When typesetting text in ''mixed'' and ''upright'' orientations:
   <dl>
     <dt>upright characters
     <dd>
       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.
       <p class="note">Note that even when typeset "upright",
         some glyphs should appear rotated.
         For example, dashes and enclosing punctuation
         (such as 〈 LEFT ANGLE BRACKET U+3008)
         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.)
         Unicode published draft data on which <i>characters</i> should appear sideways
         as the SVO property in <a href="http://www.unicode.org/reports/tr50/tr50-6.Orientation.txt">this data file</a>;
         however, this property has been abandoned for the current revision of [[!UTR50]].
     <dt id='typeset-sideways'>sideways characters
     <dd>
       Are typeset rotated 90&deg; 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.
       <!--<p class="issue">Propose 'svrt' as an OpenType substitution feature
       that is applied to rotated horizontal text in vertical text runs,
       to handle these cases.-->
   </dl>
   <p>
     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 <em>not</em> used.
   <p class="note">
     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.
   <p class=issue>This section needs additional work. Suggestions are welcome.
 <!-- random notes
   Property to customize text-orientation (and line breaking class) of various
   characters (yes, the name is horrible, we need a better one):
     text-symbolize: latin ||
                     greek ||
                     cyrillic ||
                     letter-symbols || /* letterlike symbols and math letters */
                     arrows || /* and math relation operators?? */
                     currency || /* Sc */
                     rotate-symbols || /* other So */
   Do symbols NFC-fold to Latin/Greek? If so we might have a problem there.
   Roman numerals are poorly handled right now. If we make them upright, we
   get the right behavior in most cases. But as soon as you get to 13, you
   have a problem.
 -->
 <h2 id="abstract-box">
 Abstract Box Terminology</h2>
   <p>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.
   <p>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
     <a href="#orthogonal-flows">orthogonal flows</a>.)
     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.
   <p>There are three sets of directional terms in CSS:
   <dl>
   <dt>physical
     <dd>Interpreted relative to the page, independent of writing mode.
     The physical directions are <i>left</i>, <i>right</i>, <i>top</i>, and
     <i>bottom</i>.
   <dt><a href="#logical-directions">flow-relative</a>
     <dd>Interpreted relative to the flow of content.
     The flow-relative directions are <i>start</i> and <i>end</i>,
     or <i>block-start</i>, <i>block-end</i>, <i>inline-start</i>, and <i>inline-end</i>
     if the dimension is also ambiguous.
   <dt><a href="#line-directions">line-relative</a>
     <dd>Interpreted relative to the orientation of the line box.
     The line-relative directions are <i>line-left</i>, <i>line-right</i>,
     <i>over</i>, and <i>under</i>.
   </dl>
   <p>The <dfn>physical dimensions</dfn> are <i>width</i> and <i>height</i>,
     which correspond to measurements along the <i>x-axis</i>
     (<i>vertical dimension</i>) and <i>y-axis</i> (<i>horizontal dimension</i>),
     respectively. <a href="#abstract-dimensions">Abstract dimensions</a>
     are identical in both flow-relative and line-relative terms, so there
     is only one set of these terms.
   <p class="note">
     Note: [[CSS-FLEXBOX]] also defines <a href="http://www.w3.org/TR/css3-flexbox/#box-model">flex-relative terms</a>,
     which are used in describing flex layout.
 <h3 id="abstract-dimensions">
 Abstract Dimensions</h3>
   <p>The <dfn>abstract dimensions</dfn> are defined below:
   <dl>
     <dt><dfn>block dimension</dfn></dt>
       <dd>The dimension perpendicular to the flow of text within a line, i.e.
         the <i>vertical dimension</i> in horizontal writing modes, and
         the <i>horizontal dimension</i> in vertical writing modes.</dd>
     <dt><dfn>inline dimension</dfn></dt>
       <dd>The dimension parallel to the flow of text within a line, i.e.
         the <i>horizontal dimension</i> in horizontal writing modes, and
         the <i>vertical dimension</i> in vertical writing modes.</dd>
     <dt><dfn>block-axis</dfn></dt>
       <dd>The axis in the block dimension, i.e. the <i>vertical
         axis</i> in horizontal writing modes and the <i>horizontal
         axis</i> in vertical writing modes.</dd>
     <dt><dfn>inline-axis</dfn></dt>
       <dd>The axis in the inline dimension, i.e. the <i>horizontal
         axis</i> in horizontal writing modes and the <i>vertical axis</i>
         in vertical writing modes.</dd>
     <dt><dfn>extent</dfn> or <dfn>logical height</dfn><dt>
       <dd>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.</dd>
     <dt><dfn>measure</dfn> or <dfn>logical width</dfn><dt>
       <dd>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 <i>measure</i> derives
         from its <a href="http://en.wikipedia.org/wiki/Measure_%28typography%29">use
         in typography</a>.)</dd>
   </dl>
 <h3 id="logical-directions">
 Flow-relative Directions</h3>
   <p>The <dfn>flow-relative directions</dfn>,
     <i>block-start</i>, <i>block-end</i>, <i>inline-start</i>, and <i>inline-end</i>,
     are defined relative to the flow of content on the page.
     In an <abbr title="left-to-right">LTR</abbr>
     ''horizontal-tb'' writing mode, they correspond to the
     top, bottom, left, and right directions, respectively.
     They are defined as follows:
   <dl>
   <dt><dfn>block-start</dfn>
     <dd>Nominally the side that comes earlier in the block progression,
     as determined by the 'writing-mode' property:
     the physical top in ''horizontal-tb'' mode,
     the right in ''vertical-rl'', and the left in ''vertical-lr''.
   <dt><dfn>block-end</dfn>
     <dd>The side opposite <i>block-start</i>.
   <dt><dfn>inline-start</dfn>
     <dd>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 <i>line-left</i> side.
     For boxes with a used 'direction'  value of ''rtl'', this means the <i>line-right</i> side.
   <dt><dfn>inline-end</dfn>
     <dd>The side opposite <i>start</i>.
   </dl>
   <p>Where unambiguous (or dual-meaning),
     the terms <dfn>start</dfn> and <dfn>end</dfn>
     are used in place of <i>block-start</i>/<i>inline-start</i>
     and <i>block-end</i>/<i>inline-end</i>, respectively.
   <p class="note">Note that while determining the <i>block-start</i> and
     <i>block-end</i> sides of a box depends only on the 'writing-mode' property,
     determining the <i>inline-start</i> and <i>inline-end</i> sides of a box depends
     not only on the 'writing-mode' property but also the 'direction' <em>and</em>
     'text-orientation' properties.</p>
   <div class="example">
     <p>An English (LTR-TB) block:</p>
     <pre class="ascii-art">
                   &lt;----- width / measure  -----&gt;
                              top side/
                           block-start side
                   +------------------------------+                  A
       left side/  |   ---inline direction --->   |  right side/     |
 inline-start side |  |                           |  inline-end side |
                   |  | block      * horizontal * |                height/
                   |  | direction  *writing mode* |                extent
                   |  V                           |                  |
                   +------------------------------+                  V
                              bottom side/
                             block-end side
     </pre>
   </div>
   <div class="example">
     <p>A vertical Japanese block (TTB-RL):</p>
     <pre class="ascii-art">
                   &lt;----- width / extent ------&gt;
                              top side/
                          inline-start side
                   +------------------------------+                  A
       left side/  |    &lt;---block direction---    |  right side/     |
   block-end side  |                           |  | block-start side |
                   |  *  vertical  *     inline|  |                height/
                   |  *writing mode*  direction|  |                measure
                   |                           V  |                  |
                   +------------------------------+                  V
                             bottom side/
                            inline-end side
     </pre>
   </div>
 <h3 id="line-directions">
 Line-relative Directions</h3>
   <p>The <dfn>line orientation</dfn> 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 <i>block-start</i> 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 <i>block-end</i> side.
     Hence the need for distinct terminology.
   <div class="figure">
     <img src="mongolian-lr.jpg" alt="Mongolian mixed with English">
     <p class="caption">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
     <a href="diagrams/text-flow-vectors-lr-reverse.svg">Diagram of Mongolian
     Text Layout</a>.)
   </div>
   <p>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 <dfn>line-relative directions</dfn>, which are
     defined relative to the <i>line orientation</i> as follows:
   <dl>
   <dt><dfn>over</dfn>
     <dd>Nominally the side that corresponds to the ascender side or “top”
       side of a line box. (The side overlines are typically drawn on.)
   <dt><dfn>under</dfn>
     <dd>Opposite of <i>over</i>: the line-relative “bottom” or descender side.
     (The side underlines are typically drawn on.)
   <dt><dfn>line-left</dfn>
     <dd>Nominally the side from which <abbr title="left-to-right">LTR</abbr>
     text would start.
   <dt><dfn>line-right</dfn>
     <dd>Nominally the side from which <abbr title="right-to-left">RTL</abbr>
     text would start. (Opposite of <i>line-left</i>.)
   </dl>
   <p>See the <a href="#logical-to-physical">table below</a> for the exact
     mappings between physical and line-relative directions.
   <div class="figure">
     <a href="diagrams/line-orient-up.svg" type="image/svg+xml">
       <img src="diagrams/line-orient-up.png" class="landscape"
         alt="Line orientation compass"></a>
     <p class="caption">Line orientation compass</p>
   </div>
   <div class="figurepair">
     <div class="figure">
     <a href="diagrams/line-orient-right.svg" type="image/svg+xml">
       <img src="diagrams/line-orient-right.png" class="portrait"
         alt="Typical orientation in vertical"></a>
       <p class="caption">Typical orientation in vertical</p>
     </div>
     <div class="figure">
     <a href="diagrams/line-orient-left.svg" type="image/svg+xml">
       <img src="diagrams/line-orient-left.png" class="portrait"
         alt="Line orientation with ''text-orientation: sideways-left''"></a>
       <p class="caption">Line orientation with ''text-orientation: sideways-left''</p>
     </div>
   </div>
 <h3 id="logical-to-physical">
 Abstract-to-Physical Mappings</h3>
   <p>The following table summarizes the abstract-to-physical mappings:</p>
   <table class="complex data">
     <caption>Abstract-Physical Mapping</caption>
     <colgroup class="header"></colgroup>
     <colgroup span=10></colgroup>
     <thead>
       <tr>
         <th scope="row">'writing-mode'</th>
         <th colspan="2">''horizontal-tb''</th>
         <th colspan="4">''vertical-rl''</th>
         <th colspan="4">''vertical-lr''</th>
       </tr>
       <tr>
         <th scope="row">'text-orientation'</th>
         <th colspan="2">&mdash;</th>
         <th colspan="2">''sideways-left''</th>
         <th colspan="2"><abbr title="mixed, upright, sideways-right">*right</abbr></th>
         <th colspan="2">''sideways-left''</th>
         <th colspan="2"><abbr title="mixed, upright, sideways-right">*right</abbr></th>
       </tr>
       <tr>
         <th scope="row">'direction'</th>
         <th>''ltr''</th>
         <th>''rtl''</th>
         <th>''ltr''</th>
         <th>''rtl''</th>
         <th>''ltr''</th>
         <th>''rtl''</th>
         <th>''ltr''</th>
         <th>''rtl''</th>
         <th>''ltr''</th>
         <th>''rtl''</th>
       </tr>
     </thead>
     <tbody>
       <tr>
         <th scope="row">extent</th>
         <td colspan="2">height</td>
         <td colspan="8">width</td>
       </tr>
       <tr>
         <th scope="row">measure</th>
         <td colspan="2">width</td>
         <td colspan="8">height</td>
       </tr>
       <tr>
         <th scope="row">block-start</th>
         <td colspan="2">top</td>
         <td colspan="4">right</td>
         <td colspan="4">left</td>
       </tr>
       <tr>
         <th scope="row">block-end</th>
         <td colspan="2">bottom</td>
         <td colspan="4">left</td>
         <td colspan="4">right</td>
       </tr>
       <tr>
         <th scope="row">inline-start</th>
         <td>left</td>
         <td>right</td>
         <td>bottom</td>
         <td>top</td>
         <td>top</td>
         <td>bottom</td>
         <td>bottom</td>
         <td>top</td>
         <td>top</td>
         <td>bottom</td>
       </tr>
       <tr>
         <th scope="row">inline-end</th>
         <td>right</td>
         <td>left</td>
         <td>top</td>
         <td>bottom</td>
         <td>bottom</td>
         <td>top</td>
         <td>top</td>
         <td>bottom</td>
         <td>bottom</td>
         <td>top</td>
       </tr>
     </tbody>
     <tbody>
       <tr>
         <th scope="row">over</th>
         <td colspan="2">top</td>
         <td colspan="2">left</td>
         <td colspan="2">right</td>
         <td colspan="2">left</td>
         <td colspan="2">right</td>
       </tr>
       <tr>
         <th scope="row">under</th>
         <td colspan="2">bottom</td>
         <td colspan="2">right</td>
         <td colspan="2">left</td>
         <td colspan="2">right</td>
         <td colspan="2">left</td>
       </tr>
       <tr>
         <th scope="row">line-left</th>
         <td colspan="2">left</td>
         <td colspan="2">bottom</td>
         <td colspan="2">top</td>
         <td colspan="2">bottom</td>
         <td colspan="2">top</td>
       </tr>
       <tr>
         <th scope="row">line-right</th>
         <td colspan="2">right</td>
         <td colspan="2">top</td>
         <td colspan="2">bottom</td>
         <td colspan="2">top</td>
         <td colspan="2">bottom</td>
       </tr>
     </tbody>
   </table>
 <h2 id="abstract-layout">
 Abstract Box Layout</h2>
 <h3 id="vertical-layout">
 Principles of Layout in Vertical Writing Modes</h3>
   <p>CSS box layout in vertical writing modes is analogous to layout in
     the horizontal writing modes, following the principles outlined below:
   <p>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:
   <ul>
     <li><p>Layout rules that refer to the width use the height instead,
         and vice versa.
     <li><p>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'.</p>
     <li><p>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 <i>start</i> and <i>end</i> sides
         and applied appropriately.</li>
   </ul>
   <div class="example">
     <p>For example, in vertical writing modes,
        table rows are vertical and table columns are horizontal.
       In a ''vertical-rl'' ''mixed'' ''rtl'' table,
       the first column would be on the bottom (the <i>inline-start</i> side),
       and the first row on the right (the <i>block-start</i> 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.
     <div class="figure">
       <p><a href="diagrams/vertical-table.svg" type="image/svg+xml">
         <img alt="Diagram of a vertical-rl mixed rtl table in a
         vertical block formatting context, showing the ordering of rows,
         cells, and columns as described above."
               class="example" src="diagrams/vertical-table.png"></a>
       <p class="caption">Table in ''vertical-rl'' RTL writing mode</p>
     </div>
   </div>
   <p>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 <a href="#line-left">line left</a> and <a href="#line-right">line
     right</a> sides are used as the reference for the left and right sides
     respectively.
   <p>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 <a href="#over">over</a>
     and <a href="#under">under</a> sides are used as the reference for the
     top and bottom sides respectively.
   <p>The details of these mappings are provided below.
 <h3 id="dimension-mapping">
 Dimensional Mapping</h3>
 <!--
   <p>Properties that are named in terms of the x and y axes are
     logical with respect to the block flow direction rather than absolute
     with respect to the page. Specifically:
   <ul>
     <li>The ''repeat-x'' keyword of 'background-repeat' tiles in the
       inline dimension of the element, which is not necessarily the
       horizontal dimension. [[!CSS21]] [[!CSS3BG]]
     <li>The ''repeat-y'' keyword of 'background-repeat' tiles in the
       block flow dimension of the element, which is not necessarily
       the vertical dimension. [[!CSS21]] [[!CSS3BG]]
     <li>The 'overflow-x' property controls overflow in the inline
       dimension of the element. [[!CSS3UI]]
     <li>The 'overflow-y' property controls overflow in the block
       flow dimension of the element. [[!CSS3UI]]
   </ul>
 -->
   <p>Certain properties behave logically as follows:
   <ul>
     <li>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]]
     <li>The 'line-height' property always refers to the logical
       height. [[!CSS21]]
   </ul>
   <p>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.
   <p>For example, the calculation rules in
     <a href="http://www.w3.org/TR/CSS21/visudet.html#Computing_widths_and_margins">CSS2.1 Section 10.3</a>
     are used for the inline dimension measurements:
     they apply to the measure (which could be either the physical width or physical height)
     and to the <i>inline-start</i> and <i>inline-end</i> margins, padding, and border.
     Likewise the calculation rules in
         <a href="http://www.w3.org/TR/CSS21/visudet.html#Computing_heights_and_margins">CSS2.1 Section 10.6</a>
     are used in the block dimension: they apply to the <i>extent</i> and to
     the <i>block-start</i> and <i>block-end</i> margins, padding, and border. [[!CSS21]]
   <p>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 <em>measure</em>
     of the containing block in CSS3.
 <h3 id="orthogonal-flows">
 Orthogonal Flows</h3>
   <p>When an element has a different 'writing-mode' from its
     containing block two cases are possible:
   <ul>
     <li>The two writing modes are parallel to each other. (For example,
       ''vertical-rl'' and ''vertical-lr'').</li>
     <li>The two writing modes are perpendicular to each other. (For
       example, ''horizontal-tb'' and ''vertical-rl'').</li>
   </ul>
   <p>
     When an element has a writing mode that is perpendicular to its containing block
     it is said to be in, or establish, an <dfn title="establish an orthogonal flow | orthogonal flow">orthogonal flow</dfn>.
   <p>
     To handle this case, CSS layout calculations are divided into
     two phases: sizing a box, and positioning the box within its flow.
   <ul>
     <li>
       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 <em>element</em>.
     <li>
       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
       <em>containing block</em>.
   </ul>
   <p>Since ''auto'' margins are resolved consistent with the containing
     block's writing mode, a box establishing an <i>orthogonal flow</i> can,
     once sized, be aligned or centered within its containing block just
     like other block-level elements by using auto margins.
   <div class='example'>
     <p>
       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.
     <p>
       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.
     <p class='issue'>
       Add a picture.
   </div>
   <p>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
     <a href="http://www.w3.org/TR/CSS21/visudet.html#blockwidth">10.3.3</a>,
     but its extent depends on its contents. In such cases the
     <i>available measure</i> is defined as the measure of the
     containing block; but the <i>available extent</i>, which
     would otherwise be the extent of the containing block, is
     infinite.
   <p>Putting a box in an <i>orthogonal flow</i> allows the opposite to happen:
     for the <i>available extent</i> to be defined, but the <i>available
     measure</i> 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 <i>fallback</i> variable
     in place of the <i>available measure</i> for calculations that
     require a definite <i>available measure</i>.
 <h4 id="orthogonal-auto">
 Auto-sizing in Orthogonal Flows</h4>
   <p class="issue">
     This section needs careful review for whether it is a) correct and b) sensible.
   <p>
     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:
   <p>
     <code>min(<var>max-content</var>, max(<var>min-content</var>, min(<var>fill-available</var>, <var>fill-fallback</var>)))</code>,
     where:
   <dl>
     <dt><var>min-content</var>
     <dd>the <a href="http://www.w3.org/TR/css3-sizing/#min-content-measure">min-content measure</a> of the element
     <dt><var>max-content</var>
     <dd>the <a href="http://www.w3.org/TR/css3-sizing/#max-content-measure">max-content measure</a> of the element
     <dt><var>fill-available</var>
     <dd>the <a href="http://www.w3.org/TR/css3-sizing/#fill-available-fit">fill-available fit</a> into the element's containing block's size in the element's inline axis
     <dt><var>fill-fallback</var>
     <dd>the <a href="http://www.w3.org/TR/css3-sizing/#fill-available-fit">fill-available fit</a> into the initial containing block's size in the element's inline axis
   </dl>
   <p>
     See [[!CSS3-SIZING]] for further details.
 <h4 id="orthogonal-multicol">
 Multi-column Layout in Orthogonal Flows</h4>
   <p>
     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
     <i>definite</i> but the element's measure is ''auto'':
   <ol>
     <li>
       If 'column-count' and 'column-width' are both ''auto'',
       calculate the used 'column-width' as
       the inner measure for ''auto''-sized elements, as defined above.
     <li>
       If the columns' extent is <i>indefinite</i>,
       the <i>fill-available extent</i> of the element is used.
     <li>
       The used 'column-count' then follows from filling the resulting columns with the element's content.
   </ol>
   <p>
     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 <i>max-content measure</i> of the element's contents;
     else it is calculated from the used 'column-width', 'column-count', and 'column-gap'.
   <p>
     The used extent of the element is either the used column extent
     (if multiple columns were used)
     or the <i>max-content extent</i> of the content.
   <p class="note">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.</p>
 <h4 id="orthogonal-pagination">
 Fragmenting Orthogonal Flows</h4>
   <p><em>This section is informative.</em></p>
   <p>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.
   <p>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.
   <div class="note">
     <p>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 <a href="http://www.w3.org/TR/css3-multicol/">columns</a> 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.
   </div>
 <h3 id="logical-direction-layout">
 Flow-Relative Mappings</h3>
   <p>Flow-relative directions are calculated with respect to
     the writing mode of the <em>containing block</em> 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 <em>parent
     element</em> is used instead.
   <p>For example, the margin that is dropped when a box's inline
     dimension is
     <a href="http://www.w3.org/TR/CSS21/visudet.html#blockwidth">over-constrained</a>
     is the end margin as determined by the writing mode of the
     containing block.
   <p>The <a href="http://www.w3.org/TR/CSS21/box.html#collapsing-margins">margin
     collapsing rules</a> apply exactly with the <em><i>block-start</i>
     margin</em> substituted for the top margin and the
     <em><i>block-end</i> margin</em> substituted for the bottom margin.
     Similarly the <i>block-start</i> padding and border are substituted
     for the top padding and border, and the <i>block-end</i> padding and
     border substituted for the bottom padding and border.
     Note this means only <i>block-start</i> and <i>block-end</i> margins ever collapse.
   <p>Flow-relative directions are calculated with respect to
     the writing mode of the element and used to abstract layout
     related to the element's contents:
   <ul>
     <li>The initial value of the 'text-align' property
       aligns to the <i>start</i> edge of the line box.
     <li>The 'text-indent' property indents from the <i>start</i>
       edge of the line box.
     <li>For tables, the ordering of columns begins on the <i>inline-start</i>
       side of the table, and the ordering of rows begins on the
       <i>block-start</i> side of the table.
   </ul>
 <h3 id="line-mappings">
 Line-Relative Mappings</h3>
   <p>The <dfn>line-relative directions</dfn> are
     <a href="#over">over</a>,
     <a href="#under">under</a>,
     <a href="#line-left">line-left</a>, and
     <a href="#line-right">line-right</a>. In an
     <abbr title="left-to-right">LTR</abbr>
     ''horizontal-tb'' writing mode, they correspond to the
     top, bottom, left, and right directions, respectively.
   <p>The line-right and line-left directions are calculated
     with respect to the writing mode of the element and used
     to interpret the ''left'' and ''right'' values of the
     following properties:
   <ul>
     <li>the 'text-align' property [[!CSS21]]
   </ul>
   <p>The line-right and line-left directions are calculated
     with respect to the writing mode of the <em>containing
     block</em> of the element and used to interpret the ''left''
     and ''right'' values of the following properties:
   <ul>
     <li>the 'float' property [[!CSS21]]
     <li>the 'clear' property [[!CSS21]]
   </ul>
   <p>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:
   <ul>
     <li>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]]
     <li>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]]
       <span class="note">Note that the CSS Text Module defines
       this in more detail and provides additional controls for
       controlling the position of underlines and overlines.
       [[CSS3TEXT]]</span>
   </ul>
 <h3 id="physical-only">
 Purely Physical Mappings</h3>
   <p>The following values are purely physical in their definitions
     and do not respond to changes in writing mode:
   <ul>
     <li>the ''rect()'' notation of the 'clip' property [[!CSS21]]
     <li>the background properties [[!CSS21]] [[!CSS3BG]]
     <li>the border-image properties [[!CSS3BG]]
     <li>the offsets of the 'box-shadow' and 'text-shadow' properties
   </ul>
 <h3 id="caption-side">
 Table Caption Mappings: the 'caption-side' keywords</h3>
   <table class="propdef">
     <tbody>
       <tr>
         <th>Property:</th>
         <td>'caption-side'</td>
       </tr>
       <tr>
         <th>New Values:</th>
         <td>''block-start'' | ''block-end''</td>
       </tr>
       <tr>
         <th>Initial:</th>
         <td>start</td>
       </tr>
       <tr>
         <th>Applies to:</th>
         <td>same as CSS2.1</td>
       </tr>
       <tr>
         <th>Inherited:</th>
         <td>same as CSS2.1</td>
       </tr>
       <tr>
         <th>Percentages:</th>
         <td>same as CSS2.1</td>
       </tr>
       <tr>
         <th>Media:</th>
         <td>same as CSS2.1</td>
       </tr>
       <tr>
         <th>Computed&#160;value:</th>
         <td>specified value</td>
       </tr>
     </tbody>
   </table>
   <p>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]]
   <p class='note'>For implementations that support the ''top-outside''
     and ''bottom-outside'' model, corresponding ''start-outside'' and
     ''end-outside'' are similarly introduced.
   <p>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.
   <p>For implementations that do support side captions
     (i.e. the ''left'' and ''right'' values from the obsolete CSS&nbsp;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 <i>inline-start</i> and <i>inline-end</i> 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.
   <p class="note">The CSS2.0 side caption model had some
     <a href="http://lists.w3.org/Archives/Public/www-style/2002Dec/0142.html">problems</a>
     and will likely have a different definition in CSS3.</p>
 <!--
 <h3 id="html-attributes">HTML Attributes</h3>
   <p>This section defines the mapping of HTML presentational attributes
     in CSS. This section is normative for user agents supporting HTML
     in addition to the 'writing-mode' property. [[!HTML40]] [[!HTML5]]
   <h4 id="width-height-attributes">The <code>width</code> and <code>height</code> attributes</h4>
   <p>The HTML <code>width</code> and <code>height</code> attributes refer
     to the physical width and height for elements that that are replaced,
     i.e.
     <code>&lt;applet&gt;</code>,
     <code>&lt;embed&gt;</code>,
     <code>&lt;iframe&gt;</code>,
     <code>&lt;img&gt;</code>,
     <code>&lt;object&gt;</code>,
     <code>&lt;canvas&gt;</code>,
     and
     <code>&lt;video&gt;</code>
   <p>Form elements elements contain text, therefore their contents should be
     affected by writing mode, in which case these attributes refer to the
     <em>logical</em> width and height. The UA may, however, choose not
     to rotate nor flip these elements in vertical writing modes if it is not
     capable, and in that case, these attributes remain physical.</p>
     <p class="issue">when not to rotate form elements/MathML,
       should treat them as images (always upright)
       or to force writing-mode to always calculate to horizontal-tb?</p>
   <p>On table-related elements (<code>&lt;table&gt;</code>, <code>&lt;colgroup&gt;</code>,
     <code>&lt;col&gt;</code>, <code>&lt;tr&gt;</code>, <code>&lt;th&gt;</code>,
     <code>&lt;td&gt;</code>) the <code>width</code> and <code>height</code>
     attributes are always logical.
   <p>The <code>size</code> attribute of the <code>&lt;hr&gt;</code> element
     is also logical (refers to the logical height).
   <h4 id="alignment-attributes">Alignment, Float and Clear Attributes</h4>
   <p>The following attributes behave the same way as their corresponding
     CSS properties:</p>
   <ul>
     <li><code>align</code> as 'float' or 'text-align'</li>
     <li><code>clear</code> as 'clear'</li>
     <li><code>valign</code> as 'vertical-align'</li>
   </ul>
   <h4 id="spacing-attributes">Spacing Attributes</h4>
   <p>The following attributes are logical and, as margins, are logical
     with respect to the writing mode of the <em>parent</em> element.</p>
   <ul>
     <li><code>hspace</code> as inline-start and inline-end margins</li>
     <li><code>vspace</code> as block-start and block-end margins</li>
     <li>marginwidth</li>
     <li>marginheight</li>
   </ul>
 -->
 <h2 id="page-direction">
 Page Flow: the page progression direction</h2>
   <p>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:
   <ul>
     <li>The page progression is right-to-left if the root element's
       'writing-mode' is ''vertical-rl'' or if the root element's 'writing-mode'
       is ''horizontal-tb'' and its 'direction' is ''rtl''.
     <li>The page progression is left-to-right if the root element's
       'writing-mode' is ''vertical-lr'' or if the root element's 'writing-mode'
       is ''horizontal-tb'' and its 'direction' is ''ltr''.
   </ul>
   <p>(Unless otherwise overridden, the first page of a document begins on the
     second half of a spread, e.g. on the right page in a left-to-right page
     progression.)
 <h2 id="text-combine">
 Glyph Composition</h2>
 <h3 id="text-combine-horizontal">
 Horizontal-in-Vertical Composition: the 'text-combine-horizontal' property</h3>
   <table class="propdef">
     <tbody>
       <tr>
         <th>Name:</th>
         <td><dfn>text-combine-horizontal</dfn></td>
       </tr>
       <tr>
         <th><a href="#values">Value</a>:</th>
         <td>none | all
             | [ digits &lt;integer>? ]
             <!--
             | [  [ numeric &lt;integer> | digits &lt;integer> ]
             || [ alpha &lt;integer> | latin &lt;integer> ]
             || alphanumeric &lt;integer> ]
             -->
       </tr>
       <tr>
         <th>Initial:</th>
         <td>none</td>
       </tr>
       <tr>
         <th>Applies to:</th>
         <td>non-replaced inline elements</td>
       </tr>
       <tr>
         <th>Inherited:</th>
         <td><a href="http://lists.w3.org/Archives/Public/www-style/2013Jul/0154.html" class="issue">???</a></td>
       </tr>
       <tr>
         <th>Percentages:</th>
         <td>N/A</td>
       </tr>
       <tr>
         <th>Media:</th>
         <td>visual</td>
       </tr>
       <tr>
         <th>Computed&#160;value:</th>
         <td>specified value</td>
       </tr>
     </tbody>
   </table>
   <p>This property allows the combination of multiple characters into the
     space of a single character. This property only has an effect
     in vertical writing modes. Values have the following meanings:</p>
   <dl>
     <dt><dfn title="text-combine-horizontal:none">none</dfn>
     <dd>No special processing.</dd>
     <dt><dfn title="text-combine-horizontal:all">all</dfn>
     <dd>In vertical writing modes,
       attempt to display the text contents of the element horizontally within the vertical line box.
       If the contents are wider than 1em, the UA must fit the contents within 1em, see below.
       The resulting composition is treated as a single glyph for the purposes
       of layout and decoration.
       If the content contains any element boundaries this is treated as
       ''text-combine-horizontal: none'' on the element and any descendants.
 <!--
     <dt><dfn title="text-combine-horizontal:numeric">numeric</dfn>
     <dd>Within the element, each sequence of consecutive horizontal numbers
       that has as many or fewer characters than the integer given is treated
       as if it were in an anonymous inline box with
       ''text-combine-horizontal: all''.
       For this property, a <dfn>horizontal number</dfn> is any character
       belonging to a Number category (N*) that does not belong to a
       <a href="#script-orientations">vertical script</a>.
 -->
     <dt><dfn title="text-combine-horizontal:digits">digits <var>&lt;integer></var>?</dfn>
     <dd>Within the element, each maximal sequence of consecutive ASCII digits (U+0030&ndash;U+0039)
       that has as many or fewer characters than the integer given is treated
       as if it were in an anonymous inline box with
       ''text-combine-horizontal: all''.
       When the integer is omitted, 2 is used.
       Integers outside the range 1-4 are invalid.
 <!--
     <dt><dfn title="text-combine-horizontal:alpha">alpha</dfn>
     <dd>Within the element, each sequence of consecutive horizontal letters
       that has as many or fewer characters than the integer given is treated
       as if it were in an anonymous inline box with
       ''text-combine-horizontal: all''.
       For this property, a <dfn>horizontal letter</dfn> is any character belonging
       to a Letter category (L*) that does not belong to a
       <a href="#script-orientations">vertical script</a>.
     <dt><dfn title="text-combine-horizontal:latin">latin</dfn>
     <dd>Within the element, each sequence of Latin letters
       that has as many or fewer characters than the integer given is treated
       as if it were in an anonymous inline box with
       ''text-combine-horizontal: all''.
       For this property, a <dfn>Latin letter</dfn> is any character belonging to
       a Letter category (L*) that also belongs to the Latin script.
       <p class="issue">This definition could replace ''alpha'' as a simplification.
       However, it wouldn't work for greek or mixtures of greek and latin (e.g. &mu;m).
     <dt><dfn title="text-combine-horizontal:alphanumeric">alphanumeric</dfn>
     <dd>Within the element, each sequence of consecutive horizontal digits and/or
       letters that has as many or fewer characters than the integer given is treated
       as if it were in an anonymous inline box with
       ''text-combine-horizontal: all''.
 -->
   </dl>
   <div class="example">
     <p>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:</p>
     <div class="figure">
       <p><img alt="Diagram of tate-chu-yoko, showing the two digits of a date
                    set halfwidth side-by-side in a vertical column of text"
               class="example" src="tate-chu-yoko.png">
       <p class="caption">Example of horizontal-in-vertical <i lang="ja">tate-chu-yoko</i></p>
     </div>
     <p>The figure is the result of the rules</p>
     <pre>
 <!-- -->date { text-combine-horizontal: digits 2; }
     </pre>
     <p>and the following markup:</p>
     <pre>
 <!-- -->&lt;date&gt;&#x5E73;&#x6210;20&#x5E74;4&#x6708;16&#x65E5;&#x306B;&lt;/date&gt;
     </pre>
     <p>In Japanese, this effect is known as <i lang="ja">tate-chu-yoko</i>.
   </div>
   <div class="example">
     <p>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:
     <pre>&lt;p>あれは10,000円ですよ！&lt;/p></pre>
     <div class="figure">
       <p><img alt="Rendering of the above markup with 'text-combine-horizontal: digits':
                    the first two digits of the number are rendered as tate-chu-yoko
                    while the rest of the number is rendered sideways."
               class="example" src="bad-tate-chu-yoko.png">
       <p class="caption">Example of mis-applied <i lang="ja">tate-chu-yoko</i></p>
     </div>
   </div>
   <p>In order to preserve typographic color when compressing the text to 1em,
     when the combined text consists of more than one <i>character</i>,
     then any full-width <i>characters</i> must first be converted to their non-full-width equivalents
     by reversing the algorithm defined for ''text-transform: full-width'' in [[!CSS3-TEXT]].
     Also, a 'font-variant' value of ''full-width'' must be ignored in such cases:
     whether applied via ''@font-face'' descriptor or property declaration,
     within the combined text this value does not not cause the UA to enable that font feature. [[!CSS3-FONTS]]
   <div class="example">
     <p>For example, an author might apply both 'text-transform' and 'text-combine-horizontal'
     to a date set in vertical text.
     <pre>date { text-combine-horizontal: digits 2; text-transform: full-width; }</pre>
     <p>Suppose this style rule is applied to a date such as.
     <pre>&lt;date>2010年2月23日&lt;/date></pre>
     <p>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:
     <pre style="text-align: center">
 <!-- -->２
 <!-- -->０
 <!-- -->１
 <!-- -->０
 <!-- -->年
 <!-- -->２
 <!-- -->月
 <!-- -->23
 <!-- -->日</pre>
   </div>
   <p>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.
   <p>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 <em>must</em> use width-specific variants
     (<code>hwid<code>/<code>twid</code>/<code>qwid</code>)
     to compress text
     in cases where those variants are available for all <i>characters</i> 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.
   <div class="example">
     <p>For example, a simple OpenType-based implementation might compress the text as follows:
     <ol>
       <li>Enable 1/<var>n</var>-width glyphs for combined text of <var>n</var> <i>characters</i>.
         (I.e. Use OpenType <code>hwid</code> for 2 <i>characters</i>, <code>twid</code> for 3 <i>characters</i>, etc.)
         Note that the number of <i>characters</i> &ne; number of Unicode codepoints!
       <li>Horizontally scale the result to 1em if it is not yet 1em or narrower.
     </ol>
     <p>A more sophisticated OpenType implementation might compose the text
     first with normal (proportional-width) 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.
   </div>
   <p>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.
   <!-- 水 U+6C34 was chosen because it is a very basic character common to
     all Han-based scripts, so would have to appear in any usable ideographic
     font; and its shape is very full in both dimensions, so it would be
     unlikely to be shortened in a proportional font -->
 <!--
 <h3 id="text-combine-mode">
 Horizontal-in-Vertical Glyph Scaling: the 'text-combine-mode' property</h3>
   <table class="propdef">
     <tbody>
       <tr>
         <th>Name:
         <td><dfn>text-combine-mode</dfn>
       </tr>
       <tr>
         <th><a href="#values">Value</a>:
         <td>auto | compress | [ no-compress || use-glyphs ]
       </tr>
       <tr>
         <th>Initial:
         <td>auto
       </tr>
       <tr>
         <th>Applies to:
         <td>non-replaced inline elements
       </tr>
       <tr>
         <th>Inherited:
         <td>yes
       </tr>
       <tr>
         <th>Percentages:
         <td>N/A
       </tr>
       <tr>
         <th>Media:
         <td>visual
       </tr>
       <tr>
         <th>Computed&#160;value:
         <td>specified value
       </tr>
     </tbody>
   </table>
   <p>This property controls how multiple characters are combined into the
     space of a single character when specified to do so via
     'text-combine-horizontal'. Values have the following meanings:</p>
   <dl>
     <dt><dfn title="text-combine-mode:auto">auto</dfn>
     <dd>If the contents are wider than 1em, the UA must attempt to fit the
       contents within 1em, but may use any method to do so.
     <dt><dfn title="text-combine-mode:compress">compress</dfn>
     <dd>Compress the composition (horizontally) as a whole until it fits within 1em.
       Do not substitute alternate-width glyphs.
     <dt><dfn title="text-combine-mode:use-glyphs">use-glyphs</dfn>
     <dd>Attempt to substitute narrower glyphs as necessary to make the
       composition fit within 1em:
       <ul>
         <li>a two-character composition uses 1/2-em or proportional glyphs
         <li>a three-character composition uses 1/3-em glyphs (if the font
           supports this feature, else fall back to 1/2-em or proportional glyphs)
         <li>etc.
       </ul>
       <p>Since even fonts that have fractional-width glyphs available do
       not have such glyphs for all characters, the UA must ensure the
       expected advance width for ''use-glyphs'' by either compressing or
       padding (equally on both sides) each glyph individually if it does
       not match the required advance width. (This step does not apply if
       ''no-compress'' is specified.)
     <dt><dfn title="text-combine-mode:no-compress">no-compress</dfn>
     <dd>Do not compress the composition or perform any glyph substitution
       in order to make the composition fit within 1em.
       When combined with ''use-glyphs'', however, this indicates to perform
       glyph substitution if possible per ''use-glyphs'' but not to compress
       the glyphs if they do not fit the size requirements.
       This value may cause the glyphs to overflow the line significantly.
   </dl>
 -->
 <h2 class="no-num" id="changes">Changes</h2>
   <h3 class="no-num" id="recent-changes">
   Changes since the <a href="http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/">May
 CSS Writing Modes Module Level 3 <abbr title="Working Draft">WD</abbr></a></h3>
   <p>Major changes include:</p>
   <ul>
     <li>Replaced 'unicode-bidi' value of ''isolate bidi-override'' with single keyword ''isolate-override''.
     <li>Clarified that bidi isolated content does not affect plaintext heuristics of the containing paragraph.
     <li>Lots of other clarifications to bidi.
     <li>Renamed ''mixed-right'' value of 'text-orientation' to ''mixed''.
     <li>Updated references to UTR50 for orientation of characters in Unicode
         and improved text defining vertical typesetting rules.
     <li>Fixed errors and clarified auto-sizing rules for orthogonal flows.
     <li>Replaced Appendix D with references to the new [[!CSS3-SIZING]] module.
     <li>Removed 'text-combine-mode' property.
     <li>Removed all 'text-combine-horizontal' values except ''none'' and ''all''.
     <li>Defined effect of 'text-combine-horizontal' on line-breaking.
   </ul>
   <h3 class="no-num" id="changes-201109">
   Changes since the <a href="http://www.w3.org/TR/2011/WD-css3-writing-modes-20110901/">September
 CSS Writing Modes Module Level 3 <abbr title="Working Draft">WD</abbr></a></h3>
   <p>Major changes include:</p>
   <ul>
     <li>Hooked up vertical typesetting details to UTR50.
     <li>Removed concept of "typographic modes".
     <li>Altered <a href="#orthogonal-auto">orthogonal sizing</a>
       to take into account the fill-available size; now the minimum of the
       fill-available and ICB size is used to resolve 'auto' sizes.
     <li>Renamed ''digits'' to ''numeric'' and ''ascii-digits'' to ''digits'' for 'text-combine-horizontal'.
     <li>Defined interaction of 'text-combine-horizontal' and 'text-transform'.
   </ul>
 <h2 id="conformance">
 Conformance</h2>
 <h3 id="conventions">
 Document Conventions</h3>
   <p>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.
   <p>All of the text of this specification is normative except sections
   explicitly marked as non-normative, examples, and notes. [[!RFC2119]]</p>
   <p>Examples in this specification are introduced with the words “for example”
   or are set apart from the normative text with <code>class="example"</code>,
   like this:
   <div class="example">
     <p>This is an example of an informative example.</p>
   </div>
   <p>Informative notes begin with the word “Note” and are set apart from the
   normative text with <code>class="note"</code>, like this:
   <p class="note">Note, this is an informative note.</p>
 <h3 id="conformance-classes">
 Conformance Classes</h3>
   <p>Conformance to CSS Writing Modes Level 3
   is defined for three conformance classes:
   <dl>
     <dt><dfn title="style sheet!!as conformance class">style sheet</dfn>
       <dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#style-sheet">CSS
       style sheet</a>.
     <dt><dfn>renderer</dfn></dt>
       <dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#user-agent">UA</a>
       that interprets the semantics of a style sheet and renders
       documents that use them.
     <dt><dfn id="authoring-tool">authoring tool</dfn></dt>
       <dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#user-agent">UA</a>
       that writes a style sheet.
   </dl>
   <p>A style sheet is conformant to CSS Writing Modes Level 3
   if all of its declarations that use properties defined in this module
   have values that are valid according to the generic CSS grammar and the
   individual grammars of each property as given in this module.
   <p>A renderer is conformant to CSS Writing Modes Level 3
   if, in addition to interpreting the style sheet as defined by the
   appropriate specifications, it supports all the features defined
   by CSS Writing Modes Level 3 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.)
   <p>An authoring tool is conformant to CSS Writing Modes Level 3
   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.
 <h3 id="partial">
 Partial Implementations</h3>
   <p>So that authors can exploit the forward-compatible parsing rules to
   assign fallback values, CSS renderers <strong>must</strong>
   treat as invalid (and <a href="http://www.w3.org/TR/CSS21/conform.html#ignore">ignore
   as appropriate</a>) any at-rules, properties, property values, keywords,
   and other syntactic constructs for which they have no usable level of
   support. In particular, user agents <strong>must not</strong> 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.</p>
 <h3 id="experimental">
 Experimental Implementations</h3>
   <p>To avoid clashes with future CSS features, the CSS2.1 specification
   reserves a <a href="http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords">prefixed
   syntax</a> for proprietary and experimental extensions to CSS.
   <p>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.
   </p>
 <h3 id="testing">Non-Experimental Implementations</h3>
   <p>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.
   <p>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.
   <p>Further information on submitting testcases and implementation reports
   can be found from on the CSS Working Group's website at
   <a href="http://www.w3.org/Style/CSS/Test/">http://www.w3.org/Style/CSS/Test/</a>.
   Questions should be directed to the
   <a href="http://lists.w3.org/Archives/Public/public-css-testsuite">public-css-testsuite@w3.org</a>
   mailing list.
 <h3 id="cr-exit-criteria">
 CR Exit Criteria</h3>
   <p>
   For this specification to be advanced to Proposed Recommendation,
   there must be at least two independent, interoperable implementations
   of each feature. Each feature may be implemented by a different set of
   products, there is no requirement that all features be implemented by
   a single product. For the purposes of this criterion, we define the
   following terms:
   <dl>
     <dt>independent <dd>each implementation must be developed by a
     different party and cannot share, reuse, or derive from code
     used by another qualifying implementation. Sections of code that
     have no bearing on the implementation of this specification are
     exempt from this requirement.
     <dt>interoperable <dd>passing the respective test case(s) in the
     official CSS test suite, or, if the implementation is not a Web
     browser, an equivalent test. Every relevant test in the test
     suite should have an equivalent test created if such a user
     agent (UA) is to be used to claim interoperability. In addition
     if such a UA is to be used to claim interoperability, then there
     must one or more additional UAs which can also pass those
     equivalent tests in the same way for the purpose of
     interoperability. The equivalent tests must be made publicly
     available for the purposes of peer review.
     <dt>implementation <dd>a user agent which:
     <ol class=inline>
       <li>implements the specification.
       <li>is available to the general public. The implementation may
       be a shipping product or other publicly available version
       (i.e., beta version, preview release, or “nightly build”).
       Non-shipping product releases must have implemented the
       feature(s) for a period of at least one month in order to
       demonstrate stability.
       <li>is not experimental (i.e., a version specifically designed
       to pass the test suite and is not intended for normal usage
       going forward).
     </ol>
   </dl>
   <p>The specification will remain Candidate Recommendation for at least
   six months.
 <h2 class="no-num" id="acknowledgements">
 Acknowledgements</h2>
 <p>John Daggett, Martin Heijdra, Laurentiu Iancu,
 Yasuo Kida, Tatsuo Kobayashi, Toshi Kobayashi,
 Ken Lunde, Nat McCully, Eric Muller,
 Paul Nelson, Kenzou Onozawa, Dwayne Robinson,
 Michel Suignard, Taro Yamamoto, Steve Zilles</p>
 <h2 id="character-properties" class="no-num">Appendix A.
 Characters and Properties</h2>
   <p>Unicode defines three codepoint-level properties that are referenced
     in CSS Writing Modes:
   <dl>
     <dt><a href="http://www.unicode.org/reports/tr11/#Definitions">East Asian width</a>
     <dd>Defined in [[!UAX11]] and given as the East_Asian_Width property
       in the Unicode Character Database [[!UAX44]].
     <dt><a href="http://www.unicode.org/reports/tr44/#General_Category_Values">General Category</a>
     <dd>Defined in [[!UAX44]] and given as the General_Category property
       in the Unicode Character Database [[!UAX44]].
     <dt><a href="http://www.unicode.org/reports/tr24/#Values">Script property</a>
     <dd>Defined in [[!UAX24]] and given as the Script property
       in the Unicode Character Database [[!UAX44]]. (UAs should
       include any ScriptExtensions.txt assignments in this mapping.)
   </dl>
   <p id=grapheme-cluster>In several sections (as noted), the term
     <dfn>character</dfn> is defined as <em>extended grapheme cluster</em>
     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.
   <p>Unicode defines properties for characters, but for 'text-orientation',
     it is necessary to determine the properties of a grapheme cluster.
     For the purposes of CSS Writing Modes, the properties of a grapheme
     cluster are given by its base character—except in two cases:
   <ul>
     <li>Grapheme clusters formed with an Enclosing Mark (Me) of the Common
     script are considered to be Other Symbols (So) in the Common script.
     They are assumed to have the same Unicode properties as the
     Replacement Character U+FFFD.
     <li>Grapheme clusters formed with a Space Separator (Zs) as the base
     are considered to be Modifier Symbols (Sk). They are assumed to have
     the same East Asian Width property as the base, but take their other
     properties from the first combining character in the sequence.
   </ul>
 <h2 id="bidi-html" class=no-num>
 Appendix B: Bidi Rules for HTML 4</h2>
 <p>The style sheet rules that would achieve the bidi behaviors specified
 in [[HTML401]] for the HTML Strict doctype are given below:
   <pre>
 /* HTML dir attribute creates an embedding */
 *[dir="ltr"]    { direction: ltr; unicode-bidi: embed; }
 *[dir="rtl"]    { direction: rtl; unicode-bidi: embed; }
 /* BDO element creates an override */
 bdo[dir="ltr"]  { direction: ltr; unicode-bidi: bidi-override; }
 bdo[dir="rtl"]  { direction: rtl; unicode-bidi: bidi-override; }
 /* HTML4.01:8.2.6 - preserve bidi behavior if 'display' is changed */
 html, body,
 div, address, blockquote, p,
 ul, ol, li, dl, dt, dd,
 fieldset, form,
 h1, h2, h3, h4, h5, h6,
 { unicode-bidi: isolate; }
   </pre>
 <h2 class="no-num" id="script-orientations">Appendix C:
 Vertical Scripts in Unicode</h2>
   <p><em>This section is informative.</em></p>
   <p>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 <i>horizontal-only</i>.
     The script classification of Unicode characters is given by [[!UAX24]].
   <table class="data">
     <caption>Vertical Scripts in Unicode</caption>
     <thead>
       <tr><th>Code	<th>Name                	<th>Transform (Clockwise)	<th>Vertical Intrinsic Direction
     </thead>
     <tbody>
       <tr><td>Bopo	<td>Bopomofo            	<th>0&deg;  	<th>ttb
       <tr><td>Egyp	<td>Egyptian Hieroglyphs	<th>0&deg;  	<th>ttb
       <tr><td>Hira	<td>Hiragana            	<th>0&deg;  	<th>ttb
       <tr><td>Kana	<td>Katakana            	<th>0&deg;  	<th>ttb
       <tr><td>Hani	<td>Han                 	<th>0&deg;  	<th>ttb
       <tr><td>Hang	<td>Hangul              	<th>0&deg;  	<th>ttb
       <tr><td>Merc	<td>Meroitic Cursive    	<th>0&deg;  	<th>ttb
       <tr><td>Mero	<td>Meroitic Hieroglyphs	<th>0&deg;  	<th>ttb
       <tr><td>Mong	<td>Mongolian           	<th>90&deg; 	<th>ttb
       <tr><td>Ogam	<td>Ogham               	<th>-90&deg;	<th>btt
       <tr><td>Orkh	<td>Old Turkic          	<th>-90&deg;	<th>ttb
       <tr><td>Phag	<td>Phags Pa            	<th>90&deg; 	<th>ttb
       <tr><td>Yiii	<td>Yi                  	<th>0&deg;  	<th>ttb
     </tbody>
   </table>
   <p><strong>Exceptions:</strong>
     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]]
   <p class="note">
     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.
   <p class="note">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&deg; counter-clockwise
     rotation from this orientation.
 <h2 class="no-num">
 References</h2>
 <h3 class="no-num">
 Normative references</h3>
 <!--normative-->
 <h3 class="no-num">
 Other references</h3>
 <!--informative-->
 <h2 class="no-num">
 Property Index</h2>
 <!-- properties -->
 <!-- Add alphabetic index? -->
 </body>
 </html>

Mercurial > drafts / annotate

css-writing-modes/Overview.src.html@9a46d52c3a86 (annotated)

css-writing-modes/Overview.src.html