Imagine a version of vterm that would extend the vt100 cursor control so that you could express subscripts and superscripts in something like H\e[0.5B2\e[0.5AO to produce H_2O.

Riley S. Faelan

Imagine a version of xterm that would extend the vt100 cursor control so that you could express subscripts and superscripts in something like H\e[0.5B2\e[0.5AO to produce H₂O.

Woozle Hypertwin

@riley I want a text-oriented terminal app that will render HTML.

(No, seriously. I've been brainstorming design ideas for some weeks now.)

Riley S. Faelan

@woozle How do you mean, HTML ? Raw HTML as its primary input language, or interpret HTML if escaped into a special mode, or a set of control sequences that HTML could be easily transalted into, or something else? And would you restrict it to 'inline HTML', or also have support for block elements such as buttons and iframes?

Woozle Hypertwin

@riley That question -- escaped or default -- is one of the big ones. Either way is workable, but they offer differing amounts of backwards-compatibility (with existing utilities).

There's also the question of continuous-scroll vs. page-oriented.

I'm thinking the easiest way to start would be to default to normal TTY behavior, but when valid HTML is encountered it should be rendered as such.

...and it would mainly be... well, not "inline" so much as in-flow -- tables and images should be supported, as well as HTML input methodology (buttons, drop-downs, links).

Riley S. Faelan

@woozle FWIW, I would be interested in developing a set of escape sequences that would allow (roughly) DOM-structured interaction patterns to be implemented in a virtual terminal, for one of my many would-be-fun-if-I-had-copious-free-time neoretrocomputing projects. Sort of doing the IBM 3270 thing, but doing it right.

Woozle Hypertwin

@riley That would work too -- but if one is going to the trouble of writing (/forking) one's own terminal program, why use escape-codes when there are much better formats to use for conveying that type of information.

David JONES

@riley according to Wikipedia, mintty supports SGR 73 and 74 for super and subscripts. A lot of 1980s printers supported half-line movement in some way, so I'm surprised there aren't more common codes for it.

Riley S. Faelan

@woozle Probably stylistic preference. I'm aware of pre-ASCII systems, from an era before escape sequences, interpreting raw text in interesting and useful ways, such as the early IBM high-speed printers' templates for placing data fields on a page while mailmerging, but it doesn't feel right to me, the way using explicitly invisible escape sequences does.

That having been said, I'm not wedded to the sequences having to be ANSI-based. Doing HTML with ctrl-[ and ctrl-] serving the rôle of classic HTML's brokets would seem to be okay to me, for an example of a hybrid system.

Woozle Hypertwin

@riley Sure, that's a reasonable way to make it more rigorous/explicit. You could even have codes that just mean HTML mode on/off.

...and I just now realized that there's one feature I want which is not supported by HTML, which is the ability to update text in specific places (e.g. you have a table showing status information, and you want to update the information as the program executes).

...so part of this isn't just "render HTML please and thank you" but more HTMLesque-but-also-interactive markup.

Riley S. Faelan

@woozle FWIW, among the many overly explicit control codes of the original ASCII that have kind of become obsolete because computers didn't develop the way the 1960s' people thought they would is the SI / SO pair. Its original purpose will not be coming back in a Unicode world, so it might be particularly fitting to be repurposed for switching between an HTML and a plain text mode.

Woozle Hypertwin

@riley That could actually be a useful detail to keep in mind!

...and now I'm mentally redesigning HTML to support retroactive updates to already-visible elements...

I'm thinking that some the ideas used to enable JavaScrpt to do this could also work in this context (where the "script" is all server-side, not in-client).

I also need to not get muddled between this idea and my older idea for an interactive replacement for HTML. ...or are they actually two pieces of the same goal? Hmmmm...

Riley S. Faelan

@woozle HTML includes 'entities' for representing the concept of things defined out-of-line, although in the original vision, typically before they appear What if they would be reimagined as dynamic placeholders that could be redefined after they appear?

YOU NOW HAVE &grain; BUSHELS OF GRAIN IN STORE

...

&grain = 2000;

Riley S. Faelan

@woozle and btw, reading up on the FrameMaker's manual might be a useful source of insights into these matters.

Also, SGML and its contemporary alternatives.

Woozle Hypertwin

@riley I was thinking more along the lines of the "id" attribute -- so if the HTML received contains a tag with the same attribute as an existing tag (of the same type, I guess), then that tag's contents and details replace the older one.

...but also, it would be nice to have in-text variables. I was always planning to implement that in my CMS, but why not make it an intrinsic part of the markup? (I mean, maybe there's a good reason why not, but it seems worth asking the question.)

I guess existing (pre-defined) HTML entities could be treated as constants whose value cannot be modified later... but what syntax would you use for modifying them, since that was never part of the HTML spec?

Riley S. Faelan

@woozle Speaking of attributes, I firmly believe that HTML missed the mark by not implementing <.foo> for what it ended up calling <span class='foo'> and <#foo> for what it ended up calling <span id='foo'>. If I were to reimagine HTML that has ids, I'd want <#foo> and <em#foo> supported, and if there's classes, then <.foo> and <em.foo>.

Riley S. Faelan

@woozle Original entities were always supposed to have an ampersand, a name, and a semicolon. Lax customs of late 1990s' browsers, especially one Intur-neth Exploder, made the semicolon "optional", but this doesn't have to be the case.

If the semicolon is not optional, then putting other things before the semicolon, such as &fruit = pears; or maybe SmallTalk-style &fruit: pears; becomes unambiguous. You might need to implement some sort of escaping if you wanted to allow other entities to appear in the RHS of such assignments, though.

Alternatively, consider <&fruit>pears</&fruit>.

Woozle Hypertwin

@riley I'm game for rebuilding some of that stuff.

My big WTFs were:

[1.] Why can we do

<img src={url} />

...to insert an image, but not...

<span src={url} />

...to insert text?

[2.] Why is it

<a href={url}>display text</a>

...but not...

<img href={url} />

?

Riley S. Faelan

@drj The catch is, the half-line movements have almost always been associated with moving the physical media. ESC/P defines such, for an example, but if scrolling the paper by half a line causes the sheet to be ejected, you won't get to scroll it back by half a line (and many printers didn't support backwards scrolling in the first place; it kind of became a plotters' thing instead).

There's an important exception, though: ChiWriter.

Woozle Hypertwin

@riley That works! The & - ; pair then becomes a sort of value-markup indicator. ...but of course then you have to decide how escaping will work (if you want to be able to use ";" in your value).

Riley S. Faelan

@woozle Well. These questions have answers, but they're ... not as good as you might hope for.

Early on, fetching a thing from a server was considered an expensive operation. It was less expensive via Gopher than via HTTP, but still. Embedding one HTML "document" inside another was just seen as overly extravagant.

By the time somebody had realised that HTML could be used to make web applications (and computers had gotten a couple of Moore doublings faster), embedding got a big thing, but by then, the influential browsers supported scripting, and the question of "What if there's scripts in the embedded "document" ?" immediately arose. So, browser designers tried to define embedding in ways that would provide a degree of "security" against the sort of vulnerabilities we now call XSS. Their first attempt was the <layer> mechanism (if you consider <frame> and possibly <iframe> the zeroth attempt).

Layer support was extremely flaky between browsers, so the World Wide Web Consortium set out to define a replacement in strict and relatively unambiguous ways. After several decamelations of the camel, that's what we now call <div>, and <layer> and <ilayer> have been officially considered obsolete for many years. The src attribute of <layer> got taken out by a forgotten committee somewhere on the way.

As for images, clickable image elements really used to be a thing in late 1990s' HTML. These were called 'image maps', and, later, when there was another kind, 'server-side image maps', and defined by the ismap attribute to the img element. I'm not sure if it has been officially obsoleted, but because of the rise of client-side JavaScript, it's not nearly as popular anymore as it used to be.

For some meditation on how different early HTML used to be, consider the isindex element, conceived in an era when people genuinely thought that the only kind of form that one might want to fill in on the World-Wide-Web was a search engine.

Imagine a version of vterm that would extend the vt100 cursor control so that you could express subscripts and superscripts in something like H\e[0.5B2\e[0.5AO to produce H_2​O.

Imagine a version of vterm that would extend the vt100 cursor control so that you could express subscripts and superscripts in something like H\e[0.5B2\e[0.5AO to produce H_2O.