Last week I installed and played around with Windows Live Writer a bit for blogging entries and getting them posted to my blog. All things considered Windows Writer works pretty good – unlike BlogJet, Writer managed to get my posts over intact and images uploaded properly (BlogJet never worked with my FTP server for some reason)…

 

But overall all of these products have the same shortcomings: Dealing with code in the editor. The problem here is that all these tools use the lousy IE HTML Editing control that can only be pushed so far to handle formatted text pasted into it. Stock IE HTML controls do horribly if you paste in a raw code snippet from VS.NET for example, or other Microsoft tools like Visual FoxPro, because these environments post the code as RTF text.

 

What really irks me about this is that it would be trivial to fix these issues by providing smarter Paste handling. The ability to Paste Special and treat the inbound pasted text as RTF and convert it into HTML. Converting RTF text to HTML is not complete rocket science and could be reasonably easily implemented. Instead pasting RTF code out of VS.NET results in colors preserved and all space formatting and font information lost. Yuk… In other editors pasting RTF code results in even worse results that preserve the colors but loose the font information and most importantly the spacing.

 

And all because of the damn IE Web Browser Control and the shitty HTML Editing platform it provides. We see this crap everywhere in editors that have funky behavior similar to do this. Outlook Express, Outlook 2003 (although there’s some improved format handling there) and countless third party applications including one of my own – Help Builder – in which I’ve fought with trying to get editing to work reasonably well.

 

It bugs me especially with Windows Writer which doesn’t even make an attempt at trying to deal with Post data well – it pastes any pasted text as plain text into the document losing all formatting – right there you can forget using Writer for a technical blog. And it’s pretty clear that that’s the audience for this tool – well it’s a beta we can hope that something will happen there to make this easier.

 

What I’d like to see is a Paste special dialog that pops up and can either convert from special types or in the case of code provide you a language selection dialog – that’s essentially what I do in Help Builder, where there are 3 Paste options: Plain HTML Edit text paste, Code or Formatted text Paste (which pops up a selection of which type of Code Language to paste) and Formatted paste which takes existing HTML and formats it into Help Builder’s custom format. For code snippets the Code option is certainly nice.

 

But should it really be all this difficult? Why is Visual Studio outputting code snippets in RTF format in the first place? Ok RTF is OK, but how about the way more common HTML output? You can use plug ins or macros to do this, but this should just work out of the box with standard cut and paste behavior.

 

When I’m in the middle of writing a Blog entry I don’t want to have to worry about formatting text or running special tools. All I want to do is cut and paste a block of code (or text or whatever) and paste it. In the end I just keep going back to Word because it just works the way it’s supposed to: You can get text into the document from anywhere without any special thought. It just works without having to think about it. Word of course has the nasty side effect of spitting out brain damaged HTML, but that’s another story.

 

HTML is one of the most widely used text format these days, yet there’s virtually no system support for creating it effectively with a WYSIWYG interface. We have 10 different browsers out there, but none bother to provide a decent HTML Editing interface that’s reusable. There’s progress for ‘ya.

 

I’m glad to see that Microsoft internally has moved away from the IE Html Editor and moving towards the Expression HTML Designer which looks to be a much nicer editor which should ease some of the Html editor inconsistencies in the future. Word is that the next version of VS.NET is going to use this editor as well – maybe we’ll finally get a visual editor that is actually usable <g>. Unfortunately for the rest of us (and third party application developers) building applications, there are no plans to expose this designer to applications.