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
Statushttps://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/d367667d-3bc7-40c4-87e3-ca360b9aa615%40gmail.com.
