Someone left a comment in my previous blog post and related a problem his wife is having over the WYSIWYG functionality of her blog post editor. An image with some text wrapped around it looks one way in her blog editor and another way in her blog. In short, what she had seen (in her blog editor) was not what she got in her blog.
I have never thought of that problem before. When I draft my posts, I already know the width of my blog’s post area; so, I would not insert any image wider than that. For wider images, I would crop or resize them first or use the height and width attributes of the image element. As to text wrapping, I only do it when the image width is less than or equal to half the width of my blog’s post area.
But users should not be forced to know these things and the comment reminded me of that. Working so long as a techie made me forget how normal people use software. Software should serve people and not the other way around. It was a refreshing eye opener and all software developers should receive comments of that sort and pay attention to it.
And looking at the current crop of blog editors, it would seem like developers are paying attention and are trying to address the issue as best as they could. I found out, based on looking at the post editors I have downloaded, that they address it using three main approaches:
- The blog editor allows you to specify a local stylesheet or to enter style definitions or properties, which mimic the style of your blog, in the editor itself;
- It publishes your post every time you hit preview and displays your blog in a browser then deletes the post afterwards; and,
- It downloads your blog’s template once and uses it locally every time you do a preview.
The first way for a blog client or post editor to have some recognizable form of WYSIWYG functionality is to allow the user to specify a file in her computer containing CSS statements or properties. It could also allow the user to enter CSS style properties directly in the editor itself. The editor then uses this information to display the contents in the preview window every time the user tries to preview. This is good—but only if you know CSS in the first place. Also, you need to know the particular properties used in your blog and their corresponding values; otherwise, this is good exercise of guesswork.
The second method I have seen post editors do is to instantly publish your unfinished post. Let us say that you’d like to preview your post while still halfway through it. Everything you have written up to that point will be published “temporarily” to your blog. Your blog is then loaded in a browser and you see your post in it. After you close the preview pane or window, that post is deleted from your blog.
It could be argued that this is the most accurate method because what you see in preview is your actual blog so that is really what you’ll get. One problem I have with this, though, is that you might forget to close the preview window and leave it open for a long time. Your unfinished post is public during that time and visitors might be able to see it dangling in your blog. So, if you use this type of post editor, close the preview window first before you answer that phone!
The final method is the one I like most. The post editor downloads your blog’s template during setup or configuration and uses it offline to preview your post. What is displayed during preview is not the real blog like in the previous case but it’s close enough. For layout purposes, this should be sufficient—and safer.
So far, these are the methods used by post editors to give you WYSIWYG functionality that I know of. Each have their own set of advantages and disadvantages. Knowing them helps you decide the best one for you and avoid potential pitfalls.


Great info! We'll keep following your progress.
ReplyDelete@anonymous, thanks. I'm glad to hear that.
ReplyDelete