- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Thu, 21 Jul 2011 15:59:53 -0400
On Wed, Jul 20, 2011 at 6:23 PM, Tim Down <timdown at gmail.com> wrote: > Yes, but it's significantly better than the alternative, which is to > write your own code to search for text that spans nodes. It shouldn't be *too* hard to write that code. First do the search in textContent and get a list of the offsets of all the results. Then get a list of Text nodes, and iterate through them. Record the sum of their lengths as you go, and when you get to the right place, store the result. I'd guess it would be 20 lines or so. Something like this (untested): function findStrings(root, search) { var offsets = []; for (var i = root.textContent.indexOf(search); i != -1; i = root.textContent.indexOf(search, i + 1)) { offsets.push(i); } var results = []; var treeWalker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT); var currentOffset = 0; while (treeWalker.nextNode()) { while (offsets.length && currentOffset <= offsets[offsets.length - 1] && offsets[offsets.length - 1] < currentOffset + treeWalker.currentNode.length) { results.push([treeWalker.currentNode, offsets[offsets.length - 1] - currentOffset]); offsets.pop(); } currentOffset += treeWalker.currentNode.length; } return results; } Probably buggy, but something like that should work. (And hey, it's 19 lines, good guesswork.) Granted, if you wanted to do any kind of normalization it would be more complicated to author, but also more complicated to spec. So I don't see really a use-case here that's strong enough to justify this, if we can get rid of it. > Agreed. My number two feature (well, it would make the top 5, at > least) would be removing the restriction on execCommand() only working > on editable content. This very use case shows that its usefulness > extends beyond editable content. The temporarily-switch-designMode-on > workaround is ugly, and destroys the selection in some browsers. As I said elsewhere, I disagree. Wanting to only modify editable content is an important use-case. It's easy to emulate the behavior you want if that restriction is in place (temporarily turn on designMode), but nearly impossible to emulate the opposite behavior if it's not built in to start with. If execCommand() worked on any content at all, then text editors would be permanently forced to use iframes with designMode instead of being able to use contenteditable, just to avoid the user randomly bolding or deleting interface text. Also, it would mean that (for instance) execCommand("delete") works differently from the backspace key. If turning designMode on destroys the selection in some browsers, that's a bug that can easily be fixed, and doesn't justify a change to the spec. Changing specs to work around easily-fixed browser bugs makes much less sense than just fixing the bugs. The only disadvantage I see to requiring this is that it's error-prone: the obvious way to do it is to turn designMode on and then turn it off, which will have an unexpected side effect if it had already been on. But that's a minor issue, and I don't see a good way to avoid it. Why exactly do you not want to turn designMode on and off, other than easily-fixed browser bugs? What do you think is "ugly" about it?
Received on Thursday, 21 July 2011 12:59:53 UTC