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 < [email protected]> 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 >>> 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 >> <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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f93cdcfd-9ed8-4695-ae03-4afdc5d93975n%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/CAG0MU3iazFy-JwTwAUSs7QPVffDEBeD16-SZ8qicQ9RkeS2T2A%40mail.gmail.com.
