Alt text and media types for preformatted text

[Thomas Frohwein]

On Mon, Mar 01, 2021 at 07:48:56PM -0500, Sean Conner wrote:
> It was thus said that the Great Nathan Galt once stated:
> > 
> > 
> > On Mon, Mar 1, 2021, at 1:24 PM, Sean Conner wrote:
> > > 
> > >   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.
> >
> > 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 recall, escape codes where *never* in any of the specifications, just
> an oversight when documenting the format (aka "loophole").  
> 
> > 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).
> 
>   I'd ban control codes in a heartbeat (except for HTAB, CR and LF as
> stated), but I'm not sure how popular that decision would be.

I would support it. I think this step would work best if coupled with
best practices or code example for clients to identify and ideally
remove or warn/error if encountered. The client that I'm working on is
ncurses-based and doesn't support escape codes for that reason. But
maybe a visible difference to text without escape code would be enough
to weed out existing escape code hacks. A simple way would be to guide
clients to how to print the escape codes as plain text rather than
processing them. Could probably come up with a simple regex/tr to get
started...