Written on 2/7/2014 in Web development

Today I will be talking about the merits of writing posts in HTML. I'll conclude this quite fast, it sucks. It's not made for it and it's definitely not good for it. I looked at some WYSIWIG1 2 editors with which I had the pleasure of working with a few years back. My feelings about these editors are mixed. I like how easy they are to implement and some of them work really great. But, there's a big but.

WYSIWYG editors are great when used where needed, credit where credit's due. I used it in a CMS written in PHP a while back. The users were not tech-savvy so there was no need to make it harder for them than it already was. I was not going to try and explain to them that everything between '<b>' and '</b>' magically transforms to bold printed text. They had to have text and when they highlighted the text and pressed the BOLD 'B' icon, the selected text just had to be shown as bold text. Not just boxed in some tags ([B]text[/B]) like you see in some forums. Granted, most of the time, a preview feature is provided, but still, they would keep tampering with it because they just don't care to understand.

In the last few years however, there's been a big surge of interest for the Markdown specification. For a brief moment there was even a move to make it a standardized specification for use on the massive plains of The Internet. This move quickly resulted in a desolate desert where the tumbleweeds roll quietly across the landscape for reasons unknown. However, the markdown specification was very much alive and has a vast camp of followers, providing big user maintained sites with a beautiful writing syntax.

Some of them big names like:
StackExchange
StackEdit
Github

Documentation is very easy to find and the specification is deliberately held very compact. When using it, you feel like you're in control of what's happening with the presentation of your text in a way where WYSIWYG is just too obscure. Markdown was intended to be like this and it's one of its biggest advantages. The raw unformatted text has to stay adequately readable and compact. You can easily distinguish titles, lists and links. So I was very eager to try it in action. Because of the compact rules, a lot of sites also extend the spec to make their own markdown flavour. Whether this is a positive argument or a negative one is not clear. But I'd rather have an easy to extend simple library than a bloated black box. But enough about the spec itself, let's get down to business.

There were a few options for how to handle the editing part.

1. You write the source in some plain text editor and copy paste it to the db
2. You write on Stackedit so you can easily see results and then copy paste it to the db (or some other options might be possible here too..)
3. You write it in a custom made web page

As a matter of fact, I don't think the way you edit it matters a whole lot. This is where [SOC] excells, a good separation means that it doesn't matter at all how the posts are getting in the database. As long as it gets there. The way it gets persisted isn't a concern to the presentation. For the time being, I'm quite happy writing in notepad. I might even start with just writing the HTML for a while but I'll have to prepare for these changes. Since the spec is quite limited, I can foresee a future where I might want some custom transforming. Therefore I'll probably go with option #3. There's a base JavaScript (and a lot of other languages) library already available for this: Markdownjs.

Presentation could also be done in a few ways.

1. Transform to html client side (write & transform on the client, send the original text + marked down text to the server)
2. At runtime (on every post request, transform original text, client or server side)
3. After edits (Some kind of trigger that transforms it when the original text is changed in some way)
4. Transform to html server side (write on the client, send the original text to the server and then transform it)

This is quite simple, the "at runtime" option is never going to make it. It doesn't make sense in this application to convert at runtime. It would only cause a performance drop. Server side after edits is tempting. It's easy to implement but if I want some way to check how my text is formatted It could generate a lot of unnecessary traffic. I believe client side transforming is the best way to go here. This way I can easily update the generated html and display while I'm writing my posts.

The post editor looks like this:

It doesn't look amazing and perhaps it looks a bit cluttered but there's no need for more complexity right now. Plus, I'm the only user so I actually have a stunning 100% customer satisfaction. The inner mechanics are very easy. On an update / change to the Text textarea, I format the text and update the Formatter text with the generated HTML. Added to that, the formatter result displays how it would look on a page.

I'm reluctant to show my code for the manager here because it's very ugly. But I'll share a little secret. While the Blog itself does not use JQuery and as few libraries as possible, I do use JQuery and as much libraries as possible in the manager. Mainly because I'm rather lazy and the performance is not as important in the manager.