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

> 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