[whatwg] Specification of window.find()

[Aryeh Gregor]

On Wed, Jul 27, 2011 at 6:55 PM, Tim Down <timdown at gmail.com> wrote:
> 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).

True.  Of course, that's a rabbit hole I've mostly managed to avoid
going down so far.

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

Right, but that's why we have libraries like jQuery.  If it's in
demand and it can be done in JavaScript, libraries can do it, and then
we don't want to make browsers do it too unless either it's an
extremely common use-case or they can do it better somehow.  Or they
have to for compat.

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

Having a behavior switch like styleWithCSS is a possible option.  The
problem I have with that kind of switch is that it breaks down if two
scripts on the same page are both relying on the switch being a
particular value: you can't rely on the current state of the switch
unless you run it before every single command execution.  I saw at
least one execCommand()-using library that did exactly that, running
styleWithCSS *and* useCSS before every single command.

Defining an extra argument to execCommand() would be possible, but I'm
leery about it, because it already has one useless boolean argument
that no browser but IE supports.  What we could consider is
overloading it with a form like execCommand(command, options), where
options is an object, so you could do execCommand("forecolor", {value:
"red", styleWithCSS: false, restrictToEditable: true}) or something.
But it's awkward to have to specify the same options all the time, and
the syntax is incompatible and doesn't fall back gracefully.

It's definitely worth considering at some point, though.  I added a
TODO: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=aff4441e