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
>