[whatwg] Specification of window.find()

[Aryeh Gregor]

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?