The CSS Corner: writing-mode

Introduction

The writing-mode property enables text layout for non-Latin languages like Japanese and Arabic. Supported in IE since release 5.5, this property has been significantly updated in IE8. Our goals were threefold:

• To make its behavior more predictable for developers
• To align with relatively newer CSS concepts like shrink-to-fit sizing
• To further the CSS3 Text Layout module by providing the first implementation.

This post walks through the basics of the new implementation and the background you need to start experimenting. We’re looking forward to your feedback!

The Basics – properties and values

The writing-mode property, as defined in CSS3 Text Layout, is a shorthand for the ‘direction’ and ‘block-progression’ properties. Direction can be thought of as the flow of characters on a line; ‘block-progression’ can be thought of as the direction of line flow.­ The following table (mostly borrowed from the spec) shows its eight possible values:

writing-mode	direction	block-progression	Common Usage:
lr-tb	ltr	Tb	Latin-based, Greek, Cyrillic writing systems (and many others)
rl-tb	rtl	Tb	Arabic, Hebrew writing systems
tb-rl	ltr	Rl	East Asian writing systems in vertical mode
bt-rl	rtl	Rl	Arabic script block quote embedded in East Asian vertical text
tb-lr	ltr	Lr	Mongolian script writing system
bt-lr	rtl	Lr	Arabic script block quote embedded in Mongolian script document
lr-bt	ltr	Bt	None
rl-bt	rtl	Bt	None

(Note that the last two rows refer to combinations that are currently undefined because they are not used by the world’s scripts and languages. For completeness they are implemented in IE8.)

In understanding vertical text layout it is important to agree on terminology as the meaning of width and height can change based on context. We always refer to width and height as physical properties i.e. width is always horizontal and height is always vertical. In addition left, top, right and bottom are also considered physical.

The best way to understand writing-mode and vertical text layout is through examples. The simple scenarios below will help you understand sizing, overflow and tables.

Block dimensions

Vertical sizing algorithms swap width and height calculations, so the algorithm which was used for width in horizontal layout is now used for height in vertical layout.

Consider this example:

Here no widths and heights are specified for the two div elements; the first is parallel to the parent body, the second is orthogonal with writing-mode set to tb-lr.

Notice how the first div is as wide as the viewport and its height fits its content. This is as per the normal rules of CSS.

The sizing of the second div is exactly analogous with width and height swapped – the height is now the same as that of the viewport, and the width is sized to fit the content.

Note, viewport is used in this example, but if the body’s height was specified then its value would be used to compute the auto height as expected. The reasoning behind this behavior is that the user can scroll to the vertical content (if the first horizontal div was very long) and then start scrolling horizontally while all content still fits the vertical landscape of the viewport.

This example becomes more interesting as one adds a second orthogonal div, this time with a relative size:

 

The second vertical div has width set to 50%; notice how its physical width is 50% of that of viewport (body).

Note that the last block appears below the previous one because the block flow of the parent (body) is top to bottom. It may be natural to assume that the writing-mode of an element affects the block progression of the element itself but that is not the case. Changing block progression on the body to LR would place the blocks side by side. However, if BODY was to overflow horizontally it would do so in the writing direction of its parent. In this case the HTML element which is LR-TB, thus, overflow will be to the right thus hiding the beginning of the content. This is a subtle yet very important point since most users would expect that the origin point (where the first letter of the content appears) will be visible regardless of overflow. The reason is that overflow to the left and top (assuming LR-TB direction) is not a scrollable and hence clip-able area (see next section).

Overflow in vertical layout

Handling overflow in vertical layout is still under debate. IE8 positions scrollbars according to the direction of overflow i.e. if content overflows to the left of the element then the vertical scrollbar will be on the left side.

Consider an example where a fixed-sized element has writing-mode:bt-rl and overflowing content.

Notice the position of the scrollbars and also their initial state. Since the start of the content is the physical bottom of the element, that is the initial position of the vertical scroller.

Another interesting case is when the element is too wide for the window, thus forcing viewport scrollbars:

The start of the text is off the screen and the user must scroll right to see it. In addition the vertical scroller is not accessible after the user has scrolled to the right. This may seem odd but it is the expected result as the direction of the parent (body) is LR-TB. When developing pages in mixed mode layout, consider the effects of overflow.

Vertical layout and tables

In the case of vertical tables, rows become vertical and columns become horizontal. Using the following mark-up…

 <body writing-mode=”??-??”>
     ABCDEF
     <table>
          <tr> 
              <td> 1 </td> <td> 2 </td> <td> 3 </td>
          </tr>
          <tr>
              <td> 4 </td> <td> 5 </td> <td> 6 </td>
          </tr>
          <tr>
              <td> 7 </td> <td> 8 </td> <td> 9 </td>
          </tr>
     </table>
</body>

…these are the results in all eight modes:

Table sizing follows the same principle as box sizing: height and width calculations are swapped. The cell width / column width / table width calculation algorithms now use all height values. The cell height / row height / table height calculation algorithms now use all width values.

Padding, Margins and Percentage values

Most web authors who use CSS to design their web sites know that understanding margin collapsing takes time. This is why one of our goals while designing and implementing multiple writing directions was to limit any added complexity to margin collapsing logic. In essence, margin collapsing follows the same rules as in CSS 2.1 – 8.3.1. The only difference is that margins are collapsed in the direction of block-progression. The reason for that is that when an orthogonal change of direction (vertical inside of horizontal) occurs, the element changing direction becomes a Block Formatting Context. Hence, no margins of its nested elements (vertical ones) are collapsed with it. This is illustrated in the following example – note that none of nested blocks are collapsing their margins with the container (the dark-blue block) even thought the container has no borders.

Percentage values for padding and margins are computed based on the logical width. That is, the computed value of width if parent element is in horizontal or computed value of height if parent element is in vertical block-progression.

Thanks for reading. We will be following the comments for feedback and look forward to hearing from you.

Saloni Mira Rai – Program Manager and
Rossen Atanassov – Software Developer

Comments

• Anonymous
  May 29, 2009
  PingBack from http://www.anith.com/?p=42972

• Anonymous
  May 29, 2009
  hello can any one confirms this info that Microsoft begins work on Internet Explorer 9 ??? i this would like to no from  the IE Team if this info is confirm http://community.winsupersite.com/blogs/paul/archive/2009/05/05/microsoft-begins-work-on-internet-explorer-9.aspx

• Anonymous
  May 29, 2009
  @David, yes, as Dean described back in March, we are now working to release IE8 on Win7 and taking feedback for the next version.  See the "What's next" section here: http://blogs.msdn.com/ie/archive/2009/03/19/internet-explorer-8-final-available-now.aspx

• Anonymous
  May 30, 2009
  hi if work is in fac starting with IE9 how come this web site has not said any thing about it yet??? en.wikipedia.org/wiki/Internet_Explorer all so when can we get the 1st look with Internet Explorer 9??? when will bate 1 be comeing out??

• Anonymous
  May 30, 2009
  I can follow de examples now. It would be prefereable that he exmaplees page contained the reference pictures as wel. As in this is how your browser shows the example: <code example> This is how the example should look (reference image): <reference image>

• Anonymous
  May 31, 2009
  When "Rounded Corners" (CSS 3) will be supported? I am still waiting for this. Firefox/Chrome/Safari supported this but not IE. Example: -webkit-border-radius: -moz-border-radius: 10px; border-radius This saved me a lot of time than using corners images.

• Anonymous
  May 31, 2009
  @ david i doubt your see anything about what ie9 has in it for a while probably not for 12 months assuming same time frame as ie7 to 8 was

• Anonymous
  May 31, 2009
  the words "CSS Corner" should not be part of any post title unless the content of the post details how IE supports rounded corners in CSS. Its amazing how much reading these titles makes my blood boil just re-realizing how annoying it is that IE still doesn't support this - and all my IE end users see ugly harsh rectangles instead of nice soft rounded rectangles. Grrrrrrrrrrrr!

• Anonymous
  June 01, 2009
  Thanks for posting this. I'm implementing writing-mode in the gecko rendering engine(https://bugzilla.mozilla.org/show_bug.cgi?id=145503). Well, I was wondering why IE changed the behavior of 'height' between IE7 and IE8. And this article let me know the why. As for this, I'm not still completely agree with you, but I'll follow that 'top', 'right', 'bottom', 'left', 'width' and 'height' refer to those of the physical dimension. Although, I don't know how much time it'll take to implement this in the gecko. I just wanted to let you know I'm working on this. If we need to discuss the detail of this for interoperability, feel free to contact me, although my work at gecko is in very early stage. Particularly, I'm very excited to see that even tables are writing-mode-aware now. And the chosen reordering behavior looks fine to me. Great job! Also, if I can afford time, after finishing gecko, I'm planing to implement it in webkit too. My interest is to bring the vertical text into the web. That means if you need some help from me, it'll be OK(for example, creating various test suites).

• Anonymous
  June 01, 2009
  The comment has been removed

• Anonymous
  June 01, 2009
  @Ryo Onodera, thank you, it will be great to see support for vertical writing directions in other platforms.

• Anonymous
  June 02, 2009
  @wasworried: No one "forged" anything (it would be more work to do so, and to no benefit). Screenshots were taken on a machine with visual themes disabled, a common developer configuration. @David: Wikipedia is a great reference, but it's hardly complete.

• Anonymous
  June 02, 2009
  Are you really supposed to rotate the characters for tb-* and bt-* writing-modes?

• Anonymous
  June 02, 2009
  Thank you for submitting this cool story - Trackback from progg.ru

• Anonymous
  June 02, 2009
  The comment has been removed

• Anonymous
  June 02, 2009
  Perhaps you could explain what is going on with this simple table using writing-mode:tb-rl? Works find in IE7, looks a complete mess in IE8 <table border="2px">    <tr>      <td style="writing-mode:tb-rl">Some text</td>      <td style="writing-mode:tb-rl">Some more text</td>    </tr>  </table>

• Anonymous
  June 03, 2009
  The comment has been removed

• Anonymous
  June 04, 2009
  We, at our company, are hating IE7-8 because CSS attribute selectors for font size work in Firefox, but not IE. Why? font[size="1"] { font-size: 20px; }

• Anonymous
  June 04, 2009
  Wilbert: not sure whether it's an IE bug or not, but in the end, it's certainly due to the fact the font tag is long deprecated. Styling should be done in CSS. Rather than hating on IE7-8 for this, I'd rather hate developers who still use the font tag in 2009. :p

• Anonymous
  June 05, 2009
  @stifu Rather than hating developers who still use the font tag in 2009, I rather hate browsers that output the font tag while styling. editabledoc.execCommand("fontsize",false,4); will produce <font size=4>selected text</font> This is the behaviour in IE8 and Firefox is only slightly better with a quoted attribute.

• Anonymous
  June 06, 2009
  @Sarcasm is the lowest: Why not just do element.style.fontSize = "12px"? Or change its class dynamically, and define the font-size in the class.

• Anonymous
  June 06, 2009
  Really it's a surprise that IE doesn't support CSS's Rounded Corners. @David: I know Wikipedia provides good reference, but it's a work in progress/external resource and Microsoft owes it no obligation whatsoever to inform it about everything the company does.

• Anonymous
  June 07, 2009
  @stifu execCommand is used on editable documents. For example to post user comments with html support or email sites such as hotmail. The only simple way to do it is through execCommand, you can't act on the element as it may not exist before the command. The point is the browser outputs a font tag even though it really ought to be <span style='font-size:12px'>selected text</span>

• Anonymous
  June 08, 2009
  Still waiting for rounded corners support. That would be a lot help for a lot of developers.

• Anonymous
  June 08, 2009
  EricLaw [MSFT], Will 'Rounded Corners' (border-radius: 1px) be supported in the next version of IE? Please don't ignore our questions.

• Anonymous
  June 09, 2009
  Given that this is a draft, shouldn't the properties be -trident-writing-mode etc.?

• Anonymous
  June 09, 2009
  Shedy: Please don't imply that I ignore your questions.  However, just because I'm not ignoring question doesn't mean I can always answer them. Thank you for suggesting that CSS border-radius is important to you.  If you have other suggestions, I'm happy to hear them. Thanks!

• Anonymous
  June 09, 2009
  The comment has been removed

• Anonymous
  June 10, 2009
  The comment has been removed

• Anonymous
  June 11, 2009
  The comment has been removed

• Anonymous
  June 11, 2009
  Classical Mongolian adds characters from top to bottom and stacks lines left to right. Mongolian is TB-LR, not what you claim.