💾 Archived View for rawtext.club › ~sloum › geminilist › 005832.gmi captured on 2024-03-21 at 16:37:10. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Nathan Galt mailinglists at ngalt.com
Tue Mar 2 00:00:15 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Mon, Mar 1, 2021, at 1:24 PM, Sean Conner wrote:
It was thus said that the Great Thomas Frohwein once stated:
On Mon, Mar 01, 2021 at 10:12:18AM +0000, Caolan McMahon wrote:
[...]
2. Knowing the content type upfront would allow clients to present streaming
data correctly using appropriate colours and escape codes for code
highlighting, for example.
A solution to a problem of its own making.
Sorry, I don't follow this point.
IMO escape codes are a hack, and universal client support can't be
expected. In fact, those may break different terminal/client types.
I think color escape codes should not be considered expected with
clients. In fact, there should probably a discussion if this should be
discouraged in the spec.
I've talked on this before (several times in fact) and my stance is that
controls codes aside from HTAB, CR and LF should not be used in text/gemini.
There's the issue that "color escape codes" are an artifact or side effect
of a terminal-based Gemini browser and it can't be relied to even exist in
the graphical browsers that are popping up. Then there's the security
issue---there are escape codes that can reprogram the keyboard, and although
the usage is rare, it is possible. There are also escape codes that can
resize the window and reposition the window, and there's no telling what
state the terminal can end in.
While I would like to disallow control codes in the specification, that
might be too big of a change, and *will* affect some sites, but adding
verbiage that discourages it can be added.
-spc
Perhaps this is the wrong way to frame this, but you're prioritizing backwards compatibility on a pre-1.0-spec to support an unintended hack that has security issues?
If I had control codes on my capsule, I'd grumble a bit, sure, but I'd remove them. I'm not sure it's worth it to shield the tiny handful of **current** capsule operators from some search-and-delete work compared to all the future client implementors who'll face at least some pressure to implement color support (and, if they're actual terminal applications, open their users to keyboard-reset exploits).