why static site checker

Why did I make the static site checker? Aren’t there a lot of other HTML validators around? When I checked a few years ago; I couldn’t find a web site validator, only web page validators. Things may have improved. Anyway, my google foo is poo.

My identity website has more than 100,000 pages. I’m too impatient to push each through an editor’s validator one by one; I want to validate my site as a whole. Furthermore, single page validators can’t catch inter–page errors, such as broken internal links, let alone hidden links (an otherwise valid link to a HIDDEN element).

riff on name

Many people avoid such problems by using frameworks. I find frameworks awful. IMAO, they produce dull, boring, trite design. The visual arts world has had centuries to develop excellent form for a rectangular space. Most 21st frameworks are so crude they haven’t even absorbed 14th century visual arts’ developments, when painters broke out of rectangular form in a rectangular frame. So much is possible, so much hasn’t happened. I want to break this dull, stultifying, archaic, mutton.

Maybe I’m making the wrong comparison, that the web isn’t about image, it’s about type. The Western visual arts never did really suss mixing writing and form (that’s not really true, but, IMAO, such arts never escaped their context). However, the Eastern visual arts most certainly did, and frameworks haven’t noticed them either.

Enough of this. Rather than criticising other people for not doing, I should do. I need to make some example sites. That’s where ssc comes in.

If I am to build a site using an experimental visual process, I can’t use frameworks. If I can’t use frameworks, I have to hand code. And there’s the key problem: HTML is such a convoluted, evolved mess, that the people who designed it, in their own design presentations, make errors. Ok, I only found this out by testing ssc on them, which conveniently illustrates that HTML is overcomplicated. I’m not going to reveal names because these people are working hard to make the web a better place. Let’s just say W3 had broken links, WhatWG referenced withdrawn ontologies, and many other authors’ sites have other internal inconsistencies. That the people who define the web make mistakes using their own design in their own documents that espouse their design, helps explain why most stick to dull, formulaic, boring, frameworks. To be fair, my HTML is far worse than their mild technical naughtiness, which is why I had to write ssc.

I’ve yet to build a site inspired by visual art’s form and layout. My efforts have been spent building ssc, a tool to make that practical.

Since I’m here, I’ll list other issues I have with frameworks:

  • They have to be regularly maintained. Every time an update comes out, that update has to be applied to a site, otherwise the site becomes vulnerable to the exploits published by the update. Time is lost playing patch catchup.
  • Updates for frameworks sometimes fail; instead of fixing issues, they break sites. That’s why I dropped Drupal. That’s why I swore off NextCloud.
  • Frameworks use scripted languages, such as PHP. There were, in October 2021, five known vulnerabilities in PHP (far better than time was). Other frameworks use other scripted languages with other problems.
  • IMAO, frameworks’ and scripts’ worst flaw is many import code at runtime from third–party repositories. Their integrity and security is dependent on that of the repository, over which a site owner (usually) has no control. There are many examples of repositories being hacked, breaking the security and integrity of all sites that use them.

Dylan Harris
December 2024