[whatwg] Specification of window.find()

[Tim Down]

On 21 July 2011 20:59, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> 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.

There's also the perennial problem of dealing with non-visible text
(c.f. Selection.toString(), innerText), which some browsers handle (a
quick tests suggests WebKit searches non-visible text and Firefox
doesn't). Also, don't forget that you're in the habit of writing this
sort of code. Knocking that kind of code out quickly is beyond what a
large percentage of web developers are capable of.


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

I absolutely agree that restricting mutation to editable content is
important. My issues with using designMode are a combination of side
effects and implementation quirks in current and older browsers, which
I agree doesn't justify a change to the spec, and a gut feeling that
it's the wrong approach. There is no reason why your algorithms can't
work on non-editable nodes, so why require the user to change such a
fundamental property of the DOM (even temporarily)? I'd prefer an
alternative mechanism for specifying whether a command should apply to
only editable content that is part of the editing API. In my
execCommand implementation, it's specified as a property of an options
object passed to execCommand(). If that's not an option, another
command could be used, similar to the styleWithCSS command, to switch
between modes. applyToNonEditable, or something.

Tim