Vertical typography with CSS sideways writing modes

Vertical typography with CSS sideways writing modes opens new possibilities for multilingual layouts, particularly for East Asian scripts and creative typographic treatments. Authors can control the flow of lines and the orientation of glyphs to produce readable vertical text without resorting to image assets or complex markup.

This article explains the key CSS properties and related platform details you need to use sideways and vertical modes safely in production: writing-mode, text-orientation, text-combine-upright, OpenType features, shaping engines, browser rollout of vertical form controls, and practical accessibility and fallback advice.

How writing-mode and text-orientation interact

The writing-mode property controls line and block flow. Values such as vertical-rl and vertical-lr make lines run vertically; the newer sideways-rl and sideways-lr variants rotate the entire glyph run so that each glyph remains in its usual upright orientation but the line direction is changed. Sideways variants are defined in the CSS Writing Modes spec and are intended for cases where you want glyphs to rotate together with the line.

text-orientation controls how individual glyphs appear inside vertical lines. Its values are mixed, upright and sideways. Crucially, text-orientation only affects vertical typographic modes: it has no effect for horizontal writing-mode values. Use text-orientation: upright to keep Latin letters and digits upright within a vertical CJK run, or text-orientation: sideways when you want glyphs rotated to match a sideways line.

Together, writing-mode and text-orientation let you choose both the flow of blocks and the orientation of glyphs inside those blocks. Remember that these properties govern presentation only and that some script direction and bidi interactions require additional handling (unicode-bidi, direction) for correct results with RTL scripts in vertical contexts.

What the specs say (Writing Modes Level 3 & 4)

The CSS Writing Modes Level 3 and Level 4 specs define the semantics for vertical-rl, vertical-lr, sideways-rl and sideways-lr, and for text-orientation values mixed, upright and sideways. The specs also document implementation concerns: for example, upright can force used direction to ltr in many implementations, and user agents may accept aliases like sideways-right.

The spec notes real-world caveats: authors should not rely on automatic LTR treatment of RTL characters in upright typesetting in many UAs. In practice this means you may need explicit unicode-bidi and direction overrides for some RTL scripts when using text-orientation: upright. The spec also records that UAs have historically diverged on sideways support and glyph rotation behavior.

If you need the normative behavior, refer to Writing Modes Level 3/4 for details on value semantics and expected interactions with other CSS features. The spec is also the source for implementation notes and recommended authoring patterns for bidi in vertical contexts.

Browser support, the history of “sideways”, and compatibility

Browser support for vertical typography has matured significantly. Can I Use reports that css-text-orientation has broad modern support , roughly 96.3% global support at the time of checking , which is a useful starting metric when deciding production fallback strategies. For precise per‑browser and per‑version coverage you should consult the Can I Use version matrix.

The sideways values have a history of staggered implementation. Firefox added robust sideways support around version 44, and Chrome, Edge and other Chromium-based browsers implemented sideways support later. For exhaustive version-by-version detail see the sideways-specific page on Can I Use or your browser vendor release notes.

Because behavior and exact support vary by version, use the combination of global percentages (quick decision), Can I Use matrices (version detail) and W3C i18n-tests (behavioral pass/partial/fail data) to decide whether to use native vertical/sideways features or provide transform-based fallbacks in legacy environments.

Vertical form controls and replaced content

A major interoperability effort in 2024 added vertical writing-mode support for form controls. WebKit announced vertical writing-mode support for form controls in Safari 17.4 on Mar 18, 2024. As WebKit put it: “By adding vertical writing mode support for form control elements in Safari 17.4, we hope to empower authors to create the best content for their local and global communities.” This change lets inputs, buttons, selects, progress, meter, range and textarea participate in vertical layouts more naturally.

Chromium documented its own rollout in a Jan 15, 2024 post: “Vertical writing mode for form control elements means that these elements can be displayed in vertical writing modes. By Chrome 123 the feature will be enabled for all users.” Together these vendor rollouts complete a major interop step so native controls behave predictably in vertical flows.

Note that writing-mode does not automatically rotate replaced content such as images or iframes; and some OS-provided controls may still be rotated visually while others are custom-painted for vertical support. Check vendor docs for which elements were rotated versus re-rendered for vertical support in each browser.

OpenType features, shaping engines and glyph rotation

Fonts and layout engines play a major role in how vertical text looks. OpenType provides vertical-specific features such as vert, vrtr, vrt2, vkrn and vpal. The vrt2 feature (Vertical Alternates and Rotation) supplies pre-rotated glyphs for vertical writing and is often used for glyphs that require different shapes or metrics in vertical runs.

Shaping engines like HarfBuzz define default feature sets for vertical runs (for example enabling vart, vert, vkrn, vpal, vrt2 in various combinations). Those choices impact whether Latin letters or Katakana appear rotated or upright in vertical text and whether metrics are adjusted for better line fit. If you rely on a specific vertical glyph shape, test with the fonts and engines used in your target UAs.

Additionally, text-combine-upright is widely supported and lets you pack multiple characters (often digits or initials) into a single vertical character cell. This is important for CJK vertical typesetting where compact dates or acronyms are common. Web-Platform Features and MDN provide compatibility details for these features.

Practical authoring rules, accessibility and fallbacks

Practical rules: text-orientation only applies when writing-mode is vertical. A common pattern is:

writing-mode: vertical-rl;
text-orientation: upright;
text-combine-upright: all; / optional for compact digits/initialisms /

This keeps Latin text upright inside a vertical CJK block and packs digits when desired.

Be careful with RTL scripts in upright vertical runs. The spec warns that major implementations historically do not support automatic LTR treatment of RTL characters for upright typesetting; authors may need explicit unicode-bidi and direction overrides for Hebrew or Arabic. Test bidirectional vertical text thoroughly, and consult the W3C i18n test-suite for pass/partial/fail results across UAs.

Accessibility: CSS writing-mode is a visual presentation , screen readers typically read DOM text in logical order regardless of visual rotation. However, some UA and assistive technology combinations have shown edge-case interactions with heavy transforms or typographic transforms. Use semantic HTML, correct lang attributes, ARIA where appropriate, and test with your target screen readers and platforms to ensure a good experience.

Production decisions and testing checklist

When deciding whether to adopt vertical or sideways layouts in production, follow a short checklist: check Can I Use for global support percentages and per-version matrices; consult W3C i18n-tests for detailed behavioral differences (especially for CJK bidi and text-combine-upright); and validate font behavior via OpenType features and shaping engine behavior in your target browsers and OSes.

If you need to support older UAs that lack sideways or text-orientation features, consider graceful fallbacks such as transform: rotate(…) on containers, or serve alternative CSS for legacy browsers. Remember that transform-based rotation alters the visual orientation but does not enable true vertical typographic features like text-combine-upright or OpenType vertical alternates.

Finally, build automated visual regression tests and manual checks for replaced content, form controls and accessibility. The combination of MDN live examples, vendor blog posts, and the W3C test suite will help you validate behavior across the target matrix of platforms, browsers, fonts and assistive technologies.

In short, vertical typography with CSS sideways modes is production-ready in many contexts, but it requires careful testing: across browsers and versions, with your fonts and shaping engines, and for accessibility-sensitive flows.

For further reading and interactive tests consult MDN (writing-mode, text-orientation, vertical form controls), the W3C CSS Writing Modes Level 3/4 specs, the W3C i18n-tests pages, Can I Use for version matrices and OpenType docs for font-side details such as vrt2 and vert features.