Updated: September 29, 2018
Once upon a time, visual HTML editors were all the rage. You would open a browser-like program and just type your pages, without thinking too much about the source code, the scripts, or even the looks. The magic happened somewhere behind the scenes. Then, slowly but surely, online CMS started showing up, and eventually became the modern norm. But what if you still want to write Web stuff offline?
It does sound a bit like a paradox - after all, you WILL be uploading your material one day. Still, being able to write in an offline manner has its perks and convenience. Moreover, if you do not use any CMS, writing pure HTML can be tedious. Having a nice frontend helps you focus on what you want people to read, not necessarily what machines ought to be interpretting and displaying. The question is, how difficult is this to achieve in the year 2018?
HTML editors, at your service
Once upon a time, there were dozens of WYSIWYG editors, all offering their own wonders, as well as their own range of inconsistencies, garbage code and functionality. I came across the old Nvu back in 2006, upgraded to Kompozer when this one came about, and kept on using it ever since in some form or another, as it offers the simplicity of writing stuff without having to worry about code, plus some serious usability benefits that no other program seems to offer. But then, Kompozer hasn't seen any updates in a long while, and some refresh is needed. What do we have on the table?
Bluefish
This program has been around for a long while. It's not a pure WYSIWYG editor. In fact, it's no different than any text editor in this sense. The best it will do is just launch an external browser for you. Seems decent, but ultimately, Bluefish feels clunky slash nerdy and not what we really require for simple writing.
Moreover, I encountered various problems while using it. For instance, it has a very rich output sub-menu, and it can validate code, convert HTML to XML, tidy HTML, and so forth, but then it failed to launch Tidy, even though the program is installed in the system.
Brackets
Modern, slick, and maybe somewhat overwhelming, the best way to descibe Brackets. Actually we talked about this program at some length in my OCS-Mag article on HTML editors from 2015. It is a utility that tries to span the classical world of writing with the new metadata-rich world of code writing. It is also designed for more skilled users, not newbies. Brackets has a live preview function, but it does not really show you what your pages look like when you write them. So in essence, it's not exactly what we're looking for.
Bluegriffon (BlueGriffon)
This is a successor to the old Nvu editor - which was also forked into Kompozer, now long discontinued, although still perfectly usable, at least in its Windows form. In Linux, you will need to use old libraries, and this can be a pain. Anyway.
Bluegriffon looks the part and it handles HTML5 just fine. There are some rather neat options overall, and in essence, this is the one true WYSIWYG left around. While it mostly does what it should, and new users will probably be oblivous to any issues that exist on the code level, I encountered various issues that made me wonder if there's really any future for offline HTML editors.
Bluegriffon has some glaring usability problems. If you are adding images or linking to other documents, they are marked as absolute paths - and not relative - by default, which makes for a tedious extra click everywhere, or broken pages if you forget to do so. If you're wondering what I meant, say you want to link to a page named dedoimedo.html that is in the same directory as the file you're currently writing. In relative terms, a href="dedoimedo.html" is a perfectly valid link, and as long as the two files are in the same directory, this will work just fine. Absolute means something like C:\dedoimedo\dedoimedo.html, which is meaningless online, and will break just about anywhere outside your local computer.
You need to manually tick the box. Every time. Bluegriffon also does not use shortcuts as much as Kompozer - you have none for inserting links, images or invoking the spellchecker. Middle click doesn't do anything useful, while in Kompozer it opens and closes tabs (documents), as any modern browser really should. If you want to mark a portion of your text and style it a certain way, you must first define it as a span and then apply the class/style, whereas Kompozer does this automatically, saving you clicks and mouse actions. Lastly, Bluegriffon also changes the code, but more about that later.
SeaMonkey (Composer)
When I said Bluegriffon is the one true WYSIWYG left around, well, I was wee exaggerating. Among those currently actively developed and supported, and those that I got to test, there happen to be TWO, except, they are very, VERY tightly related. The Jack-o'-All-Trades SeaMonkey suite also comes with Composer (distinguish this from Kompozer), and it offers a similar functionality if slightly different looks to Bluegriffon.
Essentially the same advantages and pitfalls are there, including HTML5 support and issues with images. Here, the problem manifests in a different way. On some pages, it would not link any new images. On others, it always starts with an absolute path (prefixed with file:///), and the Relative URL checkbox is grayed out. You actually need to manually edit the URL and strip out the non-relative portion before you can actually make it all work. This is slow and tedious. And even though SeaMonkey does have a button that says it will preserve original source formatting, it does not really do that. More about code changes later.
In general, there were some rather surprisingly clunky options, which I find quite odd as they were resolved in Kompozer a long time ago. The setup on Linux also requires a handful of 32-bit libraries, otherwise you may hit the following error:
XPCOMGlueLoad error for file /home/roger/Downloads/seamonkey/libmozgtk.so:
libgtk-3.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.
For me, the full set of needed libraries (which auto-resolve dependencies) included the following - tested in various guises and forms on 64-bit versions of openSUSE KDE, Kubuntu and Ubuntu.
libgtk-3-0-32bit libgthread-2_0-0-32bit libXt6-32bit
Kompozer (KompoZer)
The old and trusted workhorse. Kompozer has no support for HTML5 and CSS3, so things will look odd if you try to load modern code. On the other hand, it has by far the most streamlined workflow, with shortcuts, relative links, and a few other quickies that all other programs miss. The latest release dates back to 2007, but there's a beta version from 2010. Golly.
HTML Tidy
As it happens, I also wrote about this topic, back in 2009, almost a decade back. I showed you the wonders of HTML Tidy, then available in many guises and forms, including a Firefox extension (the good ole days) and a Notepad++ plugin. There was a GUI, and a separate tool to prettify your CSS. The choices were many and plenty.
In 2018, things are a little different. The original Tidy sort of died, but then it was resurrected recently, with the focus on making it HTML5 compliant. It now lives as a standalone program, a loadable library (DLL), and it can also be installed as a Notepad++ plugin under the name of Tidy2.
Setup problems
But it's not all smooth sailing to Cape Good Code. I wanted to see how well this new Tidy works. In Linux, I already had the old Tidy installed, and I had to force uninstall it and its associated libraries before the new one would install. At least everything comes from the repo, so you do not need to sweat it.
In Windows, the standalone and the DLL work all right. In Notepad++, you can only use plugins with the 32-bit version of the program. The old HTML Tidy is completely broken, and if you try to run it, Notepad++ will disable it. To get the new one, you must first update the text editor to the latest version and then use its plugin manager to install Tidy2, which is based on tidy-html5. There.
You can also use the standalone version on demand through Kompozer. It does sound weird, but Kompozer has its own extensions, one such being HandCoder, which can invoke the Tidy executable on demand. Technically, you can set its path to any which version of Tidy, including the latest builds (Nov 2017 in my tests), and it will run them just fine against old and modern HTML pages. In fact, the 2007 Kompozer and its long-outdated HandCoder extension can summon Tidy versions from 2005 all the way to 2017. Nice.
Using the new Tidy
Overall, the program seems to work well. I was particularly impressed with Tidy2, which seems to offer a much wider range of flags and options. The online reference is a decent time killer, and you can spend a good few hours trying to figure out how everything works.
All that said, there were also many problems with new Tidy/Tidy2 and how it manipulates code, and I find it rather odd that people who developed this - serious and smart nerds that they are - didn't think about some rather obvious choices in how their little program outputs tidied markup.
Focusing mostly on Tidy2, first, it uses spaces to indent code - not tabs. This is wasteful for large documents, as you end up with more characters, and eventually larger files. 1K tabs becomes 4K spaces. Second, it mangles code, including scripts and script attributes. This can be a big problem if you use snippets of Javascript and whatnot from publishers like Google (Adsense or Analytics), for instance, which mandate that you use their stuff as is. It will also replace special characters like quotation marks or ampersand, which could break scripts and their URLs.
At this point, I decided to consult the available reference pages - they come as an offline page through the Notepad++ interface, or you can read them online, although that list seems to date back to 2008. You have three configurations, and you can tweak them individually.
Anyway, the config looks something like:
indent: auto
indent-spaces: 2
wrap: 120
markup: yes
output-xml: yes
input-xml: no
quote-marks: no
quote-nbsp: no
quote-ampersand: no
...
I learned, through many hours of trial and error, that if you wish to keep your code as pristine as possible, both in looks AND functionality, then you should set the following variables:
quote-marks: no
quote-nbsp: no
quote-ampersand: no
preserve-entities: yes
literal-attributes: yes
At the very least, the following five lines will ensure that your URLs and script vars remain unchanged. But Tidy2 (and Tidy itself of course) will still edit and change things like forms and ins blocks, even if you do not ask them, making its use alongside third-party code snippets virtually impossible. For example, this won't ever work:
<ins class="adsbygoogle"
style="display:block"
data-ad-format="autorelaxed"
data-ad-client="ca-pub-xxxxxxxxxx"
data-ad-slot="yyyyyyyyyy"></ins>
This brings me to several key points - why does Tidy not allow skipping certain parts of the code. And why is it not possible to markup the code nicely without any manipulation. Tidy should tidy - not validate code - or at least, this should be optional. When it comes to pretty looks, I have implemented something similar in my own little program called recursive LDD, which is a recursive implementation of the LDD program. Whenever it outputs code on the screen, it calculates how many tabulations are required to indent the printed text based on separator (tab) x number of entries into the recursive function. The same can be done here without changing HTML into XML and whatnot.
Here, we encounter other problems. If you select markup=no, Tidy will wipe the document clean. If you choose output=html, it will do nothing - it won't indent anything and/or delete blank lines.
Other inconsistencies
Worst yet, there does not seem to be a standard on what the output should look like. Having worked with Tidy for the past 12-13 years more or less, I've seen at least three or four different ways it manipulates code. For instance, the 2005 version formats paragraphs in the following manner:
<p>
Text here
</p>
However, the new Tidy does it like this:
<p>Text here</p>
Old Tidy would use the next-line drop and then indent for ALL elements. The new Tidy only does this for certain elements (like divs), but not paragraphs and lists. Then, there's the matter of code incapsulation. The 2005 Tidy did not change scripts in any way - although it still mangles forms and ins. The 2009 Tidy would actually wrap code in <![CDATA[]]> blocks. The latest Tidy seemingly behaves like the 2005 version, except it adds an almost random number of indent spaces, pushing scripts deep into the code blocks, in no way related to the 'tidied' hierarchy output. As you can imagine, this presents a big problem, especially if you have tons of files, and you do not wish to have to manually validate the output of a program that is supposed to make the changes for you.
Problems with code output & other HTML editors
Alas, Tidy is not alone in making undesired changes to the HTML code. Bluegriffon also does its own thing. If it encounters the old syntax of open paragraph bracket, new line, text, new line, close paragraph bracket, it will then inline the code thus:
<p> Text here </p>
It will actually ADD two spaces to the beginning and end of the block. Worst of all, these do not display on the screen, so I am wondering what goes on behind the scenes, and why this weird convention. It will also add these spaces between other elements, like images and closing divs and such. Maddening.
Bluegriffon also has its own markup function - I tried it - and it changed some of the code, but each time showing a different number of lines. Once edited, the marked-up pages were horribly mangled. Some of the divs were just completely ruined. Last but not the least, Bluegriffon also mangles forms and ins blocks.
SeaMonkey (Composer) had similar issues. It also changed paragraph lines, only it used its own styling to do that, meaning extra tabs PLUS padding spaces. And even with the right box checked, it still edited the source, mangling the ins blocks.
Conclusion
Yes, I know. Writing standalone code is probably not the "modern" way of doing things. Then, if you do want to do a simple HTML/CSS job with valid code, you're in serious trouble, because you need to choose between text editors and code-munching visual editors that don't really shine at what they profess to do. Plus, when it comes to code tidying, my oh my, this is Wild Wild West. Beware, because you could really break your scripts and forms, and worst of all, there does not seem to be any convention on how your code ought to be broken. Finally, with changes looming over the world of CMS, like the WordPress Gutenberg overhaul, I am really worried what the future of clean code holds for us, or if there is even going to be any such future.
Ironically, it is the 2007 tool called Kompozer that does the best overall job here, despite its inherent limitations and no support for modern standards. But then, it is the least intrusive of the bunch, and also the most productive. Bluegriffon and Seamonkey work fine, but they blend these ancient problems with modern looks, and that does not help in any way. Kompozer resolved the early 2000s UI bugs, and it should have been the baseline for future iterations. In the end, you are left with sub-optimal choices.
No matter which way you go, you will need to compromise between ease of use, visual convenience, code chaos, and plain efficiency. It would seem that Year 2018 has little sympathy for those who want to do their work offline or use tidy, compliant code. On the bright side, you can go wild with Notepad++ or Brackets. So there's that at least. In essence, we have come full circle, and haven't really gained anything. On the far side of the spectrum, the online CMS world is like the cloud journey. People have these lovely API to run their stuff and fancy-ish UI, but they don't really have any access to the stuff behind the scenes, and it's a horrible, complicated mess. What You See is What Once Was. Welcome to Abstraction. Dedoimedo out.
Cheers.