I've developed an XML text editor that indents XML using a 'floating' left-margin rather than the more common tab or space characters. Indentation is updated continuously and only relies on the XML context of new-line characters. The intended use for the tool is for XSLT editing and for XML vocabularies which tend to be hand-crafted and where whitespace management is critical (such as XMLSpec).

To make this tool work with XML from other sources, any XML file opened, or pasted from the clipboard, is first scanned for indent characters; these are then stripped before rendering the formatted XML.

After overcoming some significant early problems such as formatting of attributes, commented-out XML and a tendency for the XML to leap alarmingly across the screen, there do appear to be many benefits to this, in terms of readability, UI efficiency/ergonomics, processing, version-control etc.

However, if there are such benefits, I worry why all XML editors don't already do this.

So, in terms of usability of the tool and readability/usefulness of the XML produced, when characters used for indenting XML are removed; what are the potential issues and how should I mitigate them?

I've tested other XML editors with XML produced by this tool. They all succeed in reformatting the XML reasonably (except for attributes - which have more variable indentation conventions) by inserting padding characters.

The editor provides also an alternate view where the left-margin is collapsed, but no characters are affected. In the examples linked below, the highlighted element in each view shows the only place (highlighted area with no characters) where space characters were added by the author for indentation. This was required to indent a single line within a multi-line attribute value, so the XML-context was not sufficient.

XML Editor Screenshots: Comparing Indented and Non-Indented Views

[Edit] Some more points:

Text moving around the screen whilst the user typed presents some challenges (as already mentioned). However, using auto-completion of tags/attributes and delayed formatting helps. Also, there's already some movements of tags in more conventional editors, so this behavior won't be completely unexpected.

Attention has been paid to handling keyboard-shortcuts that have special affects on whitespace (like ctrl-backspace or tab) so that there are not too many surprises.

The editor works best with word-wrap on, but many users follow text editor conventions for maintaining a maximum line-length by inserting line-feeds. An optional feature removes such line-feeds but its recognised that this could cause as many problems as it solves.

The rationale behind auto-indenting XML tags found within comments is that blocks of XML may be commented/uncommented at will. CData blocks, though they may contain XML tags are treated as normal text; this is because the CData tags can't be removed without making the XML invalid. CData contents is colored differently from parsed text to avoid any confusion about indentation.

Indentation of XML within comments: Though automated this is independent of the 'real' XML indentation to avoid anything within comments affecting the formatting of the rest of the XML.

Pasting to other XML tools - Because there's no 'foreign' indentation for the editor to handle, this probably works better than when copying between 2 conventional tools.

Pasting to text-only tools (such as a wiki) - This presents a problem unless that tool recognises RTF.

An option for saving-with-whitespace could be provided, however, a redistributable/online 'reformatting tool' might provide more flexibility?

Just for info: This editor was initially released as part of a much larger XML processing system, however, to get more general feedback I've also now put out a simpler, lighter free version, XMLQuire. Given the number of day 1 downloads for this, I hope to be in a position to assess disadvantages direct from live user feedback fairly soon...

[update] Downloads of products using this system run at about 200 per week, so total downloads must exceed 10,000 by now. No users have yet complained of the whitespace handling, but just a handful have come back with complimentary feedback. It seems that for many this feature goes largely unnoticed.

  • This question is hardcore. Good luck!
    – Rahul
    Commented May 29, 2011 at 20:19
  • @Rahul - Cheers. I worded the question to overcome my natural bias in favor of this design -so fewer answers (identifying disadvantages) is theoretically better news.
    – pgfearo
    Commented May 30, 2011 at 13:07

2 Answers 2


You're bending normal editor conventions, so users will have to get used to not typing spaces/tabs and also to text jumping right when they complete a new opening tag and left on completing a closing tag. None of this seems in itself to be that big an obstacle. In effect you are running 'prettify' with each keypress, and so giving more responsive feedback. You can view it as being analogous to color syntax highlighting as you type. People had to adjust to that, but it's a net win.

The usability questions that come to my mind are in the gray area between UX questions and questions about the app's functionality.

  • What about <!CDATA[]]>? Will the automatic indenting be turned off for that? Or optionally turned off? It could get a bit confusing mixing automating indenting and manual. That's not a problem with an app where all formatting is manual.
  • The app works without indentation internally. Can I export/save with indentation if I want to? I might be wanting to use it with an editor that cannot automatically add indentation, or to cut and paste to a wiki.


Thanks for the update.

It is now sounding like the kind of thing where one can only make more useful and detailed comment by actually trying it out. A while back I wrote an 'instant assembler' that did all the syntax and type checking, macro expansion, code generation as you typed. Getting the responsiveness required was not easy, but in the end the main usability issues were not there. The usability issues were in the select text behavior not implementing all details of normal editor selection (dragging to extend causing window scrolling) - and that happened because I don't do that myself, and because I wasn't able to just extend a standard editor control.

So test, with one to three users and get their feedback. Problems are likely to be not in the area you are worrying about.

I would say you would be very safe to run with your idea. It looks as if you have the option that people who really want to use explicit spaces can do so, and your target market looks computer literate enough that they will find that option - if they happen to want to stick to the old way of doing it.

It sounds a nice idea. Good luck with it.

  • CDATA is treated as ordinary text, so there's no auto-indentation for it. I treat comments as a special case, because its quite common in XSLT to comment out XML and then un-comment it later.
    – pgfearo
    Commented May 29, 2011 at 17:42
  • I've added some more points to my question that hopefully address your recommendations/clarification-requests
    – pgfearo
    Commented May 29, 2011 at 20:08
  • Thanks, I'll need to seek beta-testers for early feedback - will also put out screen-cast tutorials. Notes: Responsiveness achieved by only updating view in real-time, remaining work performed on 2nd thread. The parser builds model and does formatting in a single 'chunked' pass. Explicit space indent features are provided, but only really useful for text-formatting. Best side-effects: 1. Formatting on drag/drop ops - totally seamless. 2. XSLT coding - editing efficiency (in terms of key-strokes) is comparable to 'curly-brace' programming languages.
    – pgfearo
    Commented May 30, 2011 at 12:19
  • I've accepted this answer because it raises a number of potential issues along with suggestions on how the impact on users of this significant change may be minimized
    – pgfearo
    Commented May 31, 2011 at 15:08

If you're actually removing indentation characters from the source, as opposed to just rendering as if they were not there, then you may be breaking interoperability with other editors. Someone who created a manually-formatted XML file in, say, emacs (or Notepad or whatever), and then used your editor with it, should not lose his ability to return to his original editor.

  • Interoperability is a concern. Emacs and similar tools have XML modules that should reformat the XML ok - perhaps even better than the original. Though this undermines a key benefit of this tool, I will add a legacy 'save with indent chars' feature for Notepad users, plus a command-line reformatter that could also launch Notepad.
    – pgfearo
    Commented May 30, 2011 at 5:41
  • Another thought - Notepad breaks formatting interoperability with emacs (on unix/linux) by not preserving \n linefeeds
    – pgfearo
    Commented May 30, 2011 at 10:41
  • Oh, I didn't know that about Notepad (I use it rarely). But think of this as a class of potential problem; there are lots of editors out there, and if you change the source document (as opposed to just how you render it) you may well be breaking one of them. Arbortext's Epic does this, for example, and it completely messes up the ability to diff two versions of a file, which is important when reviewing changes in source control. Commented May 31, 2011 at 2:48
  • Most, if not all, XML editors have this problem - their pretty-print features change indent chars in different ways. Isn't dispensing with indent chars altogether the only reliable way to remedy this for the future?
    – pgfearo
    Commented May 31, 2011 at 5:19
  • @pgfearo, I would think that "leave the file the way you found it except for the actual user-initiated edits" would be the only reliable way to remedy this. Commented Jun 3, 2011 at 4:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.