The Invisible Formatting Tag Problem

Continuing with my response to Alastair’s Responding to Adrian, let’s take a look into the problem with invisible formatting tags in WYSIWYG editors.

The example I gave was to delete the final character of some hyperlinked text. The delete operation removes the internal formatting tag, and hence removes the hyperlink entirely, as well as the final character.

In this behaviour Outlook is no different to many other HTML editors, and is a completely appropriate example. The problem of the invisible formatting goes directly to the heart of the limitations of WYSIWYG editors. There is no visual representation of the tag, so there are bound to be some surprises when the user starts editing in the vicinity of the tag.

It seems like a logical assumption to assume that because is marked up with various tags and that we’re so used to thinking in a DOM model, that invisible formatting tags are an inherent limitation of WYSIWYG editors. The truth however is quite different. It’s actually possible to write a WYSIWYG editors which doesn’t use invisible formatting tags that the user can inadvertently delete.

The Swing text APIs are an excellent example of this. The general document model that Swing uses is actually generic across many different formats1 and has no invisible formatting tags anywhere in the document. The document model is based around a character array containing all the text in the document. On top of that, an element tree is layered. The elements have a start and end offset within the content and their start and end offsets automatically adjust to accomodate changes to the document content. This means that the user can delete any character within a hyperlink and the element representing the hyperlink simply adjust its offsets so that it cover one less character. When the user deletes the last character of the hyperlink the hyperlink element is removed.

At no stage in this process are there extra characters inserted into the content array to track the positions of elements, it is purely done with offsets in the text. There are a number of user actions which require changes to the element tree beyond just adjusting offsets and these need to be handled specifically. Fortunately, the vast majority of these cases are handled with a few simple rules, leading to simple implementation and an intuitive and predictable editing experience for the end user.

The assumption that because HTML requires a tag, HTML editors have to include a tag in their model is simply false. No editor I know of does this, including Outlook. Office tends to use the end of a paragraph as the key point for tracking formatting2 so there can be unexpected effects when the user backspaces through that point. Even with a bad model, there is no reason that Microsoft couldn’t change that behavior to something else – they have simply decided that that is the way it should work or that changing it is not yet a high priority.

In fact, the Outlook example is a perfect showcase of this – hyperlinks work differently to bold, italic and underline. This actually shows clearly that the problem isn’t because of an invisible formatting tag, otherwise the same problem would occur with the tag, the tag etc. The hyperlink behavior is actually a specific choice made by the Outlook team3. I mentioned in my first response one possible reason the Outlook team might have decided to do this:

Regarding the hyperlink complaint, that’s most likely because Outlook automatically applies hyperlinks when you type an URL – this annoys a lot of people so they made it easy to remove the hyperlink again, by hitting backspace at the end of the hyperlink.

No one who has experience writing editors will claim that it is easy to make a WYSIWYG editor intuitive for users no matter what format your editing. The fact is that editing content is hard. There are an infinite number of states your program could be in4 and a vast number of user actions to handle. Identifying all the possible things that a user wants to do and how they are going to try to do it is really difficult, but that doesn’t mean that WYSIWYG editors are flawed, it simply means it will take a lot of work and dedication to getting it right. Even when there are parts of the editor that don’t work perfectly, for the vast majority of users a WYSIWYG editor is better5 than having to learn and use a markup language.

Beyond Outlook, there are plenty of other examples of HTML being represented using a different syntax – the DOM model, binary XML and a range of other XML serialization formats which HTML could be represented as. There is simply no reason an editor needs to deal with the limitations and difficulties of the HTML serialization format, it can come up with any model it deems fit to provide the best experience for end users.

Hidden formatting tags are simply a bad idea from the early days of WYSIWYG editors that has hung around because Microsoft don’t want to break backwards compatibility in Office. They are not required, nor are they acceptable in any modern WYSIWYG editor.

 

1 – HTML, RTF and plain text support are provided by default but developers can plug in their own implementations for other formats.↩

2 – whether or not this is actually an invisible tag or simply a behavior that Microsoft has chosen to implement I couldn't be sure↩

3 – A bad one I'll agree, but certainly not a limitation of the editor↩

4 – every possible document a user could create is a new state↩

5 – better = easier to use, easier to learn, more intuitive and all round "nicer" to work with↩