Specification of window.find()

[Benjamin Poulain]

Hi,

I would like to suggest a change for the main HTML 5 specification:
http://www.whatwg.org/specs/web-apps/current-work/

The problem I have is with the Window object specification
(http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ).
It does not mention the method find() which can be found on most engines
(e.g.: https://developer.mozilla.org/en/DOM/window.find ).

I think it would be good to have it in the standard, and to define a
standard behavior for it. WebKit and Gecko have small differences in the
way this function is implemented.


I recently stumbled upon the way this function handle content
invisible because of clipping: https://bugs.webkit.org/show_bug.cgi?id=15078

I think the best way to handle this case would be not to select the
hidden strings. This would be the less disruptive for Web developers,
and would make sense for the user interface.

In any case, I would prefer this function to be part of a standard
instead of having a behavior specific to WebKit.

Best regards,
Benjamin

[Benjamin Poulain]

Hi,

I never received an answer for this issue.

Is writing on this list the correct process make comments about the
specification? What is the best way to see this moving forward?

Benjamin

On 10/27/2010 11:07 PM, ext benjamin.poulain@... wrote:

> Hi,
>
> I would like to suggest a change for the main HTML 5 specification:
> http://www.whatwg.org/specs/web-apps/current-work/
>
> The problem I have is with the Window object specification
> (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ).
> It does not mention the method find() which can be found on most engines
> (e.g.: https://developer.mozilla.org/en/DOM/window.find ).
>
> I think it would be good to have it in the standard, and to define a
> standard behavior for it. WebKit and Gecko have small differences in the
> way this function is implemented.
>
>
> I recently stumbled upon the way this function handle content
> invisible because of clipping: https://bugs.webkit.org/show_bug.cgi?id=15078
>
> I think the best way to handle this case would be not to select the
> hidden strings. This would be the less disruptive for Web developers,
> and would make sense for the user interface.
>
> In any case, I would prefer this function to be part of a standard
> instead of having a behavior specific to WebKit.
>
> Best regards,
> Benjamin

[Ian Hickson]

On Mon, 8 Nov 2010, Benjamin Poulain wrote:
>
> Is writing on this list the correct process make comments about the
> specification?

Yes.

> What is the best way to see this moving forward?

Patience. :-)

There are currently 1163 pending e-mails, because I am currently
prioritising dealing with W3C HTML WG pre-LC bug reports, by request of
the W3C chairs. However, once that is done I'll be getting back to
responding to WHATWG feedback.

For the current status see:
   http://www.whatwg.org/issues/data.html

For the currently pending e-mails see:
   http://www.whatwg.org/issues/

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Benjamin Poulain]

On 11/08/2010 07:57 PM, ext Ian Hickson wrote:

> On Mon, 8 Nov 2010, Benjamin Poulain wrote:
>>
>> Is writing on this list the correct process make comments about the
>> specification?
>
> Yes.
>
>> What is the best way to see this moving forward?
>
> Patience. :-)

Thanks for the responses. I will wait for your comments then :)

cheers,
Benjamin

[Ian Hickson]

On Wed, 27 Oct 2010, benjamin.poulain@... wrote:
>
> I would like to suggest a change for the main HTML 5 specification:
> http://www.whatwg.org/specs/web-apps/current-work/
>
> The problem I have is with the Window object specification
> (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ).
> It does not mention the method find() which can be found on most engines
> (e.g.: https://developer.mozilla.org/en/DOM/window.find ).

It looks like IE doesn't implement this, so it's probably not strictly
required for compat with the Web.

What are the use cases for this feature?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Benjamin Poulain]

On 01/06/2011 10:53 PM, ext Ian Hickson wrote:

> On Wed, 27 Oct 2010, benjamin.poulain@... wrote:
>> I would like to suggest a change for the main HTML 5 specification:
>> http://www.whatwg.org/specs/web-apps/current-work/
>>
>> The problem I have is with the Window object specification
>> (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ).
>> It does not mention the method find() which can be found on most engines
>> (e.g.: https://developer.mozilla.org/en/DOM/window.find ).
>
> It looks like IE doesn't implement this, so it's probably not strictly
> required for compat with the Web.
>
> What are the use cases for this feature?

I do not know the original use case but I can think of a few:
-on mobile devices which have a find dialog but no user interface to
access it, make the find dialog appear
-on mobile devices which do not have a find dialog, add one for you
document if pertinent
-add search feature in a frame. Searching between frames with the
browser builtin dialog is usually not doing was user expect

On IE, users usually emulate the feature with TextRange
http://msdn.microsoft.com/en-us/library/ms535872%28v=vs.85%29.aspx

cheers,
Benjamin

[Ian Hickson]

On Fri, 7 Jan 2011, Benjamin Poulain wrote:

> On 01/06/2011 10:53 PM, ext Ian Hickson wrote:
> > On Wed, 27 Oct 2010, benjamin.poulain@... wrote:
> > > I would like to suggest a change for the main HTML 5 specification:
> > > http://www.whatwg.org/specs/web-apps/current-work/
> > >
> > > The problem I have is with the Window object specification
> > > (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ).
> > > It does not mention the method find() which can be found on most engines
> > > (e.g.: https://developer.mozilla.org/en/DOM/window.find ).
> >
> > It looks like IE doesn't implement this, so it's probably not strictly
> > required for compat with the Web.
> >
> > What are the use cases for this feature?
>
> I do not know the original use case but I can think of a few:
> -on mobile devices which have a find dialog but no user interface to access
> it, make the find dialog appear

Are there pages that do this today? Or indeed any UAs that have a find
dialog but no UI to access it?


> -on mobile devices which do not have a find dialog, add one for you
> document if pertinent

You can add a custom find feature without window.find(), you just have to
implement it manually.


> -add search feature in a frame. Searching between frames with the
> browser builtin dialog is usually not doing was user expect

Are there pages that do this?


> On IE, users usually emulate the feature with TextRange
> http://msdn.microsoft.com/en-us/library/ms535872%28v=vs.85%29.aspx

Do you have any examples of pages doing this? It would be useful to study
how pages use this API; maybe we can do something better.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Benjamin Poulain]

On 05/03/2011 01:42 AM, ext Ian Hickson wrote:
>> I do not know the original use case but I can think of a few:
>> -on mobile devices which have a find dialog but no user interface to access
>> it, make the find dialog appear
>
> Are there pages that do this today? Or indeed any UAs that have a find
> dialog but no UI to access it?
>[...]

I don't really have an interest in defending the feature.

I was just hoping to get a specification for the API to get a bit more
consistency between engines.

Since you do not seem interested in the feature, I guess we can keep it
as a WebKit/Gecko extension.

Benjamin

[Hallvord R M Steen]

2011/5/3 Benjamin Poulain <benjamin.poulain@...>:

> I don't really have an interest in defending the feature.
>
> I was just hoping to get a specification for the API to get a bit more
> consistency between engines.
>
> Since you do not seem interested in the feature, I guess we can keep it as a
> WebKit/Gecko extension.

Opera is regularly nagged by rich text editor authors who would like
us to support window.find(). Since it seems to be a requested feature,
it would be nice to have a proper spec ;-)

I guess that one of the main use cases indeed is to be able to
highlight search hits inside a single frame (using the browser's
built-in search might highlight hits both in a rich text editor's UI
and the document you're editing, which would be confusing)..

Yes, it is a counter-argument that authors could write their own
implementation. However, it's non-trivial to write a good text find
implementation in JS - it needs to handle text wrapping, text that is
split across different text nodes or tags, HTML entities, soft
hyphens, BiDi and probably a lot of issues I'm not aware of. It's a
lot simpler to let the JS author hook into the UA's presumably
superior and better tested algorithm.

--
Hallvord R. M. Steen

[Ian Hickson]

On Tue, 3 May 2011, Benjamin Poulain wrote:

> On 05/03/2011 01:42 AM, ext Ian Hickson wrote:
> > > I do not know the original use case but I can think of a few: -on
> > > mobile devices which have a find dialog but no user interface to
> > > access it, make the find dialog appear
> >
> > Are there pages that do this today? Or indeed any UAs that have a find
> > dialog but no UI to access it? [...]
>
> I don't really have an interest in defending the feature.
>
> I was just hoping to get a specification for the API to get a bit more
> consistency between engines.
>
> Since you do not seem interested in the feature, I guess we can keep it
> as a WebKit/Gecko extension.

What would be even better is if WebKit and Gecko could just drop support
for the feature altogether, if there are no compelling use cases for it,
no compat need, and nobody is interested in defending the feature.

But if there is a need, that's a different matter:

On Thu, 5 May 2011, Hallvord R M Steen wrote:

>
> Opera is regularly nagged by rich text editor authors who would like us
> to support window.find(). Since it seems to be a requested feature, it
> would be nice to have a proper spec ;-)
>
> I guess that one of the main use cases indeed is to be able to highlight
> search hits inside a single frame (using the browser's built-in search
> might highlight hits both in a rich text editor's UI and the document
> you're editing, which would be confusing)..
>
> Yes, it is a counter-argument that authors could write their own
> implementation. However, it's non-trivial to write a good text find
> implementation in JS - it needs to handle text wrapping, text that is
> split across different text nodes or tags, HTML entities, soft hyphens,
> BiDi and probably a lot of issues I'm not aware of. It's a lot simpler
> to let the JS author hook into the UA's presumably superior and better
> tested algorithm.

In investigating this further, I've found that window.find() is not
especially interoperably implemented. I've filed bugs on the two browsers
that implement it to investigate what we can do about it:

   https://bugzilla.mozilla.org/show_bug.cgi?id=672395
   https://bugs.webkit.org/show_bug.cgi?id=64761

I've also added a placeholder to the spec for this feature.

Depending on how these bugs go, I'll either fill in the spec to one extent
or another, or remove the section altogether.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[timdown (Bugzilla)]

On 6 January 2011 21:53, Ian Hickson <ian@...> wrote:

> On Wed, 27 Oct 2010, benjamin.poulain@... wrote:
>>
>> I would like to suggest a change for the main HTML 5 specification:
>> http://www.whatwg.org/specs/web-apps/current-work/
>>
>> The problem I have is with the Window object specification
>> (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ).
>> It does not mention the method find() which can be found on most engines
>> (e.g.: https://developer.mozilla.org/en/DOM/window.find ).
>
> It looks like IE doesn't implement this, so it's probably not strictly
> required for compat with the Web.
>
> What are the use cases for this feature?

It's useful for custom search features. I've recommended it a few
times on Stack Overflow for people wanting to highlight or somehow
style all occurrences of a piece of text that may span nodes (it's
this part that is the compelling feature). You can achieve the same
using TextRange in IE. For example:

http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags

I think this is a valid use case. On a related note, I would like to
see equivalents of some of the text-based methods in IE's TextRange
make their way into Range, but that's a separate issue.

Tim

[Aryeh Gregor-2]

On Wed, Jul 20, 2011 at 6:14 AM, Tim Down <timdown@...> wrote:
> It's useful for custom search features. I've recommended it a few
> times on Stack Overflow for people wanting to highlight or somehow
> style all occurrences of a piece of text that may span nodes (it's
> this part that is the compelling feature). You can achieve the same
> using TextRange in IE. For example:
>
> http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags
>
> I think this is a valid use case.

However, the implementation here doesn't do what you'd want: it
selects the text, destroying any existing selection.  You can work
around it by preserving and then restoring the selection somehow, but
it's not ideal at all.  It would make much more sense to have a
function that returned a Range or list of Ranges.

Of course, for the use-case you posted, execCommand() would also have
to work on Ranges instead of just the selection, but that should
probably be feature #1 to add to it anyway . . .

[timdown (Bugzilla)]

On 20 July 2011 17:58, Aryeh Gregor <Simetrical+w3c@...> wrote:

> On Wed, Jul 20, 2011 at 6:14 AM, Tim Down <timdown@...> wrote:
>> It's useful for custom search features. I've recommended it a few
>> times on Stack Overflow for people wanting to highlight or somehow
>> style all occurrences of a piece of text that may span nodes (it's
>> this part that is the compelling feature). You can achieve the same
>> using TextRange in IE. For example:
>>
>> http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags
>>
>> I think this is a valid use case.
>
> However, the implementation here doesn't do what you'd want: it
> selects the text, destroying any existing selection.  You can work
> around it by preserving and then restoring the selection somehow, but
> it's not ideal at all.

Yes, but it's significantly better than the alternative, which is to
write your own code to search for text that spans nodes.

> It would make much more sense to have a
> function that returned a Range or list of Ranges.

Absolutely.

> Of course, for the use-case you posted, execCommand() would also have
> to work on Ranges instead of just the selection, but that should
> probably be feature #1 to add to it anyway . . .

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.

Tim

[Aryeh Gregor-2]

On Wed, Jul 20, 2011 at 6:23 PM, Tim Down <timdown@...> 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?

[timdown (Bugzilla)]

On 21 July 2011 20:59, Aryeh Gregor <Simetrical+w3c@...> wrote:

> On Wed, Jul 20, 2011 at 6:23 PM, Tim Down <timdown@...> 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

[Aryeh Gregor-2]

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

[Ian Hickson]

On Wed, 20 Jul 2011, Tim Down wrote:

> On 6 January 2011 21:53, Ian Hickson <ian@...> wrote:
> > On Wed, 27 Oct 2010, benjamin.poulain@... wrote:
> >>
> >> I would like to suggest a change for the main HTML 5 specification:
> >> http://www.whatwg.org/specs/web-apps/current-work/
> >>
> >> The problem I have is with the Window object specification
> >> (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ).
> >> It does not mention the method find() which can be found on most engines
> >> (e.g.: https://developer.mozilla.org/en/DOM/window.find ).
> >
> > It looks like IE doesn't implement this, so it's probably not strictly
> > required for compat with the Web.
> >
> > What are the use cases for this feature?
>
> It's useful for custom search features. I've recommended it a few
> times on Stack Overflow for people wanting to highlight or somehow
> style all occurrences of a piece of text that may span nodes (it's
> this part that is the compelling feature). You can achieve the same
> using TextRange in IE. For example:
>
> http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags
>
> I think this is a valid use case. On a related note, I would like to
> see equivalents of some of the text-based methods in IE's TextRange
> make their way into Range, but that's a separate issue.

So really it's not for use as a UI feature, but as a way to get Range
objects for modifying the DOM. Interesting.


On Wed, 20 Jul 2011, Aryeh Gregor wrote:
>
> However, the implementation here doesn't do what you'd want: it selects
> the text, destroying any existing selection.  You can work around it by
> preserving and then restoring the selection somehow, but it's not ideal
> at all.  It would make much more sense to have a function that returned
> a Range or list of Ranges.

So I guess we have to make a decision for the platform here.

Do we want:

 - To spec window.find() in all its historical glory, and have it
   implemented everywhere?

 - To spec a subset of window.find() that just does the use case described
   above, namely to destructively change the selection to a matching part
   of the DOM so that it can be manipulated by script?

 - To spec a new API that just returns matching ranges and then allows
   those ranges to be manipulated like the selection can be today?

 - To encourage authors to write a library that does this for them, and
   not bother to provide a dedicated API at all?

Which would implementations that don't do the full window.find() today be
willing to do?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Tab Atkins Jr.]

On Wed, Feb 15, 2012 at 11:26 AM, Ian Hickson <ian@...> wrote:

> So I guess we have to make a decision for the platform here.
>
> Do we want:
>
>  - To spec window.find() in all its historical glory, and have it
>   implemented everywhere?
>
>  - To spec a subset of window.find() that just does the use case described
>   above, namely to destructively change the selection to a matching part
>   of the DOM so that it can be manipulated by script?
>
>  - To spec a new API that just returns matching ranges and then allows
>   those ranges to be manipulated like the selection can be today?
>
>  - To encourage authors to write a library that does this for them, and
>   not bother to provide a dedicated API at all?
>
> Which would implementations that don't do the full window.find() today be
> willing to do?

As far as I know, we (google) would prefer to do nothing with
window.find(), so we can use it for the Selectors API.  No opinion on
whether the functionality is useful under another name.

~TJ

[Rick Waldron]

+1 to TJ's mention of find for use in the Selector API:

http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0277.html


Rick



On Wed, Feb 15, 2012 at 2:49 PM, Tab Atkins Jr. <jackalmage@...>wrote:

> On Wed, Feb 15, 2012 at 11:26 AM, Ian Hickson <ian@...> wrote:
> > So I guess we have to make a decision for the platform here.
> >
> > Do we want:
> >
> >  - To spec window.find() in all its historical glory, and have it
> >   implemented everywhere?
> >
> >  - To spec a subset of window.find() that just does the use case
> described
> >   above, namely to destructively change the selection to a matching part
> >   of the DOM so that it can be manipulated by script?
> >
> >  - To spec a new API that just returns matching ranges and then allows
> >   those ranges to be manipulated like the selection can be today?
> >
> >  - To encourage authors to write a library that does this for them, and
> >   not bother to provide a dedicated API at all?
> >
> > Which would implementations that don't do the full window.find() today be
> > willing to do?
>
> As far as I know, we (google) would prefer to do nothing with
> window.find(), so we can use it for the Selectors API.  No opinion on
> whether the functionality is useful under another name.
>
> ~TJ
>

[Ian Hickson]

On Wed, 15 Feb 2012, Tab Atkins Jr. wrote:

> On Wed, Feb 15, 2012 at 11:26 AM, Ian Hickson <ian@...> wrote:
> > So I guess we have to make a decision for the platform here.
> >
> > Do we want:
> >
> >  - To spec window.find() in all its historical glory, and have it
> >   implemented everywhere?
> >
> >  - To spec a subset of window.find() that just does the use case described
> >   above, namely to destructively change the selection to a matching part
> >   of the DOM so that it can be manipulated by script?
> >
> >  - To spec a new API that just returns matching ranges and then allows
> >   those ranges to be manipulated like the selection can be today?
> >
> >  - To encourage authors to write a library that does this for them, and
> >   not bother to provide a dedicated API at all?
> >
> > Which would implementations that don't do the full window.find() today be
> > willing to do?
>
> As far as I know, we (google) would prefer to do nothing with
> window.find(), so we can use it for the Selectors API.  No opinion on
> whether the functionality is useful under another name.

On Wed, 15 Feb 2012, Rick Waldron wrote:
>
> +1 to TJ's mention of find for use in the Selector API:
>
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0277.html

On Thu, 16 Feb 2012, Tim Down wrote:
>
> For what it's worth as author of a small library currently working on
> implementing something like this feature, I have no love for
> window.find(), even if it were consistently implemented in browsers. I
> would prefer the use case I described to be met by a different API,
> which would ideally provide node-independent text-based
> creation/mutation of Ranges, with features similar to those provided by
> Microsoft's TextRange.

Given the lack of interest in the feature, I have removed it from the spec
and recommend to implementors that they drop support for the API.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'