The CSS Corner: writing-mode

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:

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.

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 becausethe 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…

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.

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.

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

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!

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.

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.

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.