Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

TAG suggested we put the shadow roots in a dictionary with a `shadowRoots` 
option (The API shape changed in spec 
 
after the TAG review was filed). That's what Chromium implemented: document.idl 
- Chromium Code Search 
.
 
I think we are good here.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cb567424-b450-4965-aca9-2910ff533199n%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

Yes, these tests will all pass if we enable the runtime flag 
`CaretPositionFromPoint`. 

The few Mozilla failures do represent their non-spec compliant behavior.

Thanks,
Siye

On Wednesday, June 12, 2024 at 4:03:35 AM UTC-7 yoav...@chromium.org wrote:

> On Thu, Jun 6, 2024 at 9:03 PM 'Siye Liu' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Reviews requested.
>>
>> Thanks,
>> Siye
>>
>> On Thursday, June 6, 2024 at 9:47:37 AM UTC-7 Chris Harrelson wrote:
>>
>>> Hi, please fill out these reviews on your chromestatus entry:
>>>
>>> [image: image.png]
>>>
>>> On Wed, Jun 5, 2024 at 8:09 PM 'Siye Liu' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
>>>> Yes, the API returns offset inside text input and textarea elements.
>>>>
>>>> Thanks,
>>>> Siye
>>>>
>>>> On Wednesday, June 5, 2024 at 5:10:18 PM UTC-7 Brian Birtles wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Does this return the offset inside text input elements like Gecko's 
>>>>> implementation?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Brian
>>>>>
>>>>> 2024年6月6日木曜日 3:20:24 UTC+9 si...@microsoft.com:
>>>>>
>>>>>> Contact emails
>>>>>> si...@microsoft.com, sa...@microsoft.com
>>>>>>
>>>>>> Explainer
>>>>>> None
>>>>>>
>>>>>> Specification
>>>>>>
>>>>>> https://drafts.csswg.org/cssom-view/#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. The API also supports get CaretPosition inside Shadow DOM. To get 
>>>>>> CaretPosition inside Shadow DOM, caller needs to provide reference to 
>>>>>> all 
>>>>>> the shadow roots that this API can pierce into. 
>>>>>>
>>>>>>
>>>>>> Blink component
>>>>>> Blink>CSS 
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>>
>>>>>> TAG review
>>>>>> document.caretPositionFromPoint API in shadow DOM scenario · Issue 
>>>>>> #949 · w3ctag/design-reviews (github.com) 
>>>>>> <https://github.com/w3ctag/design-reviews/issues/949>
>>>>>>
>>>>>> TAG review status
>>>>>> Issues open
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>> Gecko already implemented the API without the argument that contains 
>>>>>> shadow roots that this API can pierce into. Webkit/Blink didn't 
>>>>>> implement 
>>>>>> it. The Gecko implementation in shadow DOM scenario is not 
>>>>>> spec-compliant 
>>>>>> either (Spec changed recently to cover shadow DOM scenario). Gecko 's 
>>>>>> position is positive on this API. We expect that Gecko's behavior will 
>>>>>> be 
>>>>>> changed to be spec-compliant in the future. There is also a future 
>>>>>> compat 
>>>>>> risk too if we decided to deprecate the non-standard API 
>>>>>> `document.caretRangeFromPoint`: https://crbug.com/690599
>>>>>>
>>>>>>
>>>>>> *Gecko*: Positive (
>>>>>> https://github.com/mozilla/standards-positions/issues/1012)
>>>>>>
>>>>>> *WebKit*: Support (
>>>>>> 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: 
>&g

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

Reviews requested.

Thanks,
Siye

On Thursday, June 6, 2024 at 9:47:37 AM UTC-7 Chris Harrelson wrote:

> Hi, please fill out these reviews on your chromestatus entry:
>
> [image: image.png]
>
> On Wed, Jun 5, 2024 at 8:09 PM 'Siye Liu' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Yes, the API returns offset inside text input and textarea elements.
>>
>> Thanks,
>> Siye
>>
>> On Wednesday, June 5, 2024 at 5:10:18 PM UTC-7 Brian Birtles wrote:
>>
>>> Hi,
>>>
>>> Does this return the offset inside text input elements like Gecko's 
>>> implementation?
>>>
>>> Best regards,
>>>
>>> Brian
>>>
>>> 2024年6月6日木曜日 3:20:24 UTC+9 si...@microsoft.com:
>>>
>>>> Contact emails
>>>> si...@microsoft.com, sa...@microsoft.com
>>>>
>>>> Explainer
>>>> None
>>>>
>>>> Specification
>>>> https://drafts.csswg.org/cssom-view/#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. The API also supports get CaretPosition inside Shadow DOM. To get 
>>>> CaretPosition inside Shadow DOM, caller needs to provide reference to all 
>>>> the shadow roots that this API can pierce into. 
>>>>
>>>>
>>>> Blink component
>>>> Blink>CSS 
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>
>>>> TAG review
>>>> document.caretPositionFromPoint API in shadow DOM scenario · Issue #949 
>>>> · w3ctag/design-reviews (github.com) 
>>>> <https://github.com/w3ctag/design-reviews/issues/949>
>>>>
>>>> TAG review status
>>>> Issues open
>>>>
>>>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>> Gecko already implemented the API without the argument that contains 
>>>> shadow roots that this API can pierce into. Webkit/Blink didn't implement 
>>>> it. The Gecko implementation in shadow DOM scenario is not spec-compliant 
>>>> either (Spec changed recently to cover shadow DOM scenario). Gecko 's 
>>>> position is positive on this API. We expect that Gecko's behavior will be 
>>>> changed to be spec-compliant in the future. There is also a future compat 
>>>> risk too if we decided to deprecate the non-standard API 
>>>> `document.caretRangeFromPoint`: https://crbug.com/690599
>>>>
>>>>
>>>> *Gecko*: Positive (
>>>> https://github.com/mozilla/standards-positions/issues/1012)
>>>>
>>>> *WebKit*: Support (
>>>> 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
>>>>
>>>>
>>>> Will this feature be supported on all six Blink platforms (Windows, 
>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?
>>>> Yes
>>>>
>>>> Is this feature fully tested by web-platform-tests 
>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>> ?
>>>> Yes
>>>>
>>>>
>>>> https://github.com/web-platform-tests/wpt/blob/master/css/cssom/caretPositionFromPoint.html
>>>>  
>>>> https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/Document-c

[blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

Yes, the API returns offset inside text input and textarea elements.

Thanks,
Siye

On Wednesday, June 5, 2024 at 5:10:18 PM UTC-7 Brian Birtles wrote:

> Hi,
>
> Does this return the offset inside text input elements like Gecko's 
> implementation?
>
> Best regards,
>
> Brian
>
> 2024年6月6日木曜日 3:20:24 UTC+9 si...@microsoft.com:
>
>> Contact emails
>> si...@microsoft.com, sa...@microsoft.com
>>
>> Explainer
>> None
>>
>> Specification
>> https://drafts.csswg.org/cssom-view/#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. The API also supports get CaretPosition inside Shadow DOM. To get 
>> CaretPosition inside Shadow DOM, caller needs to provide reference to all 
>> the shadow roots that this API can pierce into. 
>>
>>
>> Blink component
>> Blink>CSS 
>> 
>>
>> TAG review
>> document.caretPositionFromPoint API in shadow DOM scenario · Issue #949 · 
>> w3ctag/design-reviews (github.com) 
>> 
>>
>> TAG review status
>> Issues open
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>> Gecko already implemented the API without the argument that contains 
>> shadow roots that this API can pierce into. Webkit/Blink didn't implement 
>> it. The Gecko implementation in shadow DOM scenario is not spec-compliant 
>> either (Spec changed recently to cover shadow DOM scenario). Gecko 's 
>> position is positive on this API. We expect that Gecko's behavior will be 
>> changed to be spec-compliant in the future. There is also a future compat 
>> risk too if we decided to deprecate the non-standard API 
>> `document.caretRangeFromPoint`: https://crbug.com/690599
>>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/1012)
>>
>> *WebKit*: Support (
>> 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
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, ChromeOS, Android, and Android WebView)?
>> Yes
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?
>> Yes
>>
>>
>> https://github.com/web-platform-tests/wpt/blob/master/css/cssom/caretPositionFromPoint.html
>>  
>> https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/Document-caretPositionFromPoint.tentative.html
>>
>>
>> Flag name on chrome://flags
>> None
>>
>> Finch feature name
>> CaretPositionFromPoint
>>
>> Requires code in //chrome?
>> False
>>
>> Tracking bug
>> https://crbug.com/388976
>>
>> Estimated milestones
>> Shipping on desktop
>> 127
>> DevTrial on desktop
>> 127
>>
>>
>> Anticipated spec changes
>> *Open questions about a feature may be a source of future web compat or 
>> interop issues. Please list open issues (e.g. links to known github issues 
>> in the project for the feature specification) whose resolution may 
>> introduce web compat/interop risk (e.g., changing to naming or structure of 
>> the API in a non-backward-compatible way).*
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5201014343073792
>>
>> Links to previous Intent discussions
>> Intent to prototype: 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2618db7c-56d2-4ff2-89c5-df65e1dfe6c7n%40chromium.org
>>  Ready 
>> for Trial: 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/v4MLESmFR1c/m/UhstKjucAAAJ
>>
>>
>> This intent message was generated by Chrome Platform Status 
>> .
>>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4127f29a-82e6-41d0-bab4-596f66fa43c9n%40chromium.org.

[blink-dev] Intent to Ship: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

Contact emails
si...@microsoft.com, 
sa...@microsoft.com

Explainer
None

Specification
https://drafts.csswg.org/cssom-view/#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. The API also 
supports get CaretPosition inside Shadow DOM. To get CaretPosition inside 
Shadow DOM, caller needs to provide reference to all the shadow roots that this 
API can pierce into.


Blink component
Blink>CSS

TAG review
document.caretPositionFromPoint API in shadow DOM scenario · Issue #949 · 
w3ctag/design-reviews 
(github.com)

TAG review status
Issues open

Risks


Interoperability and Compatibility
Gecko already implemented the API without the argument that contains shadow 
roots that this API can pierce into. Webkit/Blink didn't implement it. The 
Gecko implementation in shadow DOM scenario is not spec-compliant either (Spec 
changed recently to cover shadow DOM scenario). Gecko 's position is positive 
on this API. We expect that Gecko's behavior will be changed to be 
spec-compliant in the future. There is also a future compat risk too if we 
decided to deprecate the non-standard API `document.caretRangeFromPoint`: 
https://crbug.com/690599


Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1012)

WebKit: Support (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


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, 
ChromeOS, Android, and Android WebView)?
Yes

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

https://github.com/web-platform-tests/wpt/blob/master/css/cssom/caretPositionFromPoint.html
 
https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/Document-caretPositionFromPoint.tentative.html


Flag name on chrome://flags
None

Finch feature name
CaretPositionFromPoint

Requires code in //chrome?
False

Tracking bug
https://crbug.com/388976

Estimated milestones
Shipping on desktop
127
DevTrial on desktop
127


Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop 
issues. Please list open issues (e.g. links to known github issues in the 
project for the feature specification) whose resolution may introduce web 
compat/interop risk (e.g., changing to naming or structure of the API in a 
non-backward-compatible way).
None

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

Links to previous Intent discussions
Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2618db7c-56d2-4ff2-89c5-df65e1dfe6c7n%40chromium.org
 Ready for Trial: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/v4MLESmFR1c/m/UhstKjucAAAJ


This intent message was generated by Chrome Platform 
Status.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BL4PPFE529BCE9B6AE53745A1B777B21499ABF92%40BL4PPFE529BCE9B.namprd00.prod.outlook.com.

[blink-dev] Ready for Developer Testing: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

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. The API also supports get CaretPosition inside Shadow DOM. 


Blink component
Blink>CSS 


TAG review
None

TAG review status
Not applicable. This qualifies for an exception - has already shipped in 
another browser.

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


Goals for experimentation

Get feedback from web developers and assess whether the API meets developer 
needs.

Ongoing technical constraints

None


Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, ChromeOS, Android, and Android WebView)?
Yes

Is this feature fully tested by web-platform-tests 

?

The API is tested for main DOM in WPT: 
https://github.com/web-platform-tests/wpt/blob/c18cfd4eb319ca535db8c194941719598b3b6ea8/css/cssom/caretPositionFromPoint.html
 
Will add additional tests including cases for Shadow DOM scenario once 
https://github.com/w3c/csswg-drafts/issues/9932 is resolved.


Flag name on chrome://flags
None

Finch feature name
CaretPositionFromPoint

Requires code in //chrome?
False

Tracking bug
https://crbug.com/388976

Estimated milestones
DevTrial on desktop123

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

Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2618db7c-56d2-4ff2-89c5-df65e1dfe6c7n%40chromium.org

This intent message was generated by Chrome Platform Status 
.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7674d34f-0b09-4bcf-998a-9f8ab663a4f7n%40chromium.org.

Re: [blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

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

On Tuesday, January 23, 2024 at 1:45:44 PM UTC-8 dba...@chromium.org wrote:

> For what it's worth, some of the historical context around the 2009 
> changes is in WebApps TPAC 2009 minutes 
> <https://www.w3.org/2009/11/02-webapps-minutes.html#item04> and Anne's 
> folllowup email to www-style 
> <https://lists.w3.org/Archives/Public/www-style/2009Nov/0244.html>.
>
> -David
>
> On Tue, Jan 23, 2024 at 2:31 PM 'Dan Clark' via blink-dev <
> blin...@chromium.org> wrote:
>
>> 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
>>
>> On Thursday, January 18, 2024 at 6:13:48 AM UTC-8 Daniel Bratell wrote:
>>
>>> 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
>>> On 2024-01-17 23:38, 'Siye Liu' via blink-dev wrote:
>>>
>>> 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 caretRangeFro

Re: [blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

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 si...@microsoft.com:
>
> 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 
> <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:

[blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

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 si...@microsoft.com:

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 Status
https://chromestatus.com/feature/5201014343073792

This intent message was generated by Chrome Platform Status 
.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 

[blink-dev] Intent to Prototype: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

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 Status
https://chromestatus.com/feature/5201014343073792

This intent message was generated by Chrome Platform Status 
.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2618db7c-56d2-4ff2-89c5-df65e1dfe6c7n%40chromium.org.

Re: [blink-dev] PSA: Fire beforeinput event before compositionupdate event during IME composition.

['Siye Liu' via blink-dev]

Hi Mike,

I haven't done compatibility testing because Chromium's behavior was 
introduced in M53 by accident. We previously had the correct input event 
sequence. The commit 65dc0072cfd947170ef4dbee2dd1f4c7c399156f - 
chromium/src - Git at Google (googlesource.com) 
<https://chromium.googlesource.com/chromium/src/+/65dc0072cfd947170ef4dbee2dd1f4c7c399156f>
 is 
to fix the bug.

On Tuesday, September 26, 2023 at 9:13:14 AM UTC-7 Gary Kačmarčík 
(Кошмарчик) wrote:

> FWIW, according to 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1484762 we 
> previously had compositonupdate->beforeinput but inadvertently changed it 
> to the current order around M52.
>
> On Tue, Sep 26, 2023 at 8:04 AM Mike Taylor  wrote:
>
>> Hi there - 
>>
>> Given that this change is web observable, have you all done any 
>> compatibility testing or analysis to ensure sites aren't relying on the 
>> differences between engines here (hopefully not, but you know...)?
>> On 9/25/23 7:59 PM, 'Siye Liu' via blink-dev wrote:
>>
>> Hi blink-dev,
>>
>> We've been landing a change 
>> <https://chromium-review.googlesource.com/c/chromium/src/+/4878553>to 
>> enable new event ordering for beforeinput and compositionupdate during IME 
>> composition.
>>
>> The previous event ordering for IME composition was:
>>
>> keydown -> compositionstart -> *beforeinput -> compositionupdate* -> 
>> input -> keyup -> keydown -> *beforeinput -> compositionupdate* -> 
>> textInput -> input -> compositionend -> keyup.
>>
>> The new ordering is:
>>
>> keydown -> compositionstart -> *compositionupdate -> beforeinput* -> 
>> input -> keyup -> keydown -> *compositionupdate -> beforeinput* -> 
>> textInput -> input -> compositionend -> keyup.
>>
>> This change aligns our event ordering with the behavior of Firefox and 
>> Safari, which fire the beforeinput event after the compositionupdate event.
>>
>> The new event ordering is controlled by a runtime enabled feature flag 
>> that is set to stable status (enabled by default).
>> -- 
>> 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/bc3e3ab9-0740-4a4a-83f9-f95694f0127cn%40chromium.org
>>  
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc3e3ab9-0740-4a4a-83f9-f95694f0127cn%40chromium.org?utm_medium=email_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 blink-dev+...@chromium.org.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b56a3104-8f16-4d60-95ab-62b8705c4a7f%40chromium.org
>>  
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b56a3104-8f16-4d60-95ab-62b8705c4a7f%40chromium.org?utm_medium=email_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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d784d329-54fd-4eb8-b4c2-55ba13d944c0n%40chromium.org.

[blink-dev] PSA: Fire beforeinput event before compositionupdate event during IME composition.

['Siye Liu' via blink-dev]

Hi blink-dev,

We've been landing a change 
to 
enable new event ordering for beforeinput and compositionupdate during IME 
composition.

The previous event ordering for IME composition was:

keydown -> compositionstart -> *beforeinput -> compositionupdate* -> input 
-> keyup -> keydown -> *beforeinput -> compositionupdate* -> textInput -> 
input -> compositionend -> keyup.

The new ordering is:

keydown -> compositionstart -> *compositionupdate -> beforeinput* -> input 
-> keyup -> keydown -> *compositionupdate -> beforeinput* -> textInput -> 
input -> compositionend -> keyup.

This change aligns our event ordering with the behavior of Firefox and 
Safari, which fire the beforeinput event after the compositionupdate event.

The new event ordering is controlled by a runtime enabled feature flag that 
is set to stable status (enabled by default).

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc3e3ab9-0740-4a4a-83f9-f95694f0127cn%40chromium.org.