#vertical text

[typo-vertebrale]

Souvenirs du Canada

[typo-vertebrale]

Souvenirs de Montpellier

[typo-vertebrale]

Quelques inscriptions glanées au Bourget.

[typo-vertebrale]

Gabby Thomas, championne olympique du 200m et diplômée d'Harvard, une école qui produit de très belles écharpes typographiées :)

[faintlyof]

I’m sorry, this is gonna take 3 business days to process at least.

[octomoosey]

I have a question and I was wondering if you knew how to do it - I'd prefer for the hover title to be vertical instead of horizontal, and I was wondering if that's possible to code. Thanks in advance!

hello there nonny,yes indeed - you can rotate your text using some very simple css.  rather than rewriting what’s out there, i’m just gonna link you to some really useful posts... you just need to add the ‘rotate’ transformation into the css of your tooltip! (at least, i think this is for tooltips? either way, add it to anything and it’ll rotate it... hehe!)

text rotation by css trickscss3 transform by w3 schools

even a text rotation generator by css3maker (i seriously love this site, it has so many useful things!)

[dstorey]

Vertical text update: text-combine-horizontal

In a previous blog post, I covered vertical text using CSS writing modes. At that time, it was possible to use vertical text in both IE (and has been since version 5.5) and WebKit. Since Opera switched to Blink, it now also joins that list. However, at that time, the support for more advanced control of glyphs within a vertical layout was very limited.

While the support does remain limited, the IE11 preview has become the first browser to support the text-combine-horizontal feature. I will show you this feature in this blog post; but first, a brief overview of how to use vertical text.

Setting text layout to vertical

Vertical layout can be achieved by using the writing-mode property. When text is laid out vertically, lines of text can proceed from right to left (as in CJK languages), or left to right (traditional Mongolian).

In the W3C Writing Modes specification, top to bottom, right to left text can be achieved using the vertical-rl value. IE implemented this before the current spec, and thus uses an older syntax–tb-rl–that came from SVG:

-ms-writing-mode: tb-rl; -webkit-writing-mode: vertical-rl; -moz-writing-mode: vertical-rl; -ms-writing-mode: vertical-rl; writing-mode: vertical-rl;

The less used top to bottom, left to right orientation can be achieved with vertical-lr and tb-lr for IE.

Glyph orientation

Outside of Asian languages like Chinese and Japanese, it is not customary to write using a vertical layout, but it is not unheard of. The Coke can sitting next to me has “Coca-Cola Zero” writen vertically, bottom to top, left to right. If you walk through any major city and look up at store signs, you’ll often see vertical text to save space. You’ll also see it on spines of books. In Asian vertical layouts, you will often see Latin (or other scripts) mixed in with the native script. In all these cases, there needs to be some control of the glyph orientation.

As far as I know, East Asian scripts always orientate there characters horizontally; they don’t flip on their side when displayed vertically. Latin characters can either be flipped on their side, following the direction of the text (such as on the aformentioned Coke can) or left upright, as seen on many store signs.

If you read my previous post, you’ll know that you can set the glyph orientation with the text-orientation property. Support for this hasn’t changed; it is still only supported in WebKit/Blink, and it still only has partial support. The upright value for keeping all glyphs in the horizontal orientation is the most important one for this article.

Combining upright characters

While by default characters are displayed one after another in the direction of the line, it is often desirable to display two or more side by side when using vertical text. A common example of this is Latin numbers in dates; instead of the digits in the month or day being displayed one after another, they are combined as if they were one character (actually 1em) wide.

IE11 adds support for the text-combine-horizontal property which enables this feature. There are two different modes, which act fairly differently, so it is important to understand how they work.

Combining digits

When you just want to combine digits, such as in our date example, you can use text-combine-horizontal: digits. By default this combines any two digits or less that are found together. If you specify a number after the digits keyword, it combines up to that many digits. The upper limit is 4. The glyphs are orientated upright, even if text-orientation is not applied, which is just as well, as IE doesn‘t support that property.

text-combine-horizontal: digits; /* combines runs of 1–2 digits (0–9) together*/ text-combine-horizontal: digits 2; /* same as above */ text-combine-horizontal: digits 4; /* combines runs of 1–4 digits */

The following example is inspired by a Mexican street sign found in Thinking with Type. The text-combine-horizontal: digits; declaration is used to combine each set of two digits in a 1em by 1em square, with the glyphs orientated horizontally:

Mexican street sign demo

There are some things to note here:

Each two digit pair are seperated by a space in the markup. If there were no spaces, there would be more than two digits together, and they would not be combined.

A space is not needed between a digit and a non-digit, as only number are counted. Thus if “Z88” was in the markup, “88” would still be combined together.

The “Z” in this example is not oriented upright as it is not a digit (more on that later)

When using the digits value, it will look for any runs of digits in the text of the element it is applied on…

…but the property is not inherited, so if there are any child elements (such as spans, em, strong, etc. Not exactly an uncommon occurrence) it will not apply to any text in those elements. This can be seen in an updated version of the demo. This is noted as an issue in the spec, and I hope it gets resolved.

It is also important to be careful when using this feature. While it only works on digits, sometimes long strings of digits are pretty printed to make them easier to read (as you will have seen in my Internationalization article). CJK languages use a comma for this. As this will split a run of digits, you may get part of the number combined and the rest left in the default state. The number 10,000,000 will combine 10 and leave the rest untouched. For this reason, it may be best, if you are likely to have situations like this, to use an inline element such as a span around digits you want to combine. This can be seen in a demo I updated from the previous vertical text article:

Japanese vertical text demo, with text-combine-horizontal

In this demo I combine any 3 digits or less that are found together. I highlighted all the digits in spans in red to be easier to find. Changing the value to 4 will combine the years as well. When four digits get combined, they can get quite compressed, so it is probably only wise to do this far large text sizes.

A couple of issues I found when making the previous demos is that IE applies any text-indent to text that has text-combine-horizontal applied (even if text-indent is only applied to the element’s parent), so this has to be cancelled out; and text-combine-horizontal is not applied to inline elements, even when directly specified on that element. Applying display: inline-block fixes this:

section span { /* make IE apply text-combine-horizontal to a span */ display: inline-block; /* remove text-indent that was applied on parent */ text-indent: 0; -webkit-text-combine-horizontal: digits 4; -moz-text-combine-horizontal: digits 4; -ms-text-combine-horizontal: digits 4; text-combine-horizontal: digits 4; color: red; }

One could take the opposite approach, and wrap the text you don’t want combined in spans, but in my case that wouldn’t work unless I remove the text-indent. If you do this, it is important to set text-combine-horizontal: none on the span, as if the spec is changed so that inheritance is allowed, it will suddenly break. Better to be safe than sorry.

Combining all text in an element

While the digits value only works on, well, digits, you can use the all value for any character. However, it is not that simple. It doesn’t look for runs of characters inside the element and look to combine them, but instead, it tries to combine the entire text content of the element. As with the digits value, the advance width of the result has to fit within a 1em square. As you can imagine, for a few characters that is pretty easy; a number of fonts even have half-width, third-width and quarter-width variants for certain glyphs; but for longer text, it is going to become unreadable quite fast. This text-combine-horizontal: all demo shows this in action.

Something important to point out is that this only works with (non-replaced) inline elements, unlike the digits value, which works in the polar opposite way in IE. I think this is fine, as you’re likely to be individually marking things up where this is to apply to when it works the way it does with all text in the element. It is also not applied if the element contains any child elements.

If you remember our earlier issue with the “Z” that didn’t rotate in the Mexican banner example, you will probably now see how that can be fixed using a span and text-combine-horizontal: all:

Mexican banner with Z in the correct orientation

HTML

<h1><span>Z</span> 44 82 98</h1>

CSS

h1 { … -ms-writing-mode: tb-rl; -webkit-writing-mode: vertical-rl; -moz-writing-mode: vertical-rl; -ms-writing-mode: vertical-rl; writing-mode: vertical-rl; /* only currently works in Blink/WebKit */ -webkit-text-orientation: upright; -moz-text-orientation: upright; -ms-text-orientation: upright; text-orientation: upright; /* only currently works in IE11 */ -webkit-text-combine-horizontal: digits; -moz-text-combine-horizontal: digits; -ms-text-combine-horizontal: digits; text-combine-horizontal: digits; } h1 span { /* Sets upright orientation for the Z */ -ms-text-combine-horizontal: all; }

As you can perhaps see, WebKit/Blink can use text-orientation: upright; to make the Z glyph display upright. I’m a little suprised that Microsoft added text-combine-horizontal without adding text-orientation and updating the values used by writing-mode. Perhaps for IE12?

[dstorey]

Vertical text with CSS 3 Writing Modes

Languages with latin-based writing systems such as English are typically written left to right, and from top to bottom. However, there is a whole different world of writing modes out there. CSS3 Writing Modes allows you to use these in your web sites. Read on to find out what you can, and can not use right now.

Introduction to writing modes

If you’re from anywhere outside of East Asia or the Middle East, it is likely that the writing mode your are most intimately familiar with is those that go from the left edge of the page to the right (line direction), and from the top of the page to the bottom (block direction). Examples of scripts that use this writing system include Latin (e.g. English, French, Spanish, etc.), Greek, Cyrillic (Russian, Ukrainian, Bulgarian, etc.), and Brahmic scripts such as Devanagari, Thai, Tibetan, and so on.

In the Middle-East (as well as North Africa, and Pakistan), the Arabic script is common, while in Israel the Hebrew script is used. Both of these scripts are written from right to left, rather than left to right as in Latin. What they do have in common with Latin scripts is that the lines progress down the page. If you look at a site set in Hebrew or Arabic, they tend to look like a mirror image of what one might expect if you come from a country that uses the Latin alphabet.

Things get a bit more complex when you look at CJK (Chinese, Japanese, and Korean), traditional Mongolian and other languages that can be written in vertical orientation. The key word is can. If you look at almost any Chinese or Japanese web site, you may notice that it is most likely written from left to right and top to bottom, just like Latin languages. While this is prevalent on the web, traditionally—and still in many printed publications—these languages were written with a line direction from top to the bottom of the page, and a block direction that goes from the right hand side of the page, to the left. Mongolian on the other hand uses the same top to bottom orientation, but the block direction goes from left to right.

I suspect one of the reasons why vertical text isn’t so prevalent on the web is that there hasn’t been high quality support for it in web browsers, and operating systems and applications in general. I would also guess there could be usability issues with scrolling. Vertical scrolling has traditionally been easier than horizontal scrolling, and you don’t want to keep scrolling up and down the page for each line. Multi-column layout on the web has similar scrolling issues. I’m mainly guessing though, as I’m not much more than a rookie in terms of when and how to use vertical rather than horizontal text in East Asian languages.

How to apply writing modes on the Web

In actual fact, we’ve been able to use vertical text longer than you might think. IE 5.5 added support for this feature, and support was upgraded in IE8. At the basic level, the support problem was that of other browsers. Things are a bit different now, as WebKit also has support. I suspect this is due to the demands of ePub for e-books, where WebKit is popular, and vertical text for the Japanese market is a key feature.

writing-mode

The property you need to use is writing-mode. The specification includes three values. While WebKit supports these values, IE support predates the latest version of the spec, and instead uses the values that were used in an older version and originate from SVG 1.1. While this isn’t ideal, they map well and work more or less in the same way.

IE supports the writing-mode property with the -ms- prefix (IE 8+) and without (since IE 5.5 when prefixes were not common), while WebKit requires the usual -webkit- prefix.

horizontal-tb

The horizontal-tb value is used for horizontal scripts with a block direction that goes from top to bottom. This is the default value, so you probably don’t need to specify it, unless you’re overriding a previously set value.

You’ll notice that the horizontal part of the keyword doesn’t specify the direction of the line of text. This can be set (if it hasn’t been already) by the good old direction property. Left to right uses the ltr keyword, and right to left uses the rtl keyword.

For IE there are two different values. Instead of using the direction property to specify the line direction, it is specified in the writing-mode value. left to right, top to bottom uses the value lr-tb, while right to left, top to bottom uses rl-tb.

Here is an example setting left to right, top to bottom text. I’ve included all prefixes, so it will also work if IE updates it’s syntax or Firefox adds support:

-ms-writing-mode: lr-tb; -webkit-writing-mode: horizontal-tb; -moz-writing-mode: horizontal-tb; -ms-writing-mode: horizontal-tb; writing-mode: horizontal-tb;

While for right to left, top to bottom, the following code is needed:

-ms-writing-mode: rl-tb; -webkit-writing-mode: horizontal-tb; -moz-writing-mode: horizontal-tb; -ms-writing-mode: horizontal-tb; writing-mode: horizontal-tb; direction: rtl; /* not specified as part of writing-mode property in standard syntax */

vertical-rl

This is where things get fun. The vertical-rl keyword is used to make the line direction switch in vertical mode, with a block progression from right to left. This is the value you will want to use for vertical layout in CJK languages. You do not need a direction property here as there are no known languages that uses bottom to top lines (unless you’re mixing scripts, such as embedding Arabic inside CJK text, but that is a whole different story).

IE supports this using the older tb-rl value:

-ms-writing-mode: tb-rl; -webkit-writing-mode: vertical-rl; -moz-writing-mode: vertical-rl; -ms-writing-mode: vertical-rl; writing-mode: vertical-rl;

vertical-lr

If you want to use vertical Mongolian text, you’ll want to use the vertical-lr value, or tb-lr for IE. Lines go from top to bottom like CJK languages, but they flow from the left to the right of the page.

-ms-writing-mode: tb-lr; -webkit-writing-mode: vertical-lr; -moz-writing-mode: vertical-lr; -ms-writing-mode: vertical-lr; writing-mode: vertical-lr;

Writing-mode demos

You can see all four of these writing modes in action (if you're using a modern version of IE or WebKit-based browser) in my writing modes demo. I’ve used English text in each example, but you should get the basic idea. The right to left example may be confusing though, as the text (except final punctuation and list markers) looks left to right, but right aligned. The reason is that when using Latin characters inside right to left text, they keep their left to right orientation. This is known as bi-directional text, or Bidi, but that is a discussion for another day).

Although vertical layout is primarily for languages that are naturally displayed in this orientation, Latin-based languages can also sometimes be used vertically. Usually due to lack of available space, or for stylistic reasons. Think of the spine of a book, labels on the 𝑦 axis of a graph, or those fancy vertical signs you see run down the side of theatres and other such establishments. In all but the latter case, each glyph is usually rotated 90° clockwise along with the line, so that it is displayed on its side, rather than its natural orientation. That is the default behaviour when using latin characters in vertical text using CSS.

I’ve made a demo taking advantage of this behaviour, where I’ve rotated text in a table header to save horizontal space. View the writing-mode property support demo in WebKit or IE to see this in action.

One thing you should be aware of with the previous demo is that I had to add a span (or another element) inside the th for the vertical orientation to apply in WebKit. In IE this was not needed, but the header cell didn’t resize after rotation, leaving white space. I suspect it is a bug in both browsers, but with the way tables work, it is anyone’s guess (or at least, someone smarter than me about such things). The spec mentions that writing-mode does not apply to table rows, row groups, columns and column groups, but does not mention individual table cells. Adding an element inside the cell works in both browsers however, so this technique is viable if you don't mind an extra element.

Finally I’ve made a vertical text demo using Japanese text. Here you can see the vertical text writing mode used for it’s main intended purpose. Check out the Japanese vertical text demo in IE or Chrome.

The rules for vertical Japanese text are far more complex than I could ever hope to understand while working on this post, so there may be a number of issues that would look wrong to native eyes. After checking with Tomomi Imura, one such issue is with how the latin digits are rotated. In Japanese vertical layouts, these digits often keep their horizontal orientation, but with special rules, such as centring the glyph (central baseline in CSS terminology) rather than using the alphabetic baseline (the left edge of the line in top to bottom, right to left text). If two digits are found together, they are often combined side by side as if they were one glyph (know as tate-chu-yoko). While latin digits often keep their horizontal orientation, alphabetic glyphs can be rotated (as is the default) or keep their horizontal orientation. I’ve no idea what the rules are here, or if it is entirely stylistic. The main thing I have noticed is that runs of uppercase Latin characters are often set in the horizontal orientation, while lowercase characters are often in the sideways orientation. The next section will cover what we can and can’t do to correct these issues.

Changing the orientation of glyphs in vertical text

If you want to keep glyphs from scripts such as latin from rotating when in vertical mode, you can use the text-orientation property, with a value of upright:

-ms-writing-mode: tb-rl; /* old syntax. IE */ -webkit-writing-mode: vertical-rl; -moz-writing-mode: vertical-rl; -ms-writing-mode: vertical-rl; writing-mode: vertical-rl; /* new syntax */ -webkit-text-orientation: upright; -moz-text-orientation: upright; -ms-text-orientation: upright; text-orientation: upright;

This is currently only supported in WebKit browsers. You can check it out by viewing an updated version of the previous Japanese demo, using text-orientation: upright.

This property applies to all glyphs, but as Japanese characters are already in the horizontal orientation, you will only see a difference with the Latin characters.

As you may want to keep some non-Japanese characters in the default sideways orientation, it may be best to add spans around the glyphs you want to keep upright.

The eagle-eyed among you might notice an issue in WebKit browsers. While the digits are kept horizontal, they are still aligned to the alphabetic baseline, rather than centred to the central baseline. Chrome is also slightly clipping the text. Every glyph is also rotated, which is incorrect. Glyphs such as hyphens (-), and brackets and braces ({}()<>) should be left sideways, otherwise they look very odd.

While this is where support stops for this property in Safari, Chrome also supports the sideways and sideways-right keywords. The sideways-right value rotates the glyphs 90° clockwise when using vertical layout. This is the same as what is applied by default to horizontal scripts such as Latin. It will however also rotate glyphs that are usually displayed horizontally in vertical layout, which will probably look odd to anyone that can read those languages.

The currently unsupported sideways-left keyword rotates the glyphs 90° anti-clockwise. The text line is also rotated 180° as if the text is read bottom to top, instead of top to bottom. Think of how labels on the left hand side of the 𝑦 axis of a graph are often displayed.

Combining glyphs side-by-side in vertical text

While in vertical text glyphs progress down the page, rather than side by side, sometimes you may want to have two (or maybe more?) glyphs side by side, such as the aforementioned case where two digits are combined.

For that particular use case, we can use the following rule:

text-combine-horizontal: digits 2;

The digits 2 value (actually the 2 can be omitted, as it is the default), says that if two digits (U+0030–U+0039) or less are found in a row, combine them in the space used for 1 character (a width of 1em). Unfortunately, while this would solve our problem, it is not currently supported anywhere, to my knowledge.

The all keyword works the same way, but tries to apply it to the entire textual contents of the element. You can imagine that if you apply this to an element with more than a few characters, it is likely to not be able to do that. The spec says that it must try to fit the contents into 1em, but can use any method to do so. So I’m not exactly sure what would happen if the contents don’t fit. Craziness is my best guess.

The final value is none, which is the default. It is easy to imagine what this does (nothing, except default back to nothing if the element was previously doing something).

Some unexpected things to take into account when using vertical text

If you expect everything to work as if you just rotated the element and its children 90° using CSS transform rotate, then there are a number of things you should be aware about.

Height, width, and the box model

If you rotate an element 90° clockwise with a transform, the width of the element looks as if it is the height (width now goes from top to the bottom of the screen). With vertical text however, the width and height remain the physical width and height. That is, if you specify the width and height, the text lines will rotate when specifying vertical text, but the width and height of the element will stay the same.

Similarly, margin/border/padding-top will remain the physical top of the element, rather than the right side when an element is rotated 90° clockwise. A key difference here is margin collapsing. As text flows across the page, margin-left collapses instead of margin-bottom when using vertical-rl, and the right margin collapses when using vertical-lr.

The positioning properties such as top, right, bottom, and left also still refer to the physical edge of the element’s margin box. The top property still refers to the top edge, rather than switching to the physical right edge.

Text-align, vertical-align, text-decoration and floats

While the box model doesn't rotate, text-align, vertical-align, text-decoration and floats do. Left aligned text will become top aligned, right aligned text will be bottom aligned. As you may have guessed by now, float: left will float the element to the physical top, while float: right will float to the physical bottom.

Vertical-align: top will align to the physical right of the cell when using vertical-rl and the physical left of the cell when using vertical-lr. Similarly, the underline value of text-decoration will be drawn along the physical left edge of the line box using vertical-rl and the physical right side when using vertical-lr.

Due to the above, the vertical-align property is unfortunately named, as are the left and right values of text-align and float. For text-align, two new abstract keywords have been defined, named start and end. The start value is the equivalent of left and end is the equivalent of right (except when using the right to left line direction (e.g. Arabic or Hebrew), where start is right, and end is left). This makes their use less confusing, as they always apply to the start and end of the line box, no matter what orientation is being used. These are currently only supported by WebKit and Gecko. Similarly the abstract values for top and bottom are over and under respectively.

All of this might be easier to understand with a diagram, so here you go:

Abstract and physical dimensions and directions

Flow relative directions

The following diagrams show the mapping between the flow relative abstract (yellow) and physical (green) directions, as well as the dimensions of the element. The physical directions always stay the same, while the logical directions change depending on writing mode, direction and text orientation.

horizontal-tb ltr (left to right, top to bottom)

horizontal-tb rtl (right to left, top to bottom)

vertical-rl (top to bottom, right to left)

vertical-lr (top to bottom, left to right)

Line relative directions

The following diagrams show the line relative physical (blue) and abstract (yellow) directions. You will notice that the physical line-relative directions do change when the text orientation is flipped from sideways-right to sideways-left.

horizontal-tb (top: ltr, bottom: rtl)

vertical-lr and vertical-rl

text-orientation: sideways-right, direction: ltr

text-orientation: sideways-right, direction: rtl

text-orientation: sideways-left, direction: ltr

text-orientation: sideways-left, direction: rtl