static site checker

content

introduction
try
why
README
usage
known issues
build
download
boot notes
copyright & licence

introduction

The static site checker is an opinionated HTML nitpicker, a command–line tool to validate static HTML & XHTML websites. I built it to nitpick my hand–coded identity website. I’m making it available should others find it useful.

It should not be used on untrusted content; its parsers are holier than Robin’s cow.

Dylan Harris
April 2022

try

notes

SSC is a site checker, not a page checker, yet here you can only input a page, at most. It is not the best possible illustration of the program’s abilities, but it is better than nothing. Testing a web site would require proof of control of that site, and I’m not going there for a simple demo.

SSC is pre–alpha software. It has more errors than Fido has fleas. This page is a demo of its potential, that’s all. Do not presume reported issues are correct. Do not presume unreported issues aren’t issues. If you’re unsure, check against the appropriate standard. There is no guarantee of anything, let alone accuracy.

There is a fairly tight limit on the size of a snippet.

why ssc

Why did I make the static site checker? Aren’t there a lot of other HTML validators around? Well, first of all, I’ve not found a website validator, only web page validators. Perhaps I didn’t search sufficiently.

I have a fairly big website, with more than 100,000 pages. I’m too impatient to run each through a validator individually; I want to validate my site as a whole. Some errors occur between pages, not specifically on pages: not just missing links, but, for example, it’s invalid to link to an otherwise valid id on another page when that id’s element, or one of its ancestors, is HIDDEN.

The validators I did find were incomplete. Now, admittedly, I checked these out a few years ago, and some may well have got better. Editor based validators are certainly very useful, but they only work on individual pages, not sites. You have to edit a page to get it validated, and if you have rather a lot of them, that’s a lot of time wasted opening and closing individual pages. To expand that ID example above, if, in a specialist editor, you add HIDDEN attribute to an element which has an id on a child element, does that editor then name & shame the other page you’ve just invalidated?

All this are part of the reason why many people use frameworks. (Another, the obvious one, is to get a site up quickly.) One of the difficulties I have with frameworks, is that, most of all, so many web frameworks are, visually speaking, boring and trite. The visual arts world has had centuries to work out excellent form and vision to fit in a rectangular space, and it seems to me the modern web hasn’t noticed. The best that can be said is that some of them have approached the advances made in the 14^th century, and that’s just in the Western artistic tradition. So much more is possible, yet it hasn’t happened. I want to break free from this dull, stultifying conservatism.

It may be that I’m making the wrong comparison, that the web isn’t about image, it’s about type. The comparison should not be with pictures, but papers. There’s certainly something to that. The Western visual high arts never did really suss mixing writing and form (actually, that’s not really true, but, IMHO, such arts never broke out of their context). But arts from Japan, for example, certainly did, and the web doesn’t seem to have noticed them either.

Also, to be absolutely fair, there are experimental websites mixing imaginary and text rather well. But then we get back to my point about the 14^th century. Those I’ve seen, and I’ve certainly not seen as many as there are, nor come close to it, those I’ve seen still seem not to have noticed the visual forms changes made since the middle ages.

Anyway, enough of this. Rather than criticising other people for not doing, I should do. I should make my point, not by criticising others for not thinking of it, but by example. I need to knock up some example sites. That’s where SSC comes in.

You see, if I am to build a site using what is effectively an experimental visual process, I can’t use existing web site design frameworks. But if I can’t use a framework, I have to hand code everything. And there’s a key problem: HTML is such a convoluted, evolved mess, that the people who design it, in their own design presentations, make errors. Ok, I only found this out by testing SSC on them, which perhaps illustrates my point about things being overcomplicated. Anyway, I’m not going to reveal any names because these people are actually working hard to make the web a better place. Let’s just say W3 has broken links, WhatWG references withdrawn standards, and many other authors’ sites have other internal inconsistencies. I must mention that my HTML code is far worse than any of these mild examples of technical naughtiness. But the fact that the people who define the web make mistakes in the usage of their design in the documents that espouse the design, does rather explain why most other people are forced to use dull, formulaic, archaic, boring, tools.

I’ve not yet built a site inspired by the visual art world’s lessons in form and layout. My efforts have been spent in building the tool to make that possible. But now, I contend, it is at least a little more possible than it was.

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

1. They have to be regularly maintained. Every time an update comes out, that update has to be applied to a site, or, alternatively, the update is ignored and the site becomes vulnerable to exploits blocked by the update, and published when the update is released. This is time lost.
2. Updates for frameworks don’t always work. Instead of fixing issues, they break the site. This why I dropped my experimental Drupal site a few years ago. This is why I stopped using NextCloud.
3. Frameworks are usually written in scripted languages, such as PHP. Scripts are unavoidably insecure compared to no scripts: a script cannot be hacked if it does not exist. Thus a site with no scripts is inherently more secure than a site with scripts. For example, there are, as I write, five known vulnerabilities in PHP, a very popular server scripting language (better than it once was, admittedly). If you use PHP, your site, in principle, has those vulnerabilities, and you have to spend time mitigating them. If you do not use PHP, your site cannot have those vulnerabilities. This is why my sites have no scripts, and another reason why SSC does not analyse scripts (the main one being lack of time). I do accept that sophisticated sites have no choice but to use scripts, but I suggest many sites use them unnecessarily.
4. The worst of them all, for me, is that some frameworks, and many scripts, pull in code residing on other sites, in third–party repositories and the like, as the script is run. If you do that, this means the integrity and security of your site is entirely dependent on the security of the repository. There are unfortunately many examples of repositories being hacked, and, in consequence, all the site that used those repositories are broken in turn.

Dylan Harris
October 2021

README

Static Site Checker
(an opinionated HTML nitpicker)
version 0.0.127
https://ssc.lu/



(c) 2020–2022 dylan harris
see LICENCE.txt for copyright & licence notice
see W3-LICENCE.txt for additional copyright & licence information



WARNING: this code is:
— incomplete
— pre—alpha
— IT PROBABLY WON’T BEHAVE AS YOU EXPECT :-)
— do NOT feed it untrusted data



ssc analyses static HTML snippets, files and sites:
— HTML 1.0/+/2.0/3.0/3.2/4.00/4.01/5.0/5.1/5.2/5.3–draft
— HTML living standard, Jan 2005 to Apr 2022
— SVG 1.0/1.1/1.2 Tiny/1.2 Full/2.0/2.x draft Apr 2021
— MathML 1/2/3/4–draft
— XHTML 1.0/1.1/2.0/5.x
— finds broken links (requires curl)
— processes server side includes, mostly
— checks microdata & RDFa

with opinions on:
— standard english where dialect is required
— perfectly legal but sloppy HTML
— abhorrent rudeness such as autoplay on videoss

It does NOT:
— behave securely: its parser is holier than robin’s cow
— analyse or understand scripts
— analyse or understand styles, beyond nicking class names from CSS
— analyse or understand XML or derivatives except as noted above

It can output:
— ‘repaired’ HTML (not XHTML)
— HTML with resolved Server Side Includes
— JSON summaries of microformat and microdata content
— website statistical information
— updated website with datafile deduplication


ssc -h
for a usage summary.

ssc -f config_file
analyse site using preprepared configuration

ssc directory
analyse website based in directory



To build & run:
1. Follow the build instructions in build.txt
2. Gleefully run ssc. It will misbehave if you are insufficiently gleeful.



NOTE
SSC can be run in a CGI environment. This is intended for use with OpenBSD’s native httpd web server
(https://man.openbsd.org/httpd.8). You are reminded that SSC is pre-alpha software. Do NOT expose it
to untrusted data sources, such as the open web, without taking serious precautions. SSC probably has
more bugs than the Creator’s Ultimate All–Beetle Extravaganza (J.B.S. Haldane, apocryphal : “[the
Creator has] an inordinate fondness for beetles.”).



Notes on names:
- recipe: a nod to Vernor Vinge’s “A Fire Upon the Deep”
- tea: without tea, nothing works; then there’s builders’ tea
- sauce: identifies those who presume; and anyway, it’s obvious
- toast: toasts code; i like burnt toast
- heater: i’m not stopping now
- unii: my preferred plural of unix; both unixes and unices sound like they sing castrato




SEE ALSO
build.txt        notes on building ssc
gen.txt          a model man page
usage.txt        how to use ssc
releasenotes.txt a slight history of releases
LICENCE.txt      ssc licence information
LICENSE.txt      formal GPL 3 licence
more licences    licences for borrowed external content



written by dylan harris
mail@ssc.lu
April 2022

usage

NAME
ssc - analyse static web site source



SYNOPSIS
ssc [...] directory
ssc -f config
ssc



DESCRIPTION
ssc (the Static Site Checker) is an opinionated HTML nit-picker, intended for
people, such as its author, who hand code websites. It doesn't just check
static websites for broken links, dubious syntax, and bad semantic data, it
will actively complain about things that are perfectly legal but just a little
bit untidy, like its author.

Except when serving CGI queries, it recursively scans the directory looking
for HTML source files to analyse. It produces a list of errors, warnings,
comments, and other hints of imperfection. Once complete, it summarises
internal site inconsistencies, and can produce some simple statistics.

Scripts are ignored. CSS is only processed for class declarations.



COMMAND LINE ONLY SWITCHES

These options are only available on the command line:

-f file                 Load configuration from file, which should be in .INI
                        file format. See CONFIGURATION FILE FORMAT below.

-F                      Load the configuration file .ssc/config in the current
                        directory.

-h                      Show a summary of switches, then exit.

--ontology.list         List known schema versions, then exit.

-V                      Show version details, then exit.

--validation            Show attribute extensions, then exit. Attribute
                        extensions are additional values that can be
                        associated with attributes on some X/HTML elements,
                        and is intended for use with bespoke extensions of
                        HTML.



COMMAND LINE AND CONFIGURATION FILES SWITCHES

These options are available on the command line (with dashes) and in
configuration files (without dashes). The short form alternative switches
only work on the command line.

Most binary options, e.g. those without arguments below that turn on a feature
(which may be the default), have a corresponding "no-" switch to turn it off.
The "no-" is inserted after the dot, so, for example, the contradiction to
"--general.class" is "--general.no-class". When both are specified, perhaps in
a configuration file and on the command line, the "no-" switch always applies.

--corpus.article        Prefer the content of 
 when gathering corpus
                        text.

--corpus.body           Prefer the content of  when gathering corpus
                        text. This is the default.

--corpus.main           Prefer the content of 
 when gathering corpus
                        text.

--corpus.output file    Dump XML corpus of site into file. This is intended
                        for use by a local search engine. If none of
                        --corpus.article, --corpus.body, or --corpus.main are
                        specified, the content of  is used. If more than
                        one are specified, then the text collected depends on
                        a page's content. This is incompatible with
                        --shadow.update.

--general.class         Report unrecognised classes.

--general.cgi           Check environment variables for snippets of HTML.
-W                      Expects environment variables as produced by
                        OpenBSD's native web server, httpd, produced
                        using 
. Do NOT let ssc
                        anywhere near untrusted data should you do so,
                        unless you are very confident about your system
                        configuration (because it'll defend you against
                        naughty people who may take advantage of ssc's
                        pre-alpha nature and its corresponding myriad
                        flaws). Ignores many options including shadowing.

--general.css           Do NOT process .css files (for class names).

--general.custom EL     Define a custom element  for verifying the IS
                        attribute. May be repeated.

--general.datapath dir  Look for any configuration, caches, and other useful
-p dir                  files, in this directory.

--general.error x       If nits of the specified category or worse are
-E                      generated, then exit with an error code. Values are:
                        'catastrophe', 'error' (the default), 'warning',
                        'info', or 'comment'.

--general.file XXX      File for persistent data. Requires -N. See also
                        --general.datapath. Default extension: .ndx.

--general.ignore EL     ignore attributes and content of the element . May
                        be repeated.

--general.lang LA       If an X/HTML file does not have a language / dialect
                        specified (e.g. "en" for generic English, "en-IE" for
                        Irish English, "lb-LU" for Luxembourgish, etc.),
                        default to 'LA'. If not given, the default is your
                        system default, or, if none, then "en-US" (standard
                        American English).

--general.maxfilesize n Do not process HTML source files that exceed n bytes
                        in size (default: 4M). Specify 0 for unlimited,
                        although be warned that ssc is stunningly stupid in
                        such circumstances and may even attempt to load files
                        that exceed available memory.

--general.output        Output to the specified file. If this switch is not
-o file                 used, standard output is used.

--general.progress      Dump progress information to standard output. This can
-D                      interfere with formatted output.

--general.rdfa          Check RDFa attributes.

--general.rel           Only mention  REL values, found neither in the
                        living standard nor at microformats.org, in debug
                        output.

--general.rpt           Report CSS files that are opened. ssc opens CSS files
                        to verify classes; it does not verify CSS.

--general.slob          Ignore perfectly legal but inefficient, indeed
                        thoroughly slobby, HTML, such as being far too lazy to
                        get round to bothering to close elements.

--general.ssi           Process Server Side Includes. Although ssc can process
-I                      many server side includes, it cannot process those
                        containing formulae. Note that processing SSIs may
                        cause incorrect line numbers to be mentioned when an
                        issue is reported.

--general.test          Output data in automated test format. Used by ssc-test.
-T                      Not generally useful. Documented so you can avoid it!

--general.verbose x     Output nits to the specified verbosity: 'catastrophe',
-v                      'error', 'warning', 'info', 'comment' (the default),
                        or '0' for silence. Additional values are available
                        when debugging. Each level includes its preceding
                        level, so, for example, 'warning' will also output
                        'catastrophe' and 'error' nits.

--html.rfc1867          Ignore the RFC 1867 (INPUT=FILE) extension when
                        processing HTML 2.0

--html.rfc1942          Ignore the RFC 1942 (tables) extension when processing
                        HTML 2.0.

--html.rfc19802         Ignore the RFC 1980 (client side image maps) extension
                        when processing HTML 2.0.

--html.rfc2070          Ignore the RFC 2070 (internationalisation) extension
                        when processing HTML 2.0.

--html.tags             When an HTML file is loaded that contains no DOCTYPE,
                        ssc normally presumes it's an HTML 1 file. This switch
                        tells it to presume the file follows an earlier HTML
                        Tags specification (the one at CERN). This is
                        overridden by --html.version.

--html.title n          If