Back on February 8th, 2009, community member tekzt asked if I could some how get Andrew Ozz to appear on a future episode of WordPress Weekly for an interview. Hey, I like suggestions so I followed up on tekts request and sent a few emails to Andrew. He responded back that due to personal reasons, he would not be able to effectively appear on an episode of WordPress Weekly. So instead, I sent a list of questions that the forum thread generated as well as a few of my own and he answered those. Without further adieu, here is the interview revolving mostly around the visual editor within WordPress.

Jeff – Hello Andrew, thanks for taking time out of your busy schedule to conduct this interview with me. Before we dive into the questions, first tell us what it is you do as it pertains to the WordPress project.

I work on all parts of WordPress, perhaps more on the admin UI, (PHP, Javascript, CSS, etc.) trying to get it all working nicely in most newer browsers. I’m also one of the devs that have commit access to the WordPress repository, so part of my job is to test and verify patches and commit them.

Jeff – What has been the most challenging aspect of integrating TinyMCE into WordPress?

Would have to say keeping it backwards compatible. I’ve started when TinyMCE 3 came out and it had quite a few differences compared to version 2.x. One of the hardest parts was to make it compatible with wpautop.

Perhaps in the future we will have to reevaluate the autop system that stores the posts in the database with most P tags stripped and has to add them at each page load. This works nicely for simple html but now that WordPress is being used for many different types of projects it may become a problem/slow down page load.

Jeff – Why is it that a few of the most voted on ideas revolve around either improving or replacing the TinyMCE editor?

Yes, three of the top five ideas are about the editor but most suggestions and wishes there have been implemented. Looking at them most comments are from at least a year ago. Also most people don’t seem to realize that it’s the browser trying to render their html code in the visual editor and sometimes failing.

Jeff – Why is there such a difference in the way in which code is treated between the visual and HTML editors?

It’s not that much different. Main difference is the js version of wpautop that is applied to the content of the HTML editor when switching to the Visual. It has to insert the missing P and BR tags so the browser can render the HTML code.

Jeff – How large of a role does the end users browser play with regards to how the visual editor behaves?

There are several misconceptions about the visual editor. Couple of them are that it is a HTML editor and that it’s a stand-alone software program.

1. The visual editor is a text editor. Yes it uses html in the background to describe the text formatting but it works and behaves as a typical text editor. Both OO Writer and MS Word save files in xml format, but that doesn’t mean they are xml editors. I know quite a few people try to edit the raw html and then switch to the visual editor to see their changes. This usually works well with simpler html code. Don’t think that many people would try to edit the raw xml of a Word document and then load it in Word to see the changes there :)

2. TinyMCE is quite a complicated app written in Javascript but it runs in the browser like all js apps and ultimately the browser is in control. The Visual editor is a part of the browser, same as the textarea of the HTML editor. All browsers support the so-called “contentEditable” areas that can be applied to an element (usually textarea, div or iframe). Unfortunately the features supported there vary quite a bit between the major browsers making it hard to use.

Jeff – TinyMCE is labeled as a WYSIWYG editor. However, in my experience most times what I see is not what I get. For example, I’ll be in the visual editor and block quote a piece of text. But when I press enter to begin a new line, my cursor is stuck within the blockquote tag. This also works for any other styling elements as well. Why is that?

I think the WYSIWYG a.k.a. RTE (rich text editor) comes from the early implementation of support for editing in the browsers. So it’s a dynamically displayed html (WYSIWYG) as opposite to typing html code in a textarea. That was before CSS was adopted so all formatting was in the html code.

There are three types of buttons in TinyMCE. One brings up a popup, the other affects selected text only and the third acts as a toggle switch. The blockquote button is of the third type. It can also act on selected text like the align buttons. The toggle can be turned on at the beginning of the blockquote then turned off on the next paragraph after the blockquote, the same way as in Writer and Word. Alternatively a blockquote can be applied to one or more paragraphs after they are written.

Jeff – My argument against using the visual mode of the editor is that end users need to know about the quirks before hand in order to be the most productive with the editor. Do you feel the same way?

Of course. The users should know about the quirks of any software they use in order to be more productive. However in reality most users know and use only a fraction of the features of particular software and don’t need or want to learn about the rest. The few users that take the time to go through the learning curve become the “power users” of that software and then they reach the point where knowing how to work around any quirks would be useful.

From my research over 95% of the WordPress users have some knowledge on how to use a text editor and expect TinyMCE to work in exactly the same way. Most don’t care how it works or why it works and don’t want to “mess with” html code.

Jeff – Why does the visual editor use “B” for “bold” and “I” for “Italic” buttons? This is really misleading for the user, as it actually marks the text up with
Code: and Code: tags respectively, and the style sheet may not specify these styles for those tags.

The answer is simple: the same reason the HTML editor, OO Writer and MS Word use these buttons. They are the first letters of the words (and have nothing to do with the html tags with the same names). I think it would be really misleading for the users if we have a STRONG and EM buttons instead of the widely accepted B and I.

A theme designer can decide how to handle the strong and em tags like pretty much any other html tag. It’s another question whether the users like the design…

Jeff – Why not label them “emphasis” and “strong”? This would help promote semantic content to users, rather than encouraging them to use these semantic HTML tags just to make their text look pretty.

Perhaps that would be appreciated by a few users but the great majority would be against it. We cannot forcefully educate the users, that never works.

Jeff – Why does the insert image not always insert where I have the cursor?

In the visual editor it should always insert it at the cursor, even in Firefox that has big problems with cursor placement in contentEditable mode. The only time I’ve seen it fail is when another program on the PC steals focus from the browser (like a warning message from the OS or a chat window, etc.). The HTML editor can sometimes loose focus when the browser has been used for a while (doesn’t seem to happen in WebKit browsers).

Jeff – How closely tied together is a themes CSS file with the styling elements in the visual editor?

There are several ways to apply styles to the editor iframe. However they are all theme dependent and would need to be changed for each different theme. This is not hard to do but I don’t think I’ve seen any themes that do it.

Jeff – Will the visual editor ever reach the point where everything truly is what you see is what you get? Or does the difference in browsers/javascript not enable that to happen?

Perhaps but first the browsers’ support for contentEditable elements would need to improve a lot. Currently all major browsers have many quirks, bugs and inconsistencies there. Large part of TinyMCE deals with this, working around the bugs and normalizing the methods. Don’t think many users are aware that there’s a whole plugin just to work around the shortcomings in WebKit based browsers (Safari, Chrome). Also until recently (version 2.x) Firefox was replacing STRONG and EM with B and I to be able to display them.

It is possible for a theme to supply a custom css file for inclusion in the visual editor and to define the styles that would be available in the menus. That would make the iframe closer to the actual front-end look. Of course structural css cannot be used there and is not supported by the browsers.

There are many (more advanced) features in TinyMCE that are not used by default like template support, inline css editing, pre-defined lists of media files, etc. Most of them need either theme integration or some front end design decisions to be able to work.

Conclusion:

I’d like to thank Andrew again for taking the time to answer those questions. Nothing like hearing the answers from the horses mouth! I learned quite a bit about the visual editor just from this interview alone and perhaps I will change some of my views on the editor now that I know why some things happen the way they do. Let me know if you enjoyed the interview and if this answered any questions you had regarding the visual editor within WordPress.