Re: Fwd: Re: [cssom-view] Is there a need for a plural form of document.caretPositionFromPoint()?

On 26 June 2013 16:12, Scott Johnson <sjohnson@mozilla.com> wrote:

> Ah, well, yes, that's true. ;)
>
> ~Scott
>
> Thus Spoke Simon Pieters:
> > On Tue, 25 Jun 2013 20:11:12 +0200, Scott Johnson
> > <sjohnson@mozilla.com> wrote:
> >
> >> Yes, I have a use case.
> >>
> >> mozilla mobile currently uses caretPositionFromPoint for reflow-on-zoom.
> >> We pull the caret position so that a double tap in a large paragraph can
> >> scroll to the exact area where the user double-tapped, after reflow (as
> >> the actual text position may change after reflowing).
> >>
> >> The problem is that if we have a double-tap event occur where there is
> >> some type of overlaying or covering element, we get into a problem where
> >> the caretPositionFromPoint returns a caret position within the overlaid
> >> element. It's possible this is what we want, but it would be nice if we
> >> could access ALL of the elements' caret positions, and then choose
> >> easily from these.
> >
> > It seems to me like this zooming is a feature of the browser rather
> > than something that an author would implement in a Web page/app. Is
> > that right?
>
I intentionally let the discussion set to see if there are currently real
use cases. And as I read from the comments this may not be needed.

Finding a caret position that is obscured by another element seems
> plausible. It could be solved by adding a flag to caretPositionFromPoint()
> to cut through the layers and return the top-most caret position, if there
> is one.
>
Ok, that sounds plausible.

Are there any examples of this being a problem that people run into and
> work around?
>
I'm also interested in that. In which cases do you want to get the caret
position while the element is obscured by another element (and is not part
of the browser UI)?

Sebastian