4 ms·

Unfortunately basic HTML has one glaring problem: it has no concept of code reuse. No layout, no shared footers, nothing like that. Frames were probably HTMLs a

Unfortunately basic HTML has one glaring problem: it has no concept of code reuse. No layout, no shared footers, nothing like that. Frames were probably HTMLs answer to reusing common elements, but oops, frames are a disaster. Instead it was so bad there were actually Apache extensions to reuse HTML (see server side includes). Then compound this problem with something like a blog where you have hundreds of pages who all need to have their menus updated every time you post something, and yeah...pure HTML is just unacceptable.

door101 6y ago
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.
- blacktriangle 6y ago
  And then you've completely destroyed the point of hypermedia.
  - door101 6y ago
    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
    - blacktriangle 6y ago
      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.
      - door101 6y ago
        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-morning-routine-that-completely-changed-my-life-2707208eb4d 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/ 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.
- bccdee 6y ago
  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 https://mustache.github.io/mustache.5.html
  - door101 6y ago
    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.
tannhaeuser 6y ago
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.
- blacktriangle 6y ago
  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?
  - tannhaeuser 6y ago
    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 http://sgmljs.net [2]: http://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html http://sgmljs.net/docs/producing-html-tutorial/producing-htm...
    - blacktriangle 6y ago
      This is a whole avenue of exploration I had never even considered, thank you very much for responding with this.
bonaldi 6y ago
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

door101 6y ago

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.

blacktriangle 6y ago
And then you've completely destroyed the point of hypermedia.
- door101 6y ago
  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
  - blacktriangle 6y ago
    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.
    - door101 6y ago
      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-morning-routine-that-completely-changed-my-life-2707208eb4d 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/ 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.
bccdee 6y ago
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 https://mustache.github.io/mustache.5.html
- door101 6y ago
  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.

tannhaeuser 6y ago

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.

blacktriangle 6y ago
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?
- tannhaeuser 6y ago
  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 http://sgmljs.net [2]: http://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html http://sgmljs.net/docs/producing-html-tutorial/producing-htm...
  - blacktriangle 6y ago
    This is a whole avenue of exploration I had never even considered, thank you very much for responding with this.

bonaldi 6y ago

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