Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use DOMPoint instead of Point2D? #145

Closed
dontcallmedom opened this issue Jan 11, 2017 · 5 comments
Closed

Use DOMPoint instead of Point2D? #145

dontcallmedom opened this issue Jan 11, 2017 · 5 comments

Comments

@dontcallmedom
Copy link
Member

from @w3ctag 's review @travisleithead:

Consider allowing a DOMPoint in places where a Point2D dictionary could be used (DOMPoint from http://www.w3.org/TR/geometry-1/#DOMPoint). The DOMPoint handles points in 3d space, but the 'z' and 'w' coordinates are not required, and this may be useful for platform consistency.

@yellowdoge
Copy link
Member

DOMPoint is an interface needing all its attributes x,y,z,w (I don't see any indication of z and w being not required), whereas Point2D is a dictionary with just x and y.

Moreover, DOMPoint is not 'just' a cartesian point but a 3D point with a perspective w attached to it (although this is by default 1.0) --The reason for this pseudo-quaternion situation is that DOMPoint is meant to play nicely with transformation DOMMatrixes.

Using DOMPoint would be confusing for users, since two of the said DOMPoint attributes are not used in this case but they actually relate to the mathematics of perspective cameras. Perhaps DOMPoint should be renamed to DOMPoint3D and a DOMPoint2D added to the Geometry interfaces Spec.

Finally, if any of the Geometry Interfaces would be needed, DOMRect would be the least removed one.

@domenic
Copy link

domenic commented Mar 28, 2017

Because Point2D is only used in dictionaries, the distinction is very slight. If DOMPointInit was used (not DOMPoint; that would be bad) then inputs like { x: 1, y: 2, get z() { throw new Error("z"); } } would throw when being converted to a DOMPointInit, even though the plan is to ignore the z (and w). Whereas in the current spec, given such input the z (and w) are ignored, so it would not throw. So I think Point2D as used here is the right choice.

However, if the points were ever exposed externally (e.g. as attribute values or method return values), then DOMPoint might be a better choice, for platform harmony. I can't find any such instances in the spec right now.

@yellowdoge
Copy link
Member

getSettings() returns a MediaTrackSettings that has a sequence<Point2D> representing the current points/areas used for A3 calculation.

@yellowdoge
Copy link
Member

@domenic I'm closing this issue, plz reopen or shout if this is not intended, thanks!

@travisleithead
Copy link
Member

Works for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants