Terminal protocol for borders between cells

[joshka]

Coming from the TUI side of things, something I see all the time is borders around things, and they're often done poorly. I'd love for a deeper border protocol (probably DCS) to be available that can be used in terminals to draw colored line segments between cells. There's some existing stuff around this already, but this should go deeper.

This enables:

• regions to be delineated better
• popups
• buttons
• text entry
• etc.

All places where colored background can not quite carry a good UX. a border comes in really handy.

I slopped together a prototype of this in rio and ghostty the other day. More to understand how this would look and feel, and I think it's really useful in ways that other approaches don't quite succeed with.

Anyway, leaving this here for some thoughts. Not a direct feature request as it's more of a "what if there was a protocol that we could agree on that does this" type thing. https://discord.com/channels/1005603569187160125/1320882404717625374/1550871492391076011 has a bit more detail on this. check there for prior art and DCS vs APC ideas.

https://github.com/joshka/ghostty/tree/joshka/cell-border-prototype is a working ghostty version of this (more screenshots on discord).

Curious about what people's thoughts are on this.

[j4james]

Can't see your discord link, so you may be aware of this already, but for prior art there's the DEC ruled lines protocol, which can be identified by extension number 43 in the device attributes report. I also recall some terminals using the SGR framed attribute for drawing borders, although I'm not sure that's technically a standard interpretation. The other SGR technique that's been used is a combination of the overline attribute along with the ideogram left/right side lines (can't remember what they used for the bottom border).

[00-kat]

If you want to access the Discord link, the invite's https://discord.gg/ghostty.

you may be aware of this already […] DEC ruled lines protocol

They seem to already know that one (Discord link).

[joshka]

yep - I want something a little deeper based on what we see in practice in tuis. there's lots of ways to sort of get borders, but none that are 100% good.

[jcollie]

Looks interesting to me, it's always bothered me that you loose 2 columns/rows because you want a border around some element. Main thing that I'd like to see is an option for rounded corners. Bonus points for a configurable radius.

[joshka]

yeah, I thought a bit about that, but kept it out of a prototype for a first cut intentionally. But it's a good thing to add to this.

One concern I have is that it makes things a little more complex as there's lots of "... and this" to add. Slippery slope :)

The other is that it doesn't compose well with any existing unicode blocks, so if you're dealing with background colors then you still get that little chunk at the corners which is colored wrong, and that is a much more difficult thing to handle. It's the same problem effectively that we have now with unicode border characters, just for a shape instead of all the borders.

But this actually makes me think about something else that would be good to add or a more general form for this. Right now to get a half cell border around some text you add half blocks on top bottom and full blocks left right. What if instead there was something that was more region aware for dealing with extending a background and having a border around it somehow. Obviously a bit more of a different idea than this, but also worth considering. the core of this is how the fg/bg/ and border interact in a cell, but I hadn't considered that extending a cells rendering influence to nearby cells may be a way to address this in a way.

[identity-wael]

[Removed by author.]

[joshka]

Draw only one side of a boundary, then draw a conflicting style from its neighbour. Which wins?

Yeah, that's a difficult one - likely has to be either last write (which means storing this as a linear thing, or top/bottom, left/right precedence. Solvable - no strong preference.

Scroll a region containing half a bordered box. Do the edges move with cells, clip to the scrolling region, or belong to a separate anchored object?

Fixing scrolling properly to deal with the fact that people want to do interactive things in the main part of the pain and dead things in the scrollback is also something I think should be eventually done, but for this one I'd keep it simple (and look for two ways doors in the initial cut). Borders scroll with the content.

Erase a cell, overwrite it with a wide character, or insert/delete a line. Which borders survive?

Erase - none (but define erase?)
Wide char - that's sort of why I want this to have a z-index because you might want this over or under wide chars depending on what the idea on this, likely default over
insert - pushes down
delete - borders are owned by the line that they are defined in, not the gap between them

Enter/leave the alternate screen and resize/reflow. How is stale decoration cleared?

Borders aren't a screen thing, they're a cell thing, cleared and restored (obv. there's some mechanics on that that probably make this difficult)

I'd lean toward cell-associated edge attributes for the first version, with an explicit conflict rule and an erase/reset operation. Region objects may help with rounded corners/background extension, but introduce lifetime and anchoring semantics that cell attributes can avoid.

Yeah, I want regions for other reasons - accessibility, and making areas have things like wrapping, character wrapping, updatable scrolling, access to updates in scrollback, ... future considerations, not part of this so much.

Capability negotiation also needs to be specific enough that a TUI can fall back to ordinary box-drawing characters through an unsupported terminal/multiplexer, without spending a column twice when support is present. Defining those lifecycle cases would make the prototype much easier for another terminal to implement consistently.

Absolutely agree.

There's definitely a bunch of edge cases (pun intended) to this, but I think they're all things that can have fairly reasonable solutions and where there's multiple options, picking one fairly arbitrarily can work (or supporting both with config). The details on this were not where I was coming from, more the can this work, can it make a good UI that's better than what's possible currently without devolving into something significantly deeper. I think the main thing here is that people see it and say I want that enough to engage in making it a proper protocol. The ability to slop code something in 7 mins (in rio at least, ghostty was 17 - go figure), makes doing a quick prototype that works and then fleshing out the full details a pretty reasonable approach for this sort of thing.