Re: Transformed Pointer Coordinates?

On Feb 4, 2013, at 7:54 AM, Simon Fraser <smfr@me.com> wrote:

> On Feb 3, 2013, at 3:06 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> 
>> On Jan 31, 2013, at 12:04 PM, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote:
>> 
>>> On Wed, Jan 30, 2013 at 1:42 AM, Robert O'Callahan < rocallahan@gmail.com > wrote:
>>>> On Wed, Jan 30, 2013 at 5:20 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>>> Not particularly happy with the naming, but +1 on the ability *so much*.
>>>>> 
>>>>> I suspect it should go in CSSOM View?
>>>> 
>>>> Probably.
>>> 
>>> I agree, CSSOM View makes sense to me.  I opened up a bug to track this:
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20832
>>> 
>>>> As for naming: should we call the type CSSPoint? Or is it OK to take "Point" for this? convertPointFromPageToNode doesn't strike me as a great name but it's probably not worth changing.
>>> 
>>> I'd be a bit worried Point might collide with existing variables sites use in the global scope. DOMPoint or CSSPoint seems better to me.
>>> 
>>>> There are a bunch of edge cases to sort out --- e.g. nodes with no associated CSS box; nodes with more than one CSS box; nodes in a different document; nodes inside a container with a singular CSS transform; etc. I have no idea how Webkit handles any of those.
>>>> 
>>>> In theory one could run into problems using these APIs to convert points from one node to another, where both nodes are in a subtree whose root has a singular CSS transform. Converting through the page coordinate system would lose information unnecessarily. That problem may not be worth worrying about.
>>> 
>>> My 2 cents:
>>> 
>>> At least in pages I've built, going from one element to another was the more common scenario for me.  So before learning about these webkit APIs, I was expecting something off of Element or Node. For example:
>>> 
>>>   toNode.convertPointFromNode(fromNode, pt)  //Converts the Point pt from the coordinate system used by fromNode into the coordinate system of toNode and returns it
>>> 
>>> So then you can do:
>>> 
>>>  htmlElement.convertPointFromNode(document, pt)  //Same as convertPointFromPageToNode
>>>  document.convertPointFromNode(htmlElement, pt) //Same as convertPointFromNodeToPage
>>>  htmlElement1.convertPointFromNode(htmlElement2, pt) //Convert between 2 elements
>>> 
>>> And probably also:
>>> 
>>>   svgElement.convertPointFromNode(htmlElement, pt) //Covert between SVG and HTML nodes' coord systems
>>> 
>>> Also, I wonder if it might be useful to get the transform matrix between 2 nodes as a CSSMatrix object. 
>>> 
>> 
>> I just want to admit that we added a function to SVG2 that allows getting a transformation from one element to another element:
>> 
>> ""
>> SVGMatrix getTransformToElement(SVGGraphicsElement element)
>> 
>> Returns the transformation matrix from the user coordinate system on the current element (after application of the ‘transform’ property) to the user coordinate system on parameter element (after application of its ‘transform’ property).
>> ""
>> 
>> I think a CSS OM solution sounds better. But nodeToPage and pageToNode is not enough IMO. Adding a transformFromNodeToNode in general would be great. We discussed CSSMatrix as interface before, but decided to remove it from the CSS Transforms spec, since CSSOM was not ready yet. I don't think that this changed substantially. This would be really helpful for this purpose.
> 
> transformFromNodeToNode can be problematic because of flattening, which throws away the Z component. I think this would preclude having a single transform that allows mapping from the root down into elements in a 3D rendering context.

Why isn't that a problem for nodeToPage then?

Dirk

> 
> Simon
> 
>> I support a DOMPoint, or CSSPoint interface as well, but would like to make sure that it can be used in SVG and Canvas as well. So just Point or maybe DOMPoint might be a better name instead of CSSPoint.
>> 
>> Greetings,
>> Dirk
>

Received on Sunday, 3 February 2013 22:29:30 UTC