Just last week, I was working on the new version of Xinha. If you don’t know, Xinha’s a web-based document editor. Embed it in your blog, your web software, so that you and your users can create web documents. Xinha is WYSIWYG, so there’s no need to know HTML. The Open Planning Project, my employer, uses Xinha to power OpenPlans, which is why I get to work on it. Xinha is Open Source Software, so we use it, and contribute fixes and enhancements back to the original project.
I was working with Nicholas Bergson-Shilcock, my colleague, on his new plugin for Xinha. With this plugin, you can finally make great footnotes in your documents. We were testing his code on Internet Explorer, and we noticed IE acting strange. Now I don’t mean normal IE strange, IE is the bane of all web developers, so I’m used to strange. (If you use IE, then please don’t. I don’t care whether you use Mozilla Firefox, Google Chrome, Opera, Apple Safari, or if you connect to web servers directly with telnet. Just do all web developers a favor and stop using IE.)
When I say strange, I mean screwy. Certain places in the document just didn’t seem to exist. His code used Xinha in different ways than the rest of the plugins, so we were expecting edge cases. But black holes? Nobody expects black holes!
1 2 3 4
You can’t touch the end of the first line. Let me say that again, you can’t touch the end of the first line. What does that mean? All of you DOM jockeys know how to get a reference to the node, and could manipulate the elements, but that’s no help for the user.
Your user pushes that cursor beyond the event horizon. They click on your footnote button to bring up a dialog. You insert the text they type, and BAM! The cursor’s not where the user left it; you’ve just crapped markup at some other place in the document. When you do things like that, users start to fear pressing buttons, and we can’t have that.
Why haven’t we seen it before? Xinha was using pop-ups for dialogs, and they don’t change the original selection. Now that we’ve moved to a lightbox-style dialog system, we’re moving the cursor about on the page, and we don’t have a way to move it back.
So, what can we do? Unfortunately, I tried to see if there was a way to trick IE into moving the selection to where we want. I tried moving the selection left, or right, and then back again. I tried inserting content, then deleting it, but there was no direct way to solve the problem. We ended up with three different workarounds, all of which have drawbacks, but are better than no solution at all:
- Change the justification
- If you change the justification on the current selection, IE modifies the document so that the selection continues to work. Set it to no justification, and you even get valid HTML! Unfortunately, it re-parents the following element, moving it one node closer to the root of the document.
- Insert an empty span
- This works by making sure that you are attempting to select the span element, rather than a text node, and element selection actually works in IE. It craps spans all over the document, though. and even though we try to clean these up, you never know.
- Insert a visual cue
- The final method works by inserting a visual cue for the user in the form of a little block (□), then selecting it. If we’re about to modify the document, or the user begins to type, the block will be removed automatically. In any other case, the user will see the block and naturally want to delete it from the text.
All three are written in to the code, but we decided to default to the visual cue, because it’s the safest in terms of damaging the markup. Otherwise, we’ve done everything we could to avoid triggering the error, so we hope it won’t affect too many users; it’s always a trade off.
I wrote this to get some visibility for this problem. This is probably just some sort of off by one error, and IE8 is still in beta, so maybe it can still get fixed. If not, at least you’ll have a way to work around the problem when you run into it.