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 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.

react loading skeleton

@riley @woozle everytime i remember frames still exist i flinch

Woozle Hypertwin

@riley I mean, that's kind of more or less what I expected: there were issues that are no longer issues, consistency was not a huge priority, and things were generally done in a bit of a rush and often for the wrong reasons.

I do remember image maps (pretty sure they're still supported); I might even have implemented one. (I also remember doing it the hard way -- splitting an image up into the shapes of the clickable areas, then stitching them together with carefully-formatted HTML.)

I also remember encountering isindex in the late 90s and being all "...".

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:

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.