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 >> 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://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 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 >> >> <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 blink-dev+...@chromium.org. > > 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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7183ed6f-73e0-4858-a477-5469d764efc8n%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 blink-dev+unsubscr...@chromium.org. 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.
