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

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

From: François REMY <francois.remy.dev@outlook.com>
Date: Thu, 8 Aug 2013 00:12:55 +0200
Message-ID: <DUB120-W306CC51645B39554DA1969A55E0@phx.gbl>
To: Sebastian Zartner <sebastianzartner@gmail.com>, Scott Johnson <sjohnson@mozilla.com>
CC: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>
> 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



Hi there,

I'm just relaunching this thread as part of a broader effort to report the pain points I've discovered while building the new CSS Regions polyfill.



I've a specific use case for element-based versions of elementFromPoint and caretPositionFromPoint. My use case is to find out an element or a caret position (depending on context) inside an element, for example in order to extract overflowing content.

My initial work-around was to "absolutize" the coordinates of the element and use caretPoisitionFromPoint on the document, but it doesn't work if another element is layered above mine, as I discovered.

Hopefully, this hit-testing thing is an optimization so when it fails, I fall back to manual search of the overflowing point, but I can clearly see how a web components may want to be able to trigger an hit-testing on one of its element, for example to find out where is located the user content-editable content.



As a summary, I don't think we need a plural version of caretPositionFromPoint, but I wouldn't mind an Element.prototype.caretPositionFromPoint(x,y) function that would return by hit-testing based on Element-relative coordinates, and by ignoring any other element that's outside the specific element. The Element.prototype.element(s)FromPoint(x,y) would be a plus.

Thoughts? 		 	   		  
Received on Wednesday, 7 August 2013 22:13:23 UTC

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