WordPress dot com’s “Visual” editor sucks, and it’s “HTML” mode sucks worse.

Update: This post title started out as “Figuring out WordPress dot com’s Visual and HTML editor modes”.  However, as I spent more and more time sussing out the workings of these, my opinion dropped a bit.

Since my search for an offline WordPress.com editor was a bust and my efforts to learn their online interface aren’t going well either, I suspect my best long term option is going to be using Composer to develop some custom templates which I can fill in offline and then Copy/Paste to the WordPress online “HTML” interface.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you’ve stumbled across this entry and are hoping it will help explain the mysteries of the WordPress.com online editing interface… well, don’t count on it.  I’m still struggling to wrap my brain around their concepts of of “Visual” and “HTML”.

Visual it isn’t.  That would be a “WYSIWYG” editor.  And this thing falls way short.  Pretty bizarre considering it’s an editor dedicated to solely to writing for their web service.  Other “offline” WYSIWYG editors have had to contend with never being sure what kind of a web server the resulting pages would be displayed from.  The WordPress team has the luxury of only needing their editor to be correct with their website.

As for “HTML” mode, it’s not what I was expecting either.  It hides some of the basic HTML tags, probably in the interesting of being more “beginner friendly”.  Unfortunately there aren’t any menus to guide a beginner with selection/application of HTML tags.  So the “beginner friendly” idea falls flat too.  I’m not HTML guru, but in the past I have hand coded some web pages using plain text editors.  For years I used Netscape Composer to create and maintain project documentation and reports.  Composer supports pure HTML editing as well as a WYSIWYG mode.  Fortunately Composer is still alive and well in the Mozilla SeaMonkey Project.

If the WordPress.com teams want the “HTML” mode of their online editor to be friendly, they should include some menu options.  If they want it to be expert friendly, then it should really show all of the tags.  In either case, I hope they at least look at some of the other tools out there.

Below are the results of some testing I’ve been doing to grasp the behaviors of the “Visual” and “HTML” modes in this editor tool.  It’s fairly random, nonsensical stuff.  Just a lot of typing things in and switching between Visual, HTML, and preview modes to see what effect things have.  I started out trying to solve one of my most glaring frustrations with the editor… single spacing vs double space.

I’ve found the line spacing tricks.  Either have to switch back and forth between Visual and HTML modes, or while in the Visual Editor mode, the key combination “SHIFT+RETURN”  will do a normal new line (without the double spacing).  Note: solving the next problem brought the double spacing back.

Next is finding how to get the editor to respect indentation of the first line in a new paragraph.  None of the normal HTML tag tricks I’ve used elsewhere work here, and I don’t like the idea of embedding transparent images to force alignments.  Quite a few folks across the web recommend using CSS, but I wanted to try inline HTML tags first.  Some further searching turned up a suggestion to wrap the paragraph in a tag like this:

<p style="text-indent: 2em;">  Put the text of your paragraph here. </p>

Of course, that led to the question of how to quote source code in a WordPress.com post. Fortunately I found the answer from WordPress support.

Time for another save and preview.

Wow! What a waste of time.  Anyone reading this will probably notice that the paragraphs are still double spaced.  Added the indentation tag modified the paragraph spacing (this is starting to remind me why I’ve never enjoyed coding web pages).  And the extra “code” which was supposed to display embedded source code is actually displayed right along with the HTML that I was trying to display.  In other words, I did not intend for the [Source language blah blah blah] stuff to be visibly displayed… only the actual HTML tag contained within should have been displayed.

Using the HTML editor to “fix” the source code quoting seems to have turned it into a pre formatted paragraph ?  Time for another preview.

Well, that was closer.  Returning from preview I think I can see what needs to be fixed in the Visual Editor.  The embedded HTML tag for paragraph formatting should now display as an inline code snippet.

Ok, I’ve had enough of this for now.  When I pick this up again, I’m going to focus on creating an offline SeaMonkey Composer template that can be pasted into the WordPress HTML editor interface.  I’m sure that will require some trial and error to figure out compatible tags and fit things within the active “Theme” layout.

Additionally, I need to do some more Theme research.  I’ve got a couple web pages (which I built nearly 10 years ago) that have displayed just fine on four other hosting services, but the every WordPress theme I’ve tried mangles them.  Redesigning them isn’t an option, so they may just remain with the other hosts.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

How now brown cow.

How do you get the line returns to use a smaller spacing?

The editor seems to be “double spacing” each new line.

Really looks like 2nd grade.

On other hand, if you keep typing more sentences without a line return (ie., run on paragraphs), then the automagic line spacing seems to like “single spacing” just fine.  So what does this WordPress “Visual” editor have against single spaced paragraphs?  And how to you override it?

By the way… searching the internet for technical information about WordPress is a real pain in the arse.  It’s effectively impossible to specific that a search should only return information about the actually “wordpress.com” rather than the hodge podge of “hosted wordpress” implementations running countless other servers.  What’s the big deal?  Well,   the folks writing semi-technical information about WordPress features often are referring to a “hosted” implementation with features, options, and plugins that don’t exist on the WordPress.com service.  So basically there is a multi-verse of infinitely different configurations… all using the same dang name.  Blog. Blugh. Blehccchhhh!!!

Maybe I should get off my lawn.  Dammit.

~
~
~
PART II – Messing about in the HTML editor.
One potato.
Two potato.
Hey, the spellchecker keeps k-recton my tater spellings but didn’t even show a red squiggly for “k-recton“?
So that’s about 9 lines that ?should? be single spaced. But I didn’t add any HTML tags, so maybe they’ll all be treated as one ugly long paragraph of nonsense? Time for the preview button. I suppose.

PART III – Preview results were interesting.

How do you get the line returns to use a smaller spacing?
The editor seems to be “double spacing” each new line.
Really looks like 2nd grade.

The line spacing stayed the way I intended. Switching back to the “Visual” mode, the text/line layout was still correct. Using “visual” to paste more lines (double spaced) and then use the “HTML” view to remove the extra lines. After that, the layout persisted while moving back and forth between the two view. Additionally, after getting the text/spacing straightened out in “html” view… It was then easy to go back to “visual” mode and apply additional treatments such as bold, italics, color, etc.

Ok, now for some more editor exploring... What the heck does "Preformatted do?  As far as I can tell, it makes this paragraph have a gray shaded outline, and an old school font. Yet, the other treatments are still available.  So I still don't have any idea what "Preformatted" really does.  [Time for preview button again]

Hmmm… back from the preview.  The “pre formatted” paragraph above displayed in the browser as an embedded gray area containing a single line of text and a horizontal scroll bar.

Line 01 - How now brown cow, this is the first line in of text which should be way to wide to display in a typical browser width unless their is a horizontal scroll bar to slide farther and farther and farther to right... keep going, not there yet.  Really?  Are we there yet?  No.  Not long now.  Drat, I can't get those kids out of my head now!  
Line 02 - ???puzzled facial expression???  Hitting a hard return key seems to have completed the "gray area" outlining "Line 01" and started a new gray area outlining Line 02.  Let's try another hard return key.
Line 03 - Yup.  Using a hard return in a "pre formatted" block of text appears to start a new one.  [ Time for a preview ]

Back from the preview.  Well, that worked better than expected… sort of.  While originally typing, the three lines appeared as three separate areas of text.  But a preview displayed them in the browser as one embedded block (kind of like the way folk embed source code in discussion threads sometimes).  But now that I’m back in the WordPress.com “visual” editor mode, the 3 lines of “pre formatted” text now appear as a single gray area of text with line wrapping.  [Time for another preview ]

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s