Closed dandclark closed 7 months ago
foolip
commented
10 months ago @dandclark we don't have a way to include only specific subtests in Interop 202X. From a quick look I think the idlharness.js tests might be checking that the return value of document.caretPositionFromPoint(5, 5) is a CaretPosition. But an idlharness.js test can't test much interesting about the returned CaretPosition object. A new test asserting the details about the returned object would be useful I think.
foolip
commented
10 months ago I've also sent https://github.com/web-platform-tests/wpt/pull/43114 to fix a harness error in the other test.
dandclark
commented
10 months ago I sent https://github.com/web-platform-tests/wpt/pull/43156 to add a test that does more to actually inspect the CaretPosition and confirm it corresponds to the intended position. Hopefully this could be added to the proposal in lieu of the idlharness test.
nairnandu
commented
7 months ago Thank you for proposing document.caretPostitionFromPoint for inclusion in Interop 2024.
We wanted to let you know that this proposal was not selected to be part of Interop 2024. This is because we got many more proposals than we could include in this year's project. Note that individual vendors may nevertheless choose to advance work in this area during the forthcoming year. We would welcome this proposal being resubmitted again next year, if necessary.
For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2024!
Posted on behalf of the Interop team.
Description
document.caretPositionFromPoint() provides the CaretPosition corresponding to a set of client coordinates in the DOM. This is useful for editing scenarios where the page needs to set the editing insertion position given a user click. It is standardized, and Gecko implements it, but Blink and Webkit implement a legacy document.caretRangeFromPoint(). Converging towards the standardized document.caretPositionFromPoint() would make it simpler for developers to build cross-browser editing experiences.
It's also a likely prerequisite for supporting creation of editing positions/ranges inside shadow DOM. Expanding upon the capabilities of document.caretPositionFromPoint() would be the best way to solve this problem, but consistent browser support of the current spec is needed before that approach can pay off for developers.
The current dichotomy also presents an additional surface for UA detection in Firefox since they are the only ones who implement caretPositionFromRange. Broader implementation would remove this UA detection vector.
Specification
https://drafts.csswg.org/cssom-view/#dom-document-caretpositionfrompoint
Open Issues
No response
Tests
https://wpt.fyi/results/css/cssom/caretPositionFromPoint-with-transformation.html And some sub-tests in https://wpt.fyi/results/css/cssom-view/idlharness.html
Current Implementations
Standards Positions
No response
Browser bug reports
https://bugs.chromium.org/p/chromium/issues/detail?id=388976
Developer discussions
Various developers chiming in on the crbug expressing a need for the API. See also the 44 stars on that bug. See also CSSWG discussion https://github.com/w3c/csswg-drafts/issues/6459.
Polls & Surveys
No response
Existing Usage
This use counter shows modest usage of caretRangeFromPoint, which is indicative of potential demand for caretPositionFromPoint.
Workarounds
Old stackoverflow question with several answers giving code working around the problem: https://stackoverflow.com/questions/3189812/creating-a-collapsed-range-from-a-pixel-position-in-ff-webkit Another stackoverflow question where caretPositionFromPoint/caretRangeFromPoint and their inconsistent browser support come up in several of the answers: https://stackoverflow.com/questions/2444430/how-to-get-a-word-under-cursor-using-javascript
Accessibility Impact
No response
Privacy Impact
No response
Other
No response