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.

[riley@toot.cat]

@woozle My intuitiion is to use paren-like escaping, and, of course, the paren-like thing in HTML are elements, so &fruit = <span>apples; bananas; cucumbers</span>; seems neat to me.

The catch is, HTML DOM has some imperfect nesting rules. Entitities are allowed to appear inside attributes, but attributes can only contain plain text (or something called CDATA or PCDATA), but not other elements, so allowing element tags in the RHS of an entity assignment becomes problematic.

But, well, then there's &fruit = <![CDATA[ apples; bananas; cucumbers ]]>;.

Personally, I find the whole CDATA business an ugly hack, and I'd probably advocate for an alternative, parenthesised, notation, something like &fruit [apples; bananas; cucumbers];. (As you can see from the <!CDATA[ crap, brackets actually have a sort-of ancient sometimes-leaking-through special meaning in HTML; round parents don't.) But I can sort of see some people arguing that this falls too much into how one would design wikimarkups, and is not really in the True Original Spirit of HTML, and, perhaps, prefer to escape the semicolons as &#x3B;, or maybe just as ;.

[woozle@toot.cat]

@riley Agreed on all points, I think. I have no intention of trying to be fully backward-compatible, especially with more obscure stuff. Data should be importable (and reusable) with, like, a <data id={string} src={url} format={xml|json|?}> kind of thing.

...and if there ever were to be client-side scripting and style markup, they would be XML-compatible and not their own separate syntaxoids.

[riley@toot.cat]

@woozle Do I get to postulate a conspiracy of the Unicode Consortium being biased towards big multinational corporations, and against Little People's power? :blobcat_thisisfine:

[woozle@toot.cat]

@riley If you broaden "conspiracy" to include "org listens more intently to the people with the money", then I don't think there's anything controversial about this hypothetical postulation.

[riley@toot.cat]

@woozle By late 1990s, the difference between isindex and input was, isindex let you get queries via URLs on the order of http://blabla/?value, and input insisted on it being http://blabla/?name=value.

[riley@toot.cat]

@woozle Oh, and isindex is compatible with Gopher.

[woozle@toot.cat]

@riley I mean, if you have more than one thing, then they need to have names; if you only have the one, then it can just be The Query.

[riley@toot.cat]

@woozle Or you could leave the name field of an input element blank, causing it to function in an isindex-like way. Possibly with the exception that if you have multiple, you won't get http://blabla/?first+one+second+one+third+one but http://blabla/?first+one&second+one&third+one.

[riley@toot.cat]

@woozle While we're on the topic, I'd want <radio#colour=blue> instead of <input type='radio' name='colour' value='blue'>.

[riley@toot.cat]

@woozle The name/id distinction is a thing in the real HTML, but we won't have to carry it over during the reimagination.

[woozle@toot.cat]

@riley That too would make sense.

Seems I was born
with too many choices.
Now what am I going to do
with all these extra things,
as they serve to confuse me, really.

-- James Taylor

[riley@toot.cat]

@woozle In the context that I imagined doing "smart" terminals, I'd leave all sort of scripting out of the context of the project. If something happens, such as the user clicks on a radio button, the terminal side can make the visual change, but report the change as 'input', and if, say, the amount of predicted bushels of grain that Hamurabi von Sumeria will have left over by the end of the year needs to be recalculated, then it's up to the 'server' side to issue the appropriate &grain = whatever; update.

[woozle@toot.cat]

@riley That's my default thinking, yeah.

The only real use for client-side scripting should be for user customization. (Imagine being able to write a script to download your bank statements, instead of having to manually click through six different pages to get there.)

[riley@toot.cat]

@woozle The neo-#retrocomputing context that I imagined this sort of thing for was, if the terminal could be smart enough to do all sorts of Turbo Vision like things in itself, and the client would just have to ask it, then low-level programming languages, the sort of what one would use in a retrocomputer, could immediately and easily do fairly powerful and user-friendly UIs in an old-school fashion while not forcing the programmer to delve too heavily into the old-school "optimisation" tricks.

And incidentally, the same reasoning could apply to making neat Turbo Vision like user interfaces for shell scripts without having to mess around with curses in shell scripts, just echo ... (or, well, a couple of wrappers around it that add the appropriate escape codes). Yay for a portable interface between a retrocomputing environment and a still-relevant context!

[woozle@toot.cat]

@riley Oh! I'd forgotten what "Turbo Vision" referred to, though I think I wrote at least an app or two for it. (I mostly focused on my own GUI frameworks, both text and graphical, cuz that's how I roll).

...but yeah, that sounds very congruent with what I had in mind: it should be easy to request a window, to request a set of controls or static elements (without having to specify exact positions and manage how they move around as the window-size or resolution changes, etc., but being able to specify how they relate to each other so the client-side layout engine can make good default choices), to update element contents/appearance, and to receive input from the user interacting with the screen.

...and I suspect that if it was designed well from the ground up, it wouldn't have to be a even a fraction as bloated as most web-browsers.

[riley@toot.cat]

@woozle Speaking of finding transfem folks in unexpected places, https://jexer.sourceforge.io/. A beautiful thing, even if it's Java-based.

[riley@toot.cat]

@woozle The Pascal version of Turbo Vision for a typical application used to take about 100–150 kilobytes of x86-16 executable, depending on the widgets you would use. About 70 for truly minimal things such as a README pager.

Turbo / Borland C++ version of TV tended to turn out bulkier; not because it was itself bigger, but because of quirky differences of compilation and linking technologies between Borland's Pascal and C(++) toolchains.

[riley@toot.cat]

@woozle Also, Borland supplied a hypertext authoring system with the (late) versions of Turbo Vision, in the guise of 'context help'.

[woozle@toot.cat]

@riley I remember looking at the Windows help system and thinking "huh, might be kind of useful to be able to use this for other stuff..." -- but when I looked into it, the process for creating content was... complex, and involved compilation using some software that might have cost money or something (I don't quite remember)...

...so I put it off indefinitely, and then suddenly the web happened. #procrastinationFTW

[riley@toot.cat]

@woozle And now, Microsoft uses a form of wrapped-together HTML for its context help.

The TV sample applications that come with the Borland's TV toolchains, both Pascal and C version, come with the source code for a widget that displays help, according to 16-bit context indicators, and there's an utility called tvhc, for Turbo Vision Help Compiler, also in source code form, that takes text looking like this:

.topic Viewer=2
 File viewer ▄
  ▀▀▀▀▀▀▀▀▀▀▀▀
A file viewer views the contents of a text file. You can use the
arrow keys to move about in the file. A file is loaded via the
{File│Open:FOpen} menu item.

  Up         Move up one line
  Down       Move down one line
  Right      Move right one column
  Left       Move left one column
  PgUp       Move one page up
  PgDn       Move one page down
  Home       View right most column of the file
  End        View left most column of the file
  Ctrl-PgUp  View top of file
  Ctrl-PgDn  View bottom of file.

File viewers can be resized and moved using the {Windows} menu.

and converts it into an indexed binary structure that the widget can process. .topic indicates beginning of an article, Viewer is this particular article's name; 2 is its 16-bit code (also automatically made available as hcViewer in C cource, 'hc' standing for Help Context), and {Windows} is a hyperlink to topic named Windows. {File | Open:FOpen} is a hyperlink topic named FOpen, but labelled File | Open, since the topic names, considering that they become C constant names, have to be identifier-like.

Also, you can attach the 16-bit help contaxt tags to all sorts of things, such as menu items or budttons or checkboxes, so focusing one and and triggering the cmHelp command, often customarily available bound to the F1 key, can just pop up the help browser at the appropriate topic.