A few warnings come up when I run my html through HtmlTidy, though Validator doesn't pick them up. Despite these 'errors', the site works OK as it is, but I'm checking here in case I'm missing something.

Maybe Tidy uses some XTM standards - I don't know - though it identifies my pages as Html5. It also objects to any '&' used in a sentence, & wants all accents (&eacute; etc) changed to code numbers.
It gives links about errors, sometimes, to WC3 working documents, which are a bit cryptic. Also line numbers (which I have to guess at) to locate the errors. A 'tidied' version of the web page is generated, too.

Thanks! Yes, the site seems to work fine (so far), but it's always nice to be reassured. One thing I picked up from your replies is the space-forward slash at the end of tags <tag />.
I haven't used any (I thought they were some post-Html5 sophistication), & my code (with <meta charset="UTF-8"> etc) slips past WC3s Nu Validator, no problems.

I suppose by inline css, that includes width & height dimensions in the image tags. A word in defence of this malpractice - I constantly refer to them while preparing the layout, to calculate ems & picas for the surrounding regions. I also suspect they provide full-size placeholders (in all but FireFox) when the page is loaded away from the image files. This is very handy, & overlaps show up quickly (specially in Chrome).

& here's another thing - notice my use of the ampersand? (It's like the computer is stealing our language, absconding with a shorthand Latin symbol in common use before printing was invented!) Still, I understand the possibility for confusion with code, so attempt to convert them to &amp; HtmlTidy is better than Validator at hunting them down.

HTML is just a special version of XML. In XML, self-closing tags must be closed. If you ever used XHTML, it also forced all tags to be closed.

HTML is a bit more lax on this, which is why it won't complain, but it also won't complain if you never close any list items. It's very loose on that kind of thing. So, what it comes down to is clean, readable code. And to me, <tag /> looks much cleaner, and is more readable than <tag>. Plus, it follows XML standards.

For inline CSS, if it's that helpful to you during development, leave it in, but then before release everything should be moved to a stylesheet.

That's a great link for the ampersands, so thanks! I like the longhand versions better than coded ones - with &uml; you can see what you're getting, rather than the all-too-clever #246 (for example).

As for inline image sizes, I wonder if they would be disfunctional if I didn't include dimensions anywhere -i.e. does a browser need to be told the size at all? Perhaps it's time for some off-line experiments...

But that - like attention to many other details - might have to wait. After 2 months of solid slog, I've got all my pages up & need a rest.
All done with a CSS style sheet! (It's a tiny but powerful 12 KB.) In case anyone's interested, it's at -

And yes, it's got -
TABLES!!!
It's a site made originally in 1996, when tables were the only smart way to go. With CSS, I've rarely been tempted to use tables for layout, since I appreciate that the same effects can be achieved, with added refinements.

That said, one of the biggest obstacles to anyone starting on CSS for the first time, is the rabid ravings against tables one continually encounters on the internet. (And I don't mean any of you, by that.) People like me will just dig their heels in.
In fact, one of the greatest aspects of CSS is the degree of elegance it can give any table. The W3 tutorial on the subject is a delightful start!

That's a good tip - of 100-200 images, I only have one that repeats, at a reduced size. It must be relying on the inline styling at the moment, to shrink it down. A lucky escape! (It may be easiest to make up a reduced version, with a different name, just for this instance.)

A remark about images - the pixel dimensions of Photoshop & CSS seem to match on screen, for the most part. There may be discrepancies if a class has been applied, to shrink text to a certain %. It might do the same to the image...

You may be pleased to hear that, although I still have several tables throughout my site, none of them are for layout purposes! But tables are still one of my favourite things - from classic table borders around a set of definitions to separate them from the text, to colour charts with no data at all other than the colour swatches.
But even tables have their limits e.g. a colour chart where each swatch has its own symbol/pattern/gradient. Then the combined powers of HTML & CSS are to no avail, & only a trusty jpg can save the day.