I’ve gone on record many times actually praising browsers as a model terminals should strive for (but, explicitly, at a much smaller surface area). I think browsers have gone too far on the spectrum towards OVER-THE-TOP application platform and terminals have gone too far on the spectrum towards STAGNANT application platform.
My explicit goal with my terminal projects from the beginning has been to push that forward. I think my original talk I ever gave on Ghostty 3 years ago I said something like: browsers ship hundreds of features per year, I’d like terminals to ship like 10.
Of course, I’m sure some people will disagree. And that’s fine, stay away from my projects and use something like xterm (which is fantastic and is our ground truth for historical specs).
Sure, to each their own. I’m also not criticizing your work, I’m just saying “I don’t want this.”
I think browsers suffer because their features are not user-driven, and competition is very hard because of the huge surface area that needs to be implemented. I don’t want terminals to suffer the same fate, or go down a heavily feature-fragmented route. They are by design meant to interact with an environment where this type of feature coverage can be implemented by combining tools (think UNIX philosophy), defining “the one true way” in the terminal is antithetical to that.
Just look at the many “this only works in Chrome” sites. That is not the path we should go down here.
I’d like terminals to ship like 10.
Speaking personally: please don’t. But if you insist, I think better a11y would actually benefit a good number of humans significantly.
The best way to fix a11y is to ship MORE terminal specifications that are higher level. Right now one of the reasons a11y is so bad/hard in terminals is because a grid of opaque non-semantic cells is very difficult or impossible to reliably map to the semantic needs of a11y tooling.
If we can ship more specifications that help elevate semantic state – such as program status! – but also things like semantic prompts (OSC133, not my spec), hyperlinks (OSC8, not my spec), progress (OSC9;4, not my spec), buttons, designated input areas, etc. Then we can start clearly mapping this to a11y state.
Background on this one: I spent a day (just one day, but a full one at least) with the UW HCI lab that was doing a project on terminal a11y and we were able to brainstorm a lot of the shortcomings here based mostly on their far more experienced background. They were experts on a11y technologies and I was the terminal expert.
I think here we’d have philosophical differences.
I’ve gone on record many times actually praising browsers as a model terminals should strive for (but, explicitly, at a much smaller surface area). I think browsers have gone too far on the spectrum towards OVER-THE-TOP application platform and terminals have gone too far on the spectrum towards STAGNANT application platform.
My explicit goal with my terminal projects from the beginning has been to push that forward. I think my original talk I ever gave on Ghostty 3 years ago I said something like: browsers ship hundreds of features per year, I’d like terminals to ship like 10.
Of course, I’m sure some people will disagree. And that’s fine, stay away from my projects and use something like xterm (which is fantastic and is our ground truth for historical specs).
score 1 · canonical
Sure, to each their own. I’m also not criticizing your work, I’m just saying “I don’t want this.”
I think browsers suffer because their features are not user-driven, and competition is very hard because of the huge surface area that needs to be implemented. I don’t want terminals to suffer the same fate, or go down a heavily feature-fragmented route. They are by design meant to interact with an environment where this type of feature coverage can be implemented by combining tools (think UNIX philosophy), defining “the one true way” in the terminal is antithetical to that.
Just look at the many “this only works in Chrome” sites. That is not the path we should go down here.
Speaking personally: please don’t. But if you insist, I think better a11y would actually benefit a good number of humans significantly.
score 1 · canonical
I have another comment on here about a11y… please see my comments for that full context. EDIT: Here it is https://lobste.rs/s/ifbdw1/text_mode_lie_why_modern_tuis_are#c_awixrd
The best way to fix a11y is to ship MORE terminal specifications that are higher level. Right now one of the reasons a11y is so bad/hard in terminals is because a grid of opaque non-semantic cells is very difficult or impossible to reliably map to the semantic needs of a11y tooling.
If we can ship more specifications that help elevate semantic state – such as program status! – but also things like semantic prompts (OSC133, not my spec), hyperlinks (OSC8, not my spec), progress (OSC9;4, not my spec), buttons, designated input areas, etc. Then we can start clearly mapping this to a11y state.
Background on this one: I spent a day (just one day, but a full one at least) with the UW HCI lab that was doing a project on terminal a11y and we were able to brainstorm a lot of the shortcomings here based mostly on their far more experienced background. They were experts on a11y technologies and I was the terminal expert.
score 1 · canonical