Intent to Implement: GeometryUtils

[Jinho Bang]

Contact emails

jinho...@samsung.com

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?

https://crbug.com/468662

Link to entry on the feature dashboard

Small change

Requesting approval to ship?

No

[Philip Jägenstedt]

LGTM, in particular as convertPointFromNode was request as a replacement for webkitConvertPointFromNodeToPage():

https://groups.google.com/a/chromium.org/d/msg/blink-dev/2tHsZZom43g/UZJlvUSyva8J

One thing that strikes me as strange about the spec is that Text, PseudoElement and Document implement GeometryUtils, are all of those actually useful? Having it just for Element and possibly Range (like getBoundingClientRect) would seem like a very good start.

Nevertheless, LGTM to try implementing the bits that make sense to you and a reviewer, and just ask Simon (CC'd) to change the spec if needed :)

Philip

[Chris Harrelson]

Hi Jinho,

Sounds great. LGTM

Please cc me on your tracking bug. I'm also happy to provide advice on the implementation.

There is some related refactoring that the Paint team is likely to do soon that might affect the final implementation, but for now it's fine to plug into the existing geometry conversion coded within Blink.

Thanks,

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Rogers]

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?

[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/V_bJNtOg0oM/Tcc0NZkELAYJ

[2] https://lists.webkit.org/pipermail/webkit-dev/2014-June/026593.html

[Julien Chaffraix]

On Mon, Mar 23, 2015 at 11:00 AM, Philip Rogers <p...@chromium.org> wrote:
> 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?
>
> [1]
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/V_bJNtOg0oM/Tcc0NZkELAYJ
> [2] https://lists.webkit.org/pipermail/webkit-dev/2014-June/026593.html

You can add several concerns to the list about the API:
- getBoxQuads is very close to what Houdini is offering through the
box tree API [3]. It's also close to some out-of-tree element measure
API that I have been thinking about. We should try to have a single
API instead of 3 here.
- getBoxQuads is synchronous which is something we would prefer not to
have as it makes hitting Midnight Train harder.
- the specification doesn't say how it's supposed to work. How can
reviewers know if any patch is correct and interoperable?

Thanks,
Julien

[3] http://drafts.css-houdini.org/box-tree-api/

[Jinho Bang]

2015년 3월 24일 화요일 오전 3시 1분 5초 UTC+9, Philip Rogers 님의 말:

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?

[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/V_bJNtOg0oM/Tcc0NZkELAYJ

[2] https://lists.webkit.org/pipermail/webkit-dev/2014-June/026593.html

These APIs use the geometry interfaces but I thought the apis are one things and the interfaces are another.

There were some performance issues in geometry interfaces and their main issue was where we have to implement the interfaces. (DOM vs JS)

In other words, the interfaces may be solution and may not, but we will still need something like them.

So, though we implement the apis using the interfaces, we will be able to replace them to the new interfaces later.

Anyway, I agree with you on the whole. Especially, we need to resolve the performance issues before shipping.

(But I'm not spec writer and my role is a small implementor. So, I need more enough time.)

[Jinho Bang]

2015년 3월 25일 수요일 오전 8시 1분 43초 UTC+9, Julien Chaffraix 님의 말:

Thank you for your inputs.

I'll check them. :) 

[Erik Dahlström]

Whichever way this goes, and if the goal is "one true API" then please
ensure that the chosen API is not restricted to the css box model only. It
should be generic enough to handle e.g <svg:path> elements. The proposed
APIs don't seem to provide any useful information for the <path> case, and
if we're trying to avoid adding multiple APIs then this should be
considered.


--
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

[Chris Harrelson]

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.

Thanks,

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Christian Biesinger]

Sorry for the tangent, but what is Houdini?

-Christian

[Chris Harrelson]

On Wed, Mar 25, 2015 at 11:32 AM, Christian Biesinger <cbies...@chromium.org> wrote:

Sorry for the tangent, but what is Houdini?

https://wiki.css-houdini.org/

[Julien Chaffraix]

On Wed, Mar 25, 2015 at 5:03 AM, Erik Dahlström <e...@opera.com> wrote:

This should probably be brought up on the appropriate standard's
mailing list. I am going to state my opinion here insofar as it
impacts this intent to implement.

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).

Julien

[Elliott Sprehn]

On Wed, Mar 25, 2015 at 1:10 PM, Julien Chaffraix <jchaf...@chromium.org> wrote:

[...]

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).

+1. 

[Joerg Birkhold]

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.

I agree getBoxQuads ist not necessary here. It is better to get a quick replacement for the webkit… methods. Without them developers are kind of lost in space.

Best regards

Joerg

__________________________________________

foresee _HUMANACTIVE SPACES

http://www.foresee.biz 

   | Jörg Birkhold  

   | 4CO - SCH

   | CTO        

   | mobile +49 179 90 80 480

   | fax: +49-5042 999 226

   | mail: joerg.b...@foresee.biz

Steuer Nr. 2220074220

Amtsgericht Hannover, HRB 102086

UsSt.ID.Nr. DE814257868

__________________________________________

Important note: 

This message is for the named person's use only. It contains confidential,

proprietary or legally privileged information. No confidentiality or

privilege is waived or lost by any mis-transmission. If you receive this

message in error, please immediately delete it and all copies of it from

your system, destroy any hard copies of it and notify the sender. You must

not, directly or indirectly, use, disclose, distribute, print, or copy any

part of this message if you are not the intended recipient.

[tru...@gmail.com]

Are there any polyfills for GeometryUtils so we can begin using the API right now?

[/#!/JoePea]

I got no reply, but want to note that I started a Geometry Interfaces
polyfill at http://github.com/trusktr/geometry-interfaces. :]
/#!/JoePea

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "blink-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/aYgtvcaIn6E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> blink-dev+...@chromium.org.

[act...@gmail.com]

And why not implemented?

[Jochen Kühner]

I found this old thread, cause I'm looking for an API wich I need in a designer. getBoxQuads would be exactly what I need.
It's sad it's not yet implemented, but the bigger issue, it is even not possible to polyfill. It would be possible for HTMLElement cause you could traverse back all elements and combine all Transformations and Positionings, and so you could calculate them, but it is not possible for SVG and MathML Elements, cause they are missing the offset... properties.

see my issue: https://github.com/w3c/csswg-drafts/issues/10514

I know, this thread is 8 years old, but maybe

act...@gmail.com schrieb am Mittwoch, 13. Juli 2016 um 22:21:32 UTC+2:

And why not implemented?