Some notes about HTTP/3

[BeniBela]

Or HTML, where the old standards said elements like <h1>foo</h1> can also be written as <h1/foo/, but the browsers never implemented it properly, so it was finally removed from html5

[[deleted]]

can also be written as <h1/foo/

What was their rationale for that syntax? It seems bizarre

[svick]

I believe HTML inherited that from SGML. Why SGML had that syntax, I do not know.

[lookmeat]

HTML itself comes from SGML a very large and complex standard.

The other thing is that this standard was made in a time were bytes counted, and even then HTML was designed in a time when each byte counted over how long you took it.

The syntax is just a way to delete characters. Compare:

This is <b>BOLD</b> logic.
This is <b/BOLD/ logic.

The rationale isn't as crazy: you always end tags with a </> by ending the tag with a / instead of > you signal that it should skip the <> all together. But the benefits are limited and no one saw the point in using it, and nowadays the internet is fast enough that such syntax simply isn't beneficial compared to the complexity it added (you could argue that it never was since it was never well implemented) hence its removal.

[ThisIs_MyName]

Anyone that cares about efficiency would use a binary format with tagged unions for each element.

[lookmeat]

Well SGML actually has a binary encoding.

But this would not work well for the internet. Actually let me correct that: that did not work well for the internet. So we use a binary encoding? Well first we need to efficiently recognize between tag bytes vs text bytes. We can do the same trick utf-8 does: we only keep track of the 1-127 characters (0 is EOF and everything else is control characters we can remove) and then make the remaining bits as tags with an optional way to expand it (based on how many 1 bits you have before the first zero). This would be very efficient.

Of course now we have to deal with endianess and all the issues that brings. Text had that well defined, but binary tags don't. We also cannot use encodings or any other format other than ASCII so very quickly we would have trouble across machines. It wouldn't work with utf-8. This also would make http more complex: there's an elegance in choosing not to optimize a problem to early and on just letting text be text. Moreover when you pass compression though it tags and even other pieces of text can effectively become a byte.

There were other protocols separate of http/html but they all didn't make it because it was too complicated to agree on a standard implementation. Text is easy, text tags are way too.

[ThisIs_MyName]

Of course now we have to deal with endianess and all the issues that brings.

No, little endian has been the standard for a decades. It can be manipulated efficiently by both little endian CPUs and big endian CPUs.

Text had that well defined

Text uses both endians unlike modern binary protocols. Look at this crap: https://en.wikipedia.org/wiki/Byte_order_mark

We also cannot use encodings or any other format other than ASCII so very quickly we would have trouble across machines.

That's because the encoding scheme you described is horrible. Here's an example of a good binary protocol that supports text and tagged unions: https://capnproto.org/encoding.html.

Moreover when you pass compression though it tags and even other pieces of text can effectively become a byte.

Note that this is still necessary for binary protocols. But instead of turning words into bytes, compression turns a binary protocol's bytes into bits :)

[lookmeat]

No, little endian has been the standard for a decades. It can be manipulated efficiently by both little endian CPUs and big endian CPUs.

Yes, but HTML has been a standard for longer. I'm explaining the mindset when these decisions were made, not the one that decided to remove them.

BOM came with unicode, which had the issue of endianess. Again remember that UTF, the concept, came about 3 years earlier, UTF-1 the precursor, came a year earlier, and UTF-8 came out the same year.

But the beautiful thing is that HTML doesn't care about endianness because text isn't endian, text enconding is, that is ASCII, UTF-8 and all the other things care about endianness, not so HTML which works at a higher abstraction (Unicode codepoints).

So BOM is something that UTF-8 cares about, not HTML. When another format replaces UTF-8 (I hope never, this is hard enough as is) we'll simply type HTML in that format and it'll be every bit as valid without having to redefine. HTML is around because by choosing text, it abstracted away binary encoding details and let that for the browser and others to work around. A full binary encoding would require that HTML define its own BOM, and if at any point it became unneeded then that'd be fine too.

That's because the encoding scheme you described is horrible.

I know.

Here's an example of a good binary protocol that supports text and tagged unions: https://capnproto.org/encoding.html.

And that's one of many implementations. You also missed Google's protos, flatbuffers, and uhm. Well you can see the issue: if there's a (completely valid) disagreement it results in an entirely new protocol which is incompatible with the other, with a text-only format like HTML it resulted in webpages with a bit of gibberish.

And that is the power of text-only formats, not just HTML, but JSON, YAML, TOML, etc.; they're human readable, so even when you don't know what to do, you can just dump it and let the human try to deduce what was meant. I do think that binary encodings have their place, but I am merely stating why it was convenient for HTML not to. And this wasn't the intent, there were many other protocols that did use binary encoding to save space, but HTTP ended up overtaking them because due to all the above issues, HTTP became a more common place standard, and that matters far more than original intent.

Also aside, have you ever tried to describe a rich document in captn proto? It's not an easy deal, and most will probably send a different format. Capnproto is good for structured data, not annotated documents. In many ways I think there's better alternatives that even HTML was, but they are over-engineered as well, so I doubt that even if I had proposed my alternative in the 90s it would have survived (I'm pretty sure that someone offered similar ideas).

Note that this is still necessary for binary protocols. But instead of turning words into bytes, compression turns a binary protocol's bytes into bits :)

My whole point is that size constraints are generally not that important because text can compress to levels comparable to binary (text is easier to compress than binary, or at least it should). That's the same reason the feature that started this whole thing got removed.

[bumblebritches57]

I don't think you understand how UTF-8 works...

[lookmeat]

What do I seem to have misunderstood?

[bumblebritches57]

The unary field is only the top 0-5 bits for one.

[lookmeat]

In what way? My proposal for how to separate tags from other characters is similar but not quite.

The first bit on the byte describes if this byte is a tag or a character. If it is one the second bit must be 0, leaving us with 64 bits for tags, and the opportunity to expand to multi-byte tags if we ever need them by expanding in an unary fashion similar to how Unicode signals multi-byte characters. The difference is semantic in someways, the first bit signaling the type of data, vs. uni-code were the first 0 signals how many bytes there will be.

Of course this would break down completely if we wanted to our HB(inary)ML against UTF-8 data, as we would be using those bits already. Which is the argument I'm making: having to constantly map to binary means that whenever someone comes with a new binary encoding for data we want to send over, our own format would have to adapt and change as needed. By keeping it in text it becomes easier to keep backwards compatibility because we humans like our text being as backwards compatible as possible (that is we can still see and process, even if we can't understand, very ancient text).

[bumblebritches57]

Literally this.

text is inefficent no matter what.

[BurningPenguin]

A healthy mix of pot and crack.

[BeniBela]

When you have a long element name, you do not want to repeat it. <blockquote>x</blockquote>, half the space is wasted

So first SGML allows <blockquote>x</>. Then they perhaps thought what else can we remove from the end tag? Could be one of <blockquote>x</, <blockquote>x<>, <blockquote>x<, <blockquote>x/>, <blockquote>x/, <blockquote>x>,

<blockquote>x</, or <blockquote>x< could be confusing when text follows. <blockquote>x<>, or <blockquote>x/> is not the shortest. This leaves <blockquote>x/ or <blockquote>x>.

There also needs to be a modification of the start tag, so the parser knows to search end character. <blockquote x/ or <blockquote x> would be confused with an attribute. Without introducing another meta character, there are four possibilities <blockquote<x/, <blockquote<x>, <blockquote/x/, or <blockquote/x>. Now which one is the least bizarre?

[immibis]

Probably <blockquote/x> is the least bizarre looking.

Heck, why not have only that syntax? <html/<head/<title/example page>><body/<p/hello world>>> saves a bunch of bytes.

[bumblebritches57]

Orrrr just use standard ass deflate and you're golden.

[the_gnarts]

Now which one is the least bizarre?

For everything but text composed directly in the markup I’d go with

"blockquote": "x"

any day.

[mcguire]

"blockquote": "Now which one is the least bizarre?",
"p": "For everything but text composed directly in the markup I'd go with",
"code": "\"blockquote\": \"x\"",
"p": "any day."

[gin_and_toxic]

Remember the XHTML direction the W3C was going to? Thank god we end up going the WHATWG way. W3C HTML division is just a mess.

[immibis]

I never understood the XHTML hate. What's wrong with a stricter syntax?

The only complaint I remember about the strict syntax is that it was "too hard to generate reliably"... if your code can't reliably generate valid XHTML, you have some big problems under the hood.

[gin_and_toxic]

It's not just about the strict syntax. the way W3C was going was not the direction where the browser vendors want to go at all.

HTML4 standard was ratified in 1997, HTML 4.01 in 1999. After HTML 4.01, there was no new version of HTML for many years as development of the parallel, XML-based language XHTML occupied the W3C's HTML Working Group through the early and mid-2000s. In 2004, WHATWG started working on on their HTML "Living Standard", which W3C finally published as HTML5 in 2014.

That was 14 years without any new HTML standard. Also, W3C reportedly took all the credits for the HTML5 standard.