W3C home > Mailing lists > Public > www-style@w3.org > June 2013

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

From: Scott Johnson <sjohnson@mozilla.com>
Date: Tue, 25 Jun 2013 13:11:12 -0500
Message-ID: <51C9DD40.6090301@mozilla.com>
To: "www-style@w3.org" <www-style@w3.org>
Forgot to send to the entire list.

-------- Original Message --------
Subject: 	Re: [cssom-view] Is there a need for a plural form of
Date: 	Tue, 25 Jun 2013 13:10:46 -0500
From: 	Scott Johnson <sjohnson@mozilla.com>
To: 	Sebastian Zartner <sebastianzartner@gmail.com>

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.


Thus Spoke Sebastian Zartner:
> The question is if there is a specific use case, for which you need to
> get the caret position of a covered element and you currently need
> hacks to achieve that, so I can create a report for this.
> Sebastian
> On 25 June 2013 17:26, Scott Johnson <sjohnson@mozilla.com
> <mailto:sjohnson@mozilla.com>> wrote:
>     Actually, I think this could be fairly useful. Specifically, it would
>     be useful to be able to retrieve the caret position objects, which
>     include the node and offset, for every element returned from
>     elementFromPoint(). When using the caretPositionFromPoint method,
>     there
>     are situations (e.g. with abs-pos) where one element is displayed on
>     top of another one. If we returned all possible caret positions for a
>     given point, then we would have the option of choosing which one
>     to use
>     - an ability we don't currently have.
>     ~Scott
>     On Tue 25 Jun 2013 09:23:09 AM CDT, Sebastian Zartner wrote:
>     > In bug 19753[1] I mentioned to add a plural version of
>     > document.caretPositionFromPoint() besides the one for
>     > document.elementFromPoint(), so you can get the caret positions
>     of all
>     > elements at a specific point.
>     > Another idea was to add an element-specific function
>     > caretPositionFromPoint()[2], which would take coordinates
>     relative to
>     > the given element.
>     >
>     > Now I was asked for possible use cases for this function, though
>     > unfortunately I can't remember if I had a good one.
>     > One was related to having two overlapping text fields or areas
>     used to
>     > enable auto-completion like it's done for the Firebug Command Line.
>     > Though there you don't necessarily need the position of the
>     overlapped
>     > field.
>     >
>     > So I'm asking around if somebody sees a need for such a function.
>     >
>     > Sebastian
>     >
>     > [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19753
>     > [2] http://lists.w3.org/Archives/Public/www-style/2012Oct/0702.html
Received on Tuesday, 25 June 2013 18:11:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:31 UTC