Correct - though as designed that's a tooling problem, not a spec problem. Consider the pre-web world: You don't have reusable components in your printer, you manage stylesheets and templates in your word processor.

The original assumption from TBL was there would be much richer tooling to allow everyone to compose HTML without knowing tags, but for various reasons that's not the direction Andreesen et al took Netscape. And third-party tooling (like SiteMill) end up focusing on developers and evolved into things like DreamWeaver.

Hence the mess we're in today: the world's greatest publishing platform, and it's near-impossible for non-technical users to start publishing directly to it as conceived. Good news for Wordpress and CMS vendors, but a road sadly not taken in so many other aspects

The HTML vocabulary doesn't have and doesn't need these because SGML, on which HTML is based, has entities and many other constructs for templating. In fact, both SSI in default config and embedded PHP use a (simplistic) form of SGML extension syntax (markup comments and processing instructions, resp.) for equipping static HTML with dynamic features, though SGML has much more powerful ones.

So are you suggesting the solution is we should write SGML and then have that converted to HTML to fill the role of a static site generator?

I was merely commenting on why HTML itself doesn't have the features you mentioned. But yeah, authoring HTML in SGML is the most natural thing given HTML's origins. It doesn't have to run as a static site generator since SGML can run right in the browser and in the web server backend (see eg my project here [1]). Though using SGML as static site generator from the command line or Makefiles is also extremely useful, and maybe the most appealing for developers or when static site hosting is desired ([2]).

[1]: http://sgmljs.net

[2]: http://sgmljs.net/docs/producing-html-tutorial/producing-htm...

This is a whole avenue of exploration I had never even considered, thank you very much for responding with this.

IMO the solution is to design around these constraints, ie, don’t include a menu on your blog posts, just a link to the home page, which has a list of all the posts.

By that point though, you're dropping actual useful website features. What if I want a consistent style across my pages? What if I like restyling the whole website & I don't want to manually edit dozens of HTML files to do that? What if I think a header bar or a "recent posts" section would be nice?

I'm not saying it's bad to design a website in plain HTML, but it is critically limiting, and I wouldn't recommend it over a simple generator setup. If you're really opposed to using a fully-featured SSG, it'd be pretty simple to write a shell script that uses mustache(5) [1] to plug html articles into a template. That's almost as simple and clean as plain html, but it's a real step up when it comes to what it lets you do.

[1]: https://mustache.github.io/mustache.5.html

I want to clarify -- what I'm describing is how I would design a simple website using plain HTML. I have no opposition to SSG's, but just want to present an option for what it would look like if you eschew them completely.

And then you've completely destroyed the point of hypermedia.

What do you mean? You can still like to other documents, just drop the idea of linking to the same list of documents on every page

That works, but it's not what users want. Granted this is personal anecdata, but I've spent years pushing back on client expectations in the name of architecting things in a way the web supports at the lowest levels, and it's been an exercise in failure. No user is going to accept that behavior in a blog, and frankly as a reader on the internet, I find that solution pretty lame as well. I absolutely agree with minimizing the impedance mismatch between how we develop and how the web actually works and the associated tool-chain simplifications that come with that, but at some point we have to accept that web tech just wasn't designed to do what we need from it and add some layers on top. The challenge is balance.

I am not sure what is so radical about this. Let's take Medium as an example (pulled some random article from the front page):

https://medium.com/change-your-mind/the-simple-40-minute-mor...

What we have is, essentially, a blog post that could be written in pure HTML, and a link to the user's profile, which looks like this: https://ashley-richmond.medium.com/ This is one of the most popular blogging platforms and follows exactly the hub-and-spoke navigation model that I described.

Now, I do what to clarify, what I proposed is how I would build a website using plain HTML. I would certainly not go so far as to claim that it is the best way to build any website, SSG's have many advantages, but what I'm saying is that if one is going to write a plain HTML website, the easiest way is to accept the fundamental limitations of that approach, including a hub-and-spoke navigation vs a navbar. If you're writing a plain HTML site, you're probably a bit iconoclastic and willing to accept breaking some standard practices.