About this project
Where this came from
Vertically Works began with a typeface. Baram, Yong Jae Lee’s Korean font from 2015, was crowd-funded and designed natively for vertical setting. It showed me how much labor hides inside a script: a Korean typeface needs more than 3,350 glyphs before it can say anything at all. Print spent centuries refining vertical typography. Screens started horizontal and stayed there.
In 2019, I turned the itch into an essay and a set of scrappy explorations asking one question: can vertical type work in user interface? The honest answer at the time was that nobody knew. The components you would need to find out did not exist.
The question outlasted the essay. Every few months I came back to it and hit the same wall: you cannot study vertical interaction with horizontal parts. So, eventually, I built the parts.
Vertically Works is the result · components built on true writing-mode: vertical-rl, applications that put them under real load, and open questions documented as carefully as the answers.
· Jihoon Suh, New York
Questions
Isn't most digital CJK text horizontal anyway?
Yes · and that is part of the point. Korean went almost entirely horizontal within living memory; Japanese and Chinese screens default to horizontal too. But vertical setting never died: novels, manga, scripture, newspapers, calligraphy, signage. Today the axis is chosen by the toolchain, not the designer. Horizontal is a default, not a conclusion. This project exists so the choice can be real.
Why not just rotate existing components?
Rotation transforms pixels, not behavior. A rotated toggle animates on the wrong axis. Rotated text stops being text: selection breaks, screen readers announce the wrong order, IME composition falls apart. Everything here is built on true writing-mode: vertical-rl, so text stays selectable, searchable, and accessible · and motion, focus, and gesture are redesigned for the axis rather than spun ninety degrees.
Does this work with keyboards and screen readers?
It is the hardest part, so I build it in from the start. I remap the arrow keys · next character is down, next line is left · focus traverses columns right to left, and every duration collapses to zero under prefers-reduced-motion. Each component documents its accessibility behavior. What remains unsolved is listed openly in Challenges, not hidden.
Can I use this in production?
The components are MIT-licensed source you copy and own, with zero runtime dependencies · nothing to lock into, nothing to break under you. The system itself is young. Treat it the way you treated early shadcn/ui: read the source, adapt it, and file what you find.