Contact emails
Spec
http://dev.w3.org/csswg/cssom-view/#the-geometryutils-interface
(from https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2tHsZZom43g)
Summary
Web developers often need to determine where an element has been placed in the page, or more generally,
where it is relative to another element. Existing APIs for doing this have significant limitations.
The new GeometryUtils interface and its supporting interfaces (GeometryInterfaces such as DOMPoint,
DOMRect and so on) provide web standard APIs to address these problems.
(from https://hacks.mozilla.org/2014/03/introducing-the-getboxquads-api/)
Motivation
Until now, simple cases could be handled using getBoundingClientRect() and some math, but complex cases
(e.g. involving CSS transforms) were almost impossible to handle using standard APIs. The nonstandard APIs
webkitConvertPointToPage and webkitConvertPageToPoint are a big improvement, but apart from not being
standardized, they’re not as powerful as they need to be. In particular it’s more convenient and more robust to
provide an API for directly converting coordinates from one element to another.
(from https://hacks.mozilla.org/2014/04/coordinate-conversion-made-easy/)
Compatibility Risk
Low; It will be behind a runtime flag for now until the APIs (and the specification) are stable.
FYI, Some APIs have already implemented in Firefox.
Ongoing technical constraints
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
OWP launch tracking bug?
Link to entry on the feature dashboard
Small change
Requesting approval to ship?
NoTo unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
The DOMMatrix/DOMPoint/DOMRect/etc classes have had pushback in the past [1][2]. Have there been any changes to these classes, particularly to resolve the performance and liveness concerns?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Sorry for the tangent, but what is Houdini?
-Christian
Sorry for the tangent, but what is Houdini?
This should be a non-goal: it's definitely in the really-nice-to-have
category but I wouldn't block any API on that. The CSS and SVG models
are different enough that 2 APIs can coexist (one simple based on the
box model and a more complex and precise one for non-box based
renderers).
On 25.03.2015, at 18:52, Chris Harrelson <chri...@chromium.org> wrote:I agree with this objections to the current proposal. My LGTM was too hasty. The following need to be addressed before implementation. Once they are, please come back with another Intent to Implement.1. Fix performance issues. In particular, there should be no live objects, and any methods that return data for more than one element need to be async.2. Define the spec properly to be general and unified with Houdini.Also, the use case which motivated this Intent is computing geometry for specific nodes,as a replacement for webkitConvertPointFromPageToNode() and webkitConvertPointFromNodeToPage(), which do not require getBoxQuads. In addition, getBoxQuads is the primary performance concern with this Intent. Therefore, I suggest it be dropped. It should be much easier to get a clear spec and agreement on the remaining subset.
And why not implemented?