Terminal Borders That Don't Cost a Cell: A Low-Cost Rendering Technique Explained

The "Cell Tax" Problem with Terminal Borders

Drawing borders in a terminal interface looks simple, but it carries hidden costs. The traditional approach builds borders from characters (like -, |, +), and these characters occupy real character cells, squeezing content space. For terminal applications that pursue compact layouts, this "cell tax" directly affects information density.

In the article Terminal borders that don't cost a cell, Joshka proposes an idea: leverage terminal rendering characteristics so that borders don't consume extra cells. The article earned 324 points and 141 comments on Hacker News, showing that this problem strikes a chord with many developers.

The Core Principle of Cell-Free Borders

Using Background Colors and Half-Block Characters

Terminal cells are the smallest unit of rendering, but through background colors and special characters (such as the half-block characters ▀ and ▄), you can simulate line effects without increasing character footprint. The visual thickness of the border can be achieved through background color contrast, while the characters themselves only "indicate" rather than "fill."

Half-block characters are characters in the Unicode Block Elements block (U+2580–U+259F), such as ▀ (upper half block, U+2580), ▄ (lower half block, U+2584), and █ (full block, U+2588). When a terminal renders these characters, it fills a proportional region within a single character cell with the foreground color, and the portion not covered by the foreground displays the background color. Therefore, by combining "the foreground color of a half-block character + the cell's background color," you can present two colors (top and bottom) within a single cell, thereby drawing two visual border lines with one column of characters. This is precisely the key to why borders that don't increase footprint are possible: the border's "thickness" is provided by color regions rather than additional characters.

It's worth noting that the rendering of half-block characters depends on the terminal font's support for block elements. Most monospaced fonts render them reliably, but some fonts or terminals may exhibit alignment deviations or blurriness caused by anti-aliasing.

Sharing Cells with Content

A more radical approach is to let the border overlap with content: the border is drawn on the edge pixels of content cells rather than on independent character positions. This requires the terminal to support fine-grained background color control, and the application layer needs to precisely calculate the drawing region. Joshka's exploration shows that in common terminal emulators, this overlapping border style is visually acceptable and can save a significant amount of horizontal space.

TUI (Text User Interface) refers to terminal application interfaces that use a character grid as their canvas and interact through keyboard or mouse, commonly seen in tools like htop, ranger, and tmux. Unlike GUIs, TUI layout units are character cells, with both horizontal and vertical space counted in "columns" and "rows," so every column gained or lost directly affects information density.

TUI frameworks (such as Ratatui, Textual, and Bubble Tea) typically provide abstractions for borders, padding, and layout splitting, but they still map to the character grid underneath. Understanding this helps determine the applicable boundaries of "cell-free borders": it essentially bypasses the framework's default border model and directly manipulates cell background colors and edge characters, so it often requires the framework to provide low-level style or custom rendering interfaces.

Implementation Details and Trade-offs

As discussed in the original article, this approach is not zero-cost. It relies on stable terminal support for ANSI background colors and character rendering, and cross-terminal compatibility requires additional testing. In the Hacker News comment section, some developers pointed out that border flickering or color bleeding can occur in certain terminals, while others argued that increasing rendering complexity to save a single column of space may not be worth it.

Joshka's stance leans practical: for TUI-intensive scenarios, every column of space is precious, and this technique is worth adding to the toolbox. The article provides reproducible code snippets and terminal effect comparisons so readers can verify for themselves.

ANSI escape sequences are the standard mechanism for controlling colors and cursors in terminals. Background colors are typically set through SGR (Select Graphic Rendition) parameters, for example \x1b[48;5;Nm specifies a 256-color background, and \x1b[48;2;R;G;Bm specifies a true-color background. The border approach relies on terminals correctly parsing these sequences and rendering background colors at the cell level.

Different terminal emulators (such as iTerm2, Windows Terminal, Alacritty, and kitty) do not fully agree on true color and Background Color Erase (BCE) behavior, which is the root cause of cross-terminal compatibility issues. Some terminals may leave residual background color during scrolling or redrawing, manifesting as color bleeding or flickering. Before adopting this technique, developers should confirm the target terminal's rendering consistency for SGR background colors and block characters.

Implications for Terminal UI Development

Terminal UIs have long been constrained by the character grid, with borders, padding, and separators all competing for the same set of cells. Joshka's approach reminds us that treating the terminal as a pixel canvas rather than a pure character matrix can open up new layout possibilities. However, this kind of "visual hack" requires weighing maintainability and compatibility, making it suitable for scenarios with extreme space requirements rather than all terminal applications.

For developers building CLI tools or TUI frameworks, it's advisable to validate the effect in a small prototype first before deciding whether to promote it. After all, the cells saved by borders must ultimately serve content readability.

One-line Summary

Using background colors and half-block characters to let terminal borders avoid consuming extra character cells.

Paragraph Summary

The article discusses the "cell tax" problem of borders occupying character cells in terminal interfaces, and introduces a border approach proposed by Joshka that doesn't consume extra cells. Its core principle is to use terminal background colors and half-block characters (such as ▀ and ▄) to simulate lines within a single cell, or to let borders share cell edge pixels with content. This approach can save horizontal space but relies on stable terminal support for ANSI background colors and character rendering, and cross-terminal flickering or color bleeding may occur. The article argues that this technique has practical value for space-sensitive TUI applications, but requires weighing rendering complexity and maintainability, making it suitable for validation in small prototypes first.