Intent to Prototype: document.caretPositionFromPoint API

[Siye Liu]

Contact emails

si...@microsoft.com, sa...@microsoft.com

Explainer

None

Specification

https://www.w3.org/TR/cssom-view-1/#dom-document-caretpositionfrompoint

Summary

This new API allows users to get current caret position from a given screen point. The API returns a CaretPosition object which represents the caret position indicating current text insertion point including the containing DOM node, caret's character offset, and the client rectangle of caret range.

Blink component

Blink>CSS

Motivation

document.caretPositionFromPoint API is in CSSOM View and is already implemented by Gecko. WebKit/Blink has similar document.caretRangeFromPoint API which returns a text range indicating the text insertion point. The existing API was in CSSOM View at the time it was implemented: https://bugs.webkit.org/show_bug.cgi?id=27046 http://web.archive.org/web/20090708002518/http://dev.w3.org/csswg/cssom-view/#the-documentview-interface The existing API was replaced by the new API later: https://hg.csswg.org/drafts/rev/4c7b6f843171. The switch happened around 2009 and we don't have the historical context about the decision. Given how long it has been since the spec was updated, we believe it's best that Blink complies with the spec so that future innovations with the API can be spec compliant and have lower interop/compat risk.

Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko already implemented the API. Webkit/Blink didn't implement it. The interop risk is that it's unclear at this moment about Webkit's position on this. We won't be able to achieve full interop with this API if Webkit isn't willing to support this API. There is a compat risk too if we decided to deprecate the old API: https://crbug.com/690599

Gecko: Shipped/Shipping

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/301)

Web developers: Positive (https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34) Web developers are asking to have document.caretPositionFromPoint API implemented in Blink: https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c28 https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

Yes

The API is tested in WPT: https://github.com/web-platform-tests/wpt/blob/c18cfd4eb319ca535db8c194941719598b3b6ea8/css/cssom/caretPositionFromPoint.html

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/388976

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5201014343073792

This intent message was generated by Chrome Platform Status.

[Brian Birtles]

Hi,

Will this also cover the behavioral differences between caretPositionFromPoint as implemented in Gecko and caretRangeFromPoint as implemented in Blink such as:

1. caretPositionFromPoint in Gecko digs into shadow DOM elements whereas caretRangeFromPoint in Blink does not.

2. When the point is over a text input element, caretPositionFromPoint in Gecko returns the text input element and offset into it but caretRangeFromPoint in Blink returns the nearest ancestor of the text input element. (Note that caretRangeFromPoint in Webkit returns the text input element but always returns a zero offset into it.)

Thanks,

Brian

2024年1月13日土曜日 3:35:59 UTC+9 si...@microsoft.com:

[Siye Liu]

Hi Brian,

To answer your question,

1. This prototype only covers the main dom scenario (https://crbug.com/388976). Shadow dom scenario is tracked in https://crbug.com/1514810.

2. The prototype should have similar behavior as caretRangeFromPoint's implementation in Blink (when the point is over an input element, the returned CaretPosition should be the nearest ancestor of the input element) because I expect both APIs share same hit testing logic under the hood.

Once the prototype is ready for dev trial, we can discuss further about improving current implementation in both caretRangeFromPoint and caretPositionFromPoint in Blink.

Thanks,

Siye

[Daniel Bratell]

This is not directly related to this one function but more to the whole API. I quickly skimmed the spec and I could not find out how it handles line breaks which make caret positions ambigious?

When you press the END key at one line, and the HOME key at the following line your caret DOM position can be the same, but the visual caret positions should be different, and so should certain actions like arrow-down and arrow-up.

When developing code to handle this in Opera, I solved it by letting carets know if they were connected forward or backwards (basically a bool) in the dom element, but maybe this is solved in some other way now?

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0169dc69-72a5-46e4-b377-e682f8818a80n%40chromium.org.

[Siye Liu]

Blink has similar concept called "affinity" when placing caret at wrapped line. definition: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/editing/visible_position.h;l=39-54

Thanks,

Siye

[Daniel Bratell]

Sounds like something that should be reflected in the specs. Again, not directly related to this Intent, but maybe something that should happen in parallel.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7183ed6f-73e0-4858-a477-5469d764efc8n%40chromium.org.

[Dan Clark]

For the shadow DOM scenario, have we started the spec conversation about what behavior we want to end up at? I find the Gecko behavior a bit suspicious since it's piercing into potentially-closed shadow trees without having a prior reference to them. Maybe caretPositionFromPoint should not pierce shadow DOMs and instead support shadows by being on DocumentOrShadowRoot. That said, since this is already shipped in Gecko it could be hard to reverse course.

If the shadow DOM question hasn't been discussed in standards yet I think it's worth kicking that off in parallel with prototyping, so it doesn't end up being a barrier to shipping the full implementation later on. A lot of the developer feedback has been about how caretRangeFromPoint doesn't work with shadows so it seems like this is of central importance for the API.

-- Dan

[David Baron]

For what it's worth, some of the historical context around the 2009 changes is in WebApps TPAC 2009 minutes and Anne's folllowup email to www-style.

-David

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f93cdcfd-9ed8-4695-ae03-4afdc5d93975n%40chromium.org.

[Siye Liu]

Thank you all for the feedback. I am going to open a ticket to discuss the expected behavior in shadow DOM and report the status back.

Thanks,

Siye