Rewriting my website in plain HTML and CSS

I didn't expect this to be serious and am surprised on that the tutorial actually delivers. Way back when I was learning HTML and it was said that it was built with SGML, then this relation remained a total mystery to me.

I’ve become quite a fan of writing in SGML personally, because much of what you note is spot-on. Some of the points seem a bit of a stretch though.

Any type-checking inside of SGML is more akin to unused-variable checking. When you say that macros/entities may contain parameters, I think you are referring to recursive entity expansion, which does let you parameterize macros (but only once, and not dynamically within the text). For instance, you can set a `&currentYear` entity and refer to that in `copywrite "&currentYear/&currentDay`, but that can only happen in the DTD at the start of the document. It’s not the case that you could, for instance, create an entity to generate a Github repo link and use it like `&repoName = "diff-match-patch"; &githubLink`. This feature was used in limited form to conditionally include sections of markup since SGML contains an `IGNORE` “marked section”.

   <!ENTITY % private-render "IGNORE">
   ...
   <![%private-render[
   <side-note>
   I’m on the fence about including this bit.
   It’s not up to the editorial standards.
   </side-note>
   ]]>

Would love to hear what you are referring to with “safe” third-party transclusion and also what features are available for removal or rejection of undesired script in user content.

Apart from these I find it a pleasure to use because SGML makes it easy for _humans_ to write structured content (contrast with XML which makes it easy for software to parse). SGML is incredibly hard to parse because in order to accommodate human factors _and actually get people to write structured content_ it leans heavily on computers and software doing the hard work of parsing.

It’s missing some nice features such as namespacing. That is, it’s not possible to have two elements of the same name in the same document with different attributes, content, or meanings. If you want to have a flight record and also a list of beers in a flight, they have to be differentiated otherwise they will fail to parse.

   <flight-list>
   <flight-record><flight-meta pnr=XYZ123 AAL number=123>
   </flight-list>

   <beer-list>
   <beer-flight>
   <beer Pilsner amount=3oz>Ultra Pils 2023
   <beer IPA>Dual IPA
   <beer Porter>Chocolate milk stout
   </beer-list>

For more complicated work I make quick transformers with WordPress’ HTML API to process the XML output (I know, XML also isn’t HTML, but it parses reliably for me since I don’t produce anything that an HTML parser couldn’t parse). Having an imperative-style processor feels more natural to me, and one written in a programming language that lets me use normal programming conveniences. I think getting the transformer right was never fully realized with the declarative languages, which are similar to Angular and other systems with complicated DSLs inside string attribute values.

I’d love to see the web pick up where SGML left off and get rid of some of the legacy concessions (SGML was written before UTF-8 and its flexibility with input encodings shows it — not in a good way either) as well as adopt some modern enhancements. I wrote about some of this on my personal blog, sorry for the plug.

https://fluffyandflakey.blog/2024/10/11/ugml-a-proposal-to-u...

Edit: formatting

> But the overhead of just doing it yourself is surprisingly small in terms of the time commitment.

Holy cow. The sole reason I learned SSI and then PHP in 1998 was because I was sick of this after like 2 weeks.

This person has more patience in their pinky than I have ever had.

I recently learned the object tag can do what I wished for in the 90s... work as an include tag:

    <object data="footer.html"></object>

Should reduce a lot of boilerplate that would get out of sync on my next project, without need for templating.

I've adopted the idea that a blog post is archived when it's published; I don't want to tinker with it again. Old pages may have an old style, but that's OK, it's an archive. Copy/paste works great for this.

The only reason I use a blog engine now (Hugo) is for RSS. I kept messing up or forgetting manual RSS edits.

Or, let me be cheeky: you could add some `<php include('header.html')?>` in your html.

> It can generate headers and the like dynamically so you don't have to change it on every single pa

Yeah, I noped out of that and use a client-side include (webcomponent) so that my html can have `<include-remote remote-src='....'>` instead.

Sure, it requires JS to be enabled for the webcomponent to work, but I'm fine with that.

See https://www.lelanthran.com for an example.

[EDIT: Dammit, my blog doesn't use that webcomponent anymore! Here's an actual production usage of it: https://demo.skillful-training.com/project/webroot/ (use usernames (one..ten)@example.com and password '1' if you want to see more usage of it)]

Isn't using React with a static site generator framework basically the same thing but better?

> > Yes, you must copy and paste content and not having layout page is annoying at time

> I think this was one of the most common usages of PHP in the beginning,

> <?php include('header.inc'); ?>

And other tools beforehand: basic CGI or even more basic server-side includes (https://en.wikipedia.org/wiki/Server_Side_Includes)

To reduce CPU and IO load on the server (or just in circumstances where SSI was not enabled on the server they had available) some would pre-process the SSI directives (obviously this doesn't work for dynamic results such as the output from many #exec examples), so all that is being served is simple static files ‑ a precursor to more complex modern static site builders.

> It would be great if HTML had a similar capability. People have asked for it for over 30 years, so it's unlikely that it will be implemented now.

That doesn't really fit with the intentions of HTML, and could impose a bunch of extra network latency overhead compared to using SSI instead, leading to either complete rendering delays or jumpy pages as included content is merged in in steps, though I have seen it implemented multiple ways using a bit of JS (some significantly more janky than others).

See my reply about the object tag. Suffers from lack of press I guess.

A slightly simpler version of same is:

  for PAGE in *.page
  do
    cat header.html "$PAGE" footer.html > "$PAGE.html"
  done

HTH

EDIT: if you don't want the output file to be named "a.page.html" and instead it to be "a.html", replace the above cat invocation with:

  cat header.html "$PAGE" footer.html > "${PAGE%.page}.html"

0 - https://man.freebsd.org/cgi/man.cgi?query=cat&apropos=0&sekt...

Why not use server side includes? Most web servers support it, and it dates back to one of the early features of webservers.

    <!--# set var="pagetitle" value="Main page" -->
    <!--# include file="00__header.html" -->
    
    ... main content here
    
    <!--# include file="00__footer.html" -->

`cat` supports multiple files, no? The whole point is that it concatenates. Why use 3 commands?

Unfortunately, this doesn't adjust the <title> element.

Furthermore, when it comes to recipes for baking, if it's not using weight as a measure, then it's wrong. Baking is chemistry, so if you want consistent controlled results, stop measuring anything by volume.

Sorry, pet peeve of mine as a hobby baker.

it's also just way faster to not mess with the spoons/cups! an exception might be little fussy quantities like a bunch of 1/4 tsps of different spices etc.

thanks! i first just made a sample html the way i thought it would be nice, then made that into a templeate, and wrote a python script generate the site. it first scans for all the files to build the menu and homepage, then goes file-by-file to make each one, filling in the blanks in the template as you can imagine. it was pretty natural since my spreadsheets were all following the same format already anyway. i'd be surprised if there was a lot of interest, but if so i'd consider sharing the script/template etc.

thanks, good point!

simple like:

title

subtitle

.. [two blank lines make a section break]

ingredients with 4 columns, last one is an optional comment for the row

..

method steps with 2 columns, last one is optional comment

..

then optional sections that just have to have:

section title (this is the collapsed title string too)

any rows included until the next .. etc. etc.

plus just a few tricks like if an ingredient comment has [] then it uses that as a URL for the ingredient, if a row in ingredients has just one column then it's a header etc.

Most of them bend to your will very easily if you are the one writing the HTML and not trying to use an existing template/theme. Even Jekyll the "themes" are optional and you can entirely ignore them.

Also most of the complexity disappears if you aren't trying to make a blog. They generally all have "simple pages" support that is much simpler than trying to figure out their blog mechanics.

Of course the hard part is picking an SSG you like, and it is easier to just build your own which is a big part of why SSG proliferation happens. Too many options? Make a new one.

My main sites are still in Jekyll for now, for historic reasons of GitHub Pages support.

My latest discovery and new love in this space is Lume [0]. It's definitely on the simpler side of the scale. I haven't tried it for a full blog yet, but the simple website I have built with it has indeed continued to feel simple throughout the process and even using some of the features Lume's documentation labels "Advanced".

[0] https://lume.land/

Alternatively pick a light-weight template engine from your favorite language and use it to generate the html. More flexible than plain html files and very low learning commitment.

I've been doing that for years and really happy with the result.

I would rather say that the former group are wrappers around the latter group. Using an SSG doesn't just mean converting Markdown etc. source and orchestrating a build process of some sort, but also filling in templates and providing useful build steps to orchestrate (such as generating additional pages that reference the actual article content: archives, collections grouped by tags or categories, etc.). They also generally implement things like the live reloading that the author mentioned as missing.

I'm currently using Nikola and have done quite a bit of customization - by hacking around and learning modern web stuff as I go (the last time I did this stuff seriously, jQuery was dominant and Bootstrap was brand new - of course I'm not writing a bunch of JavaScript for a blog, but that also presumably dates my understanding of HTML and CSS). I've found that even though there's way more stuff in here than I really want, it's really nice to have that kind of scaffolding to start, and I can strip it away as I customize.

>Also I didn't want all the theme-ing overhead that comes with those - just something I could inject into my existing site.

I didn't like how complex that stuff is with Nikola - I didn't have an obvious entry point for making the kinds of customizations I really wanted, and yet there was still so much to look at in order to understand the system. But at the same time I really didn't want to spend hours re-learning CSS more or less from scratch, when I could actually use the examples already in the existing themes.

I did something really awful: instead of trying to make yet another layer of theme "extension", I copied everything locally and have been condensing it as I go.

This had the benefit that I didn't have to decide on a bunch of CSS classes up front in order to have anything look passable. There may be tons of unused stuff, but I'm cleaning that up as I implement my own things - and bit by bit, I get something smaller and more comprehensible that fits my mental models. This conversion process might not be any faster, but I'm certainly enjoying myself more.

At some point in the future I'm considering doing a simple templating engine and converting these templates (originally Mako) to it. It just irritates me that I still have to deal with close tags - both in HTML and in template directives - when I'm doing everything in Python. I have a vague memory of a 2010-era JavaScript templating system - I think it was called Express or something like that? - which used indent-based syntax without closing tags. So I'm inspired by my recollection of that.

IMO there's quite a surprising amount of stuff you can do on GitHub that's highly undiscoverable. You only think of it when you see someone else on the site doing it, and then you don't necessarily know what it's called so you don't know how to research it.

Don’t hate the layer, hate the player.

How can UI be stable if you’re the one changing it all the time even if all you need is a readme page that can be done in the same UI with no change for decades?

Personal websites can be down a few days a month without a problem.

Because it's free and convenient, and other hosting providers don't magically have 100% uptime either. Not even necessarily more uptime than GitHub.

I like to think that when GitHub (or Google, or Netflix, ...) are down, I am not alone.

A few million people are holding their breath - unlike in the case of my self-hosted site where I am alone to bring it back online.

How is it "tied"? You still have a local repo that you could deploy somewhere else.

What do you have in mind?

I was thinking in using it for a blog, but I am afraid of having everything in a single file, and that making some mistake will render the whole site useless.

Also not sure how hard would be to manage once it starts to grow... Maybe it needs to grow significantly more than I can before this is a road block.

Same. This would work really well for my site, I think, although I worry slightly about latency as it scales and I add more and more photos. That is not so much a problem right now, but it might impose some latency later.

Of course. It's not a blog without RSS!

Believe it or not, I also manually edit that in BBEdit.

You just need a build system in place - generating RSS from your collection of html files isn't difficult.