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
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.