Interview With Andrew Ozz (Mr. Visual Editor)

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.


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.


  1. Thanks Andrew and Jeff, that was a really enlightening interview.

    I’m not sure of the ins and outs of TinyMCE, but it seems to me that a lot of it’s downfalls are being blamed on the browsers (such as Firefox and the image insertion.) Is this a chicken and egg situation? It is hard to judge where the fault lies on whether TinyMCE should take browser interpretation into account or whether the browser is correctly implementing code.

    I think the same also applies to the functions being the same as they work in Writer and Word. Just because these are original functions, does it mean that they are the best way to do it? I think that it is strange to base a visual HTML editor on desktop publishing software, as the nature of the content is entirely different.

    Thanks for including my questions, Jeff.


  2. The TinyMCE/WordPress integration was my responsibility for the two years or so before it was Andrew’s. When he took it over it made me a very happy man.

    The hardest part of the task is not the coding or even dealing with browser differences. What is difficult is making decisions about how the editor should behave in each of the innumerable ways it will be used. People don’t agree on what the editor should do in all situations. Someone will complain, no matter what.

    For example, when someone types some HTML in the RTE and they see it displayed instead of interpreted, they send in a bug report because they expected the editor to know what they wanted. It’s not obvious to everyone, but this would be a horrible way for the visual editor to behave. I created the tabbed editor to make it easier to edit the HTML directly, but this complaint just kept coming in. I mentally created a category for this kind of bug—expectation fault—and it made sorting through bug reports much easier.

    The expectation fault appears nowhere more frequently than in the editor. You mentioned blockquote and Andrew explained the current behavior. If you paste text in blockquote mode, your cursor will be at the end of the last paragraph. The editor has received no indication that you’re done with blockquote mode, so when you press Enter it starts a new paragraph in that mode. It always seemed correct to me. You would not have minded the current behavior if you were typing or pasting multiple paragraphs in blockquote mode. You never would have noticed it because your inputs would not have produced unexpected results.

    I used to complain that I couldn’t write software that could read minds, thus the editor was doomed to fail in everyone’s eyes at least some of the time. To the programmer, it’s the intended result and not a malfunction. Thus it’s definitely not a bug, and at worst a suboptimal design decision. To the user, it’s a bug. Usually this comes down to someone not realizing that the program acted in the way the programmer saw best, given its state and the user’s actions. Editor state is always displayed via the button shading, the cursor position, and the status line. Usually the user does not understand the editor state, which is by nature complex.

    Andrew is doing a very good job maintaining, upgrading, and improving the TinyMCE integration in WordPress. There may be (probably are) better editors out there, but editor integration is extremely sensitive and time-consuming. It’s not likely to be removed or replaced because the majority of users depend on it. Although it frustrates us sometimes, we should remember that we always have the option of editing the HTML directly… and most of us pick the RTE anyway.


  3. I always enjoy reading well explained reasons why things are the way they are. As a developer I do keep non-developers in mind when I plan and assemble, of course I do or my work would be terrible, but phrasing my own decisions to those non-developers is a feat greater than programming, for me.

    Andrew’s comments were interesting, and I applaud his reminder around browser capabilities. Also, the power user/quirks situation is one I still battle with, I’ve found myself resorting to inserting a Duck in order to ‘get away’ with a new feature, or plant an Egg to reward curiosity (or mishap).

    Andy S – I found your comments interesting too, particularly your description of the Editors state, not to mention your category for the ‘expectation fault’.

    Edit: Yes! I do want to use the same kick ass comment editor on my site!


Comments are closed.