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

On Wednesday, January 17, 2024 at 6:35:14 AM UTC-8 Daniel Bratell wrote:

> 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
> On 2024-01-16 18:31, 'Siye Liu' via blink-dev wrote:
>
> 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
>
> On Friday, January 12, 2024 at 5:23:25 PM UTC-8 Brian Birtles wrote:
>
> 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 [email protected]:
>
> Contact emails 
> [email protected], [email protected]
>
> 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 
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>
> 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 
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?
> 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 Status
> https://chromestatus.com/feature/5201014343073792
>
> This intent message was generated by Chrome Platform Status 
> <https://chromestatus.com/>.
>
> -- 
> 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 [email protected].
> 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
>  
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0169dc69-72a5-46e4-b377-e682f8818a80n%40chromium.org?utm_medium=email&utm_source=footer>
> .
>
>

-- 
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 [email protected].
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.

Reply via email to