... And you don't have to worry so much about content becoming unreadable after 10 years or more, just because you have moved to a different version of Office.
Yes, think many of us have been there. I'd definitely strip out any MS coding from the result before I used it.
Regarding the page you attached to this post, there's a huge css <style> section, and it uses tables for layout. I've been using HTML5 for at least two years, and it's also a lot easier with GRID, going back to this - while just having to concentrate on content is "easier", but is psychologically "ancient and unclean". Note the design brainwashed response, . So I'll keep it in mind for if something else doesn't work, or it more trouble than its worth. But Shades, thanks again for the suggestion and attachments. I appreciate your effort and time.
The reason why I like AsciiDoc is that the document itself is text-based and human readable. The conversion to HTML was done with the HTML converter that is built into the AsciiDocFX editor and apparently does generate old-skool HTML. The example I created has a lot of content pretty much suited for tables, so it seems a pretty logical choice
The converter in the AsciiDocFX editor can generate 1 file only, unfortunately. Separating content from layout is an excellent idea in most, if not all, use-cases.
Tables and HTML...a no-no nowadays. The bad thing about tables is that they put some (severe) limitations on content. The good thing about tables is that there is no browser that interprets tables different than the others and all of them render tables really fast. Trouble does start when you start nesting them for layout purposes. Talk about a Pandora's box that should never have been opened...
Believe me, there was little effort involved with the creating of the AsciiDoc pages. It took more time writing the initial post (I tend to be a bit long winded with those, as you notice with this one yet again