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

@woozle I just realised I forgot to put in the answer.

That is — these were missed in the first addition of them to HTML, and by the time the opportunity to fix them came, the proto-cryptobros were so powerful that they just took HTML in a different direction.

Woozle Hypertwin

@riley Time to reclaim what is rightfully ours. #OccupyHTML

(NTS: also, need a power-to-the-people fist-emoji, because ain't it.)

Riley S. Faelan

@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 ;, or maybe just as &semi;.

Woozle Hypertwin

@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 S. Faelan

@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 Hypertwin

@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 S. Faelan

@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 S. Faelan

@woozle Oh, and isindex is compatible with Gopher.

Woozle Hypertwin

@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 S. Faelan

@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 S. Faelan

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

Riley S. Faelan

@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 Hypertwin

@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 S. Faelan

@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 Hypertwin

@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 S. Faelan

@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 Hypertwin

@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 S. Faelan

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

Riley S. Faelan

@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 S. Faelan

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

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.