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 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@toot.cat]

@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@toot.cat]

@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@toot.cat]

@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@toot.cat]

@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@toot.cat]

@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@toot.cat]

@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@toot.cat]

@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@toot.cat]

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

[ionizedgirl@toot.cat]

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

[woozle@toot.cat]

@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@toot.cat]

@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@toot.cat]

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

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

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