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:


example #1


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:


example #2 


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.


example #3


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:


example #4


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:


view of all IE8 writing 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.


example #5


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 (31)

  1. David says:

    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

  2. EricLaw says:

    @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

  3. David says:

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

  4. hAl says:

    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>

  5. Shahid says:

    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.

  6. gabe says:

    @ 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

  7. 2nd time Ive been duped says:

    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!

  8. Ryo Onodera says:

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

  9. was worried says:

    I was worried at first that your screen shots were pure IE8 extracts!

    Thank god you forged them… the XP/Vista themes do apply to the scrollbars and unlike your photoshopped example the scrollbars on the left/top are not inverted into the depressed state.

  10. Rossen Atanassov [MSFT] says:

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

  11. EricLaw [MSFT] says:

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

  12. Brianary says:

    Are you really supposed to rotate the characters for tb-* and bt-* writing-modes?

  13. progg.ru says:

    Thank you for submitting this cool story – Trackback from progg.ru

  14. Dave says:

    Microsoft,

    If the IE9 news is true, then please please PLEASE ensure that you address all the bugs in IE8 before focusing on the next version.  IE7 has tons of rendering issues and it makes life painful because of the huge user base!

    http://idreamincode.co.uk/ie8-bugs

  15. Doogal says:

    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>

  16. Rob Parsons says:

    Dave,

    What a great test page.

    http://idreamincode.co.uk/ie8-bugs

    I am working my way through it to validate and confirm your issues. There are some workarounds that I have come up with that I have appended to the connect tickets.

  17. Wilbert says:

    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;

    }

  18. Stifu says:

    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

  19. Sarcasm is the lowest says:

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

  20. Stifu says:

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

  21. qualitydirectory says:

    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.

  22. Sarcasm says:

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

  23. lenen lening says:

    Still waiting for rounded corners support. That would be a lot help for a lot of developers.

  24. Shedy says:

    EricLaw [MSFT],

    Will ‘Rounded Corners’ (border-radius: 1px) be supported in the next version of IE?

    Please don’t ignore our questions.

  25. Stephen Baker says:

    Given that this is a draft, shouldn’t the properties be -trident-writing-mode etc.?

  26. EricLaw [MSFT] says:

    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!

  27. Joe Clark says:

    I really think there are some errors in your Properties and Values table (which, true to Microsoft form, uses crap HTML).

    “East Asian writing systems in vertical mode” surely means vertical-text Chinese and Japanese but not, say, Vietnamese. The character progression is top to bottom, not left to right. This is shown in error. You got the block progression correct, namely right to left.

    Arabic script blockquote embedded in East Asian vertical text could go in either direction, from bottom to top or top to bottom, depending on author preference. In neither case are characters progressing right to left. An iIndividual character would not necessarily point up or down if the entire blockquote consists of that individual character.

    Traditional Mongolian uses top-to-bottom character progression (error in your table) but left-to-right line stacking (correct).

    Bottom-to-top scripts include Ogham, so in fact they exist, if only historically.

    This stuff is hard to get right. Please try smarter.

  28. Rossen Atanassov [MSFT] says:

    @Joe Clark: I think you’ve missed few things while reading the post.

    The property table taken from the W3C CSS3 spec draft (http://dev.w3.org/csswg/css3-text-layout/#writing-mode) describes how the shorthand of block progression works. This direction doesn’t imply anything about the physical orientation and progression of glyphs (we follow the standard Unicode BiDi for determining that).

    You are correct in saying that Mongolian uses TB-RL which is exactly what the table reads (not to be confused with "Arabic script block quote embedded in Mongolian script document").

    Stone-carved scripts such as Ogham are bottom-to-top but they are also single line, hence determining block progression is not possible and omitted from the spec. Although, there are examples when Ogham mixed with Latin is written in LR-BT. We will propose a change to the CSS draft to include it for completeness.

  29. Joe Clark says:

    No, I didn’t “miss” your correction to my correction. If top, bottom, left, and right are all physical locations in your system, and width is always horizontal while height is always vertical, then in fact vertical Chinese text does not stack lines left to right as claimed in your, or CSS WG’s, tables.

    The CSS spec for writing mode is half-assed on a good day and apparently still does not even use the research CSS WG commissioned from Fantasai. I am printing the whole thing out to read in detail later, but I expect this assessment to hold up.

    The only spec that got writing direction right was PDF/UA – solely for a brief time before a bunch of foreigners at a meeting in China asserted otherwise and queered the whole thing. I was the author of that section of the spec and am quite sure I got it right where everybody else didn’t. The parallel is inexact, as Web pages are not PDFs.

  30. Joe Clark says:

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