I've been wondering about this for a while too. AFAIK, there's no built-in way to ask the browser to transform points like this, so you have to write a heavy function to walk the tree and inspect the styles manually. The function ends up being huge and brittle - there's no forward compatible way to do it given that new CSS properties might show up in the future. However, this part of the CSSOM spec <https://drafts.csswg.org/cssom-view/#the-geometryutils-interface> adds an interface (`GeometryUtils`) that sounds like it's intended to do this, but every time I've returned to that page over the last handful of years, they still have basically zero description.
The lack of this function means that there's no way to handle coordinates from pointer events in relation to arbitrarily transformed elements in a robust way. :( On Tuesday, February 7, 2023 at 4:15:01 PM UTC-8 John R. wrote: > sorry about responding to this old bug, but is there a modern polyfill for > this? an old website i'm using requires this (and other deprecated WK > functions) and i have found nothing to mitigate this issue. > > On Monday, July 28, 2014 at 4:58:28 PM UTC-4 Philip Jägenstedt wrote: > >> Primary eng (and PM) emails >> >> [email protected] >> >> Summary >> Remove webkitConvertPointFromPageToNode() and >> webkitConvertPointFromNodeToPage(). >> >> These are global functions, exposed on Window. >> >> Motivation >> >> They were added in https://bugs.webkit.org/show_bug.cgi?id=23943 to "map >> points through possibly-transformed elements." At least the uses of them >> in LayoutTests can be replaced with getBoundingClientRect(), which also >> take transforms into consideration. The same is likely true of usage in the >> wild, too. >> >> >> These two functions are also the only APIs that depend on WebKitPoint, >> paving the way for its eventual removal. >> >> Compatibility Risk >> >> The worst-case scenario is catastrophic failure of a WebKit-only site. >> Given the usage, actual risk seems very low indeed. >> >> Alternative implementation suggestion for web developers >> >> Use element.getBoundingClientRect().left/top to get the offsets that >> these functions would add/remove. >> >> >> For example, webkitConvertPointFromNodeToPage(element, new >> WebKitPoint(0,0)).x can be replaced by element.getBoundingClientRect().left. >> >> >> Usage information from UseCounter >> <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39> >> webkitConvertPointFromPageToNode() ~0.0001%: >> http://www.chromestatus.com/metrics/feature/timeline/popularity/359 >> webkitConvertPointFromNodeToPage() ~0.0002%: >> http://www.chromestatus.com/metrics/feature/timeline/popularity/360 >> >> Entry on chromestatus.com, crbug.com, or MDN >> >> None. >> >> Requesting approval to remove too? >> Yes. Usage is negligible. >> > -- 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/b8b27009-727a-408a-aad8-1fac6d6972bbn%40chromium.org.
