Comments on: Replacing text in the DOM… it’s not that simple!

By: Christopher Blum

Christopher Blum — Tue, 11 Jan 2011 11:00:00 +0000

The line:

textNode.parentNode.insertBefore(textNode, temp.firstChild);

should rather be:

textNode.parentNode.insertBefore(temp.firstChild, textNode);

Because according to https://developer.mozilla.org/En/DOM/Node.insertBefore the first parameter has to be the node that should be inserted.

Thanks!

By: "Cowboy" Ben Alman

"Cowboy" Ben Alman — Thu, 08 Jul 2010 14:36:10 +0000

James, great article! I actually created a jQuery plugin last year called jQuery replaceText that does pretty much what you’ve covered here, along with an explanation of the general process and caveats, so please check it out when you get a chance!

http://benalman.com/projects/jquery-replacetext-plugin/

By: James

James — Wed, 07 Jul 2010 19:33:33 +0000

@Jacob, Neighbouring text nodes isn’t common, but it is something I feel would need to be included in a catch-all solution. The fact that you’re reverting the elements to their original state at all is definitely a good thing! Most of what I covered were edge cases, and I think that you should only consider each one on its own — IMO it may not be necessary to accommodate all eventualities.

@Rich, I hadn’t considered that this would be a common problem, but you reminded me that there are quite a few WYSIWYG editors that would have to to build in some kind of mechanism for these edge-cases. CKEditor’s solution is interesting, although I’d probably use just one anchor and nest the em within it instead of using two separate anchors.

@Gary, I was working on something similar when I encountered all of these problems and decided to write the post — never ended up publishing the plugin though. Liking your usage of the awesome document fragment btw!

@Can, yup, well, I think each problem has to be considered on its own — it simply may not be worth covering all bases…

By: Can Berkol

Can Berkol — Wed, 07 Jul 2010 14:29:03 +0000

Great article. Harsh problems.. I still like to add that pre-planning may reduce some of these issues – but of course there is also “the client wish” factor; whether the client is your boss, your customer or yourself….

By: Gary Haran

Gary Haran — Wed, 07 Jul 2010 14:03:32 +0000

I’m glad someone discussed this. I tried solving the same problem in a cross browser way as a jQuery plugin.

You can look at my code here: http://github.com/garyharan/jquery-replace-utilities/

By: Rich

Rich — Wed, 07 Jul 2010 09:46:20 +0000

Thanks for the article, I found it very interesting as I've tried to solve your last case, alas unsuccessfully. Agreed it's not possible to solve your last case 'unobtrusively', without a heck-load of DOM scripting. A good working example of the type of logic involved is spell-checking in WYSIWYG editors. TinyMCE spellchecker does not bother (probably for the same reasons you mentioned), but CKEditor manages to solve this, it's fascinating to see the final markup: initial html is: number is RF83297 final html is: number is <a href="/order/RF83297">RF</a><a href="/order/RF83297">83297</a>

By: Graham

Graham — Wed, 07 Jul 2010 09:08:13 +0000

A nice warning to show that libraries can’t cover all the bases.

By: Jacob Waller

Jacob Waller — Wed, 07 Jul 2010 08:33:54 +0000

Interesting read, James!
I created a search-in-page search bar bookmarklet for iOS (yeah, I know…) devices (and potentially Android) the other day, and ran in to many of the problems you describe. I did come up with a similar solution, though not as well-reasoned as yours. If you’d be interested, it’s available here: http://github.com/krawaller/prettySearch.js as an early release. Please feel free to bash it – I could definitely use your help 🙂

I saw that manually creating text nodes may lead to neighbouring text nodes, but when does this happen in the wild? Also: currently, I normalize the elements only when I revert the search – how bad is this?