Removing CssValue APIs

tools/dom/templates/html/impl/impl_Window.darttemplate

Index: tools/dom/templates/html/impl/impl_Window.darttemplate
diff --git a/tools/dom/templates/html/impl/impl_Window.darttemplate b/tools/dom/templates/html/impl/impl_Window.darttemplate
index d8d90d610417447acfb9a3423f784baee18a2522..be5ed459a147b6c66e2bc5b77532b100017ff1e5 100644
--- a/tools/dom/templates/html/impl/impl_Window.darttemplate
+++ b/tools/dom/templates/html/impl/impl_Window.darttemplate
@@ -225,5 +225,30 @@ $else
   }
 $endif
 
+  @DomName('DOMWindow.convertPointFromNodeToPage')
+  @SupportedBrowser(SupportedBrowser.CHROME)
+  @SupportedBrowser(SupportedBrowser.SAFARI)
+  @Experimental
+  Point convertPointFromNodeToPage(Node node, Point point) {
+    var result = _convertPointFromNodeToPage(node,
+        new _DomPoint(point.x, point.y));

[Jacob, 2013/03/21 23:11:51]

I think the JavaScript API for this was supposed to accept arbitrary objects of
the form {x: NUM, y: num}.  We might be able to use that to avoid performing
this conversion in the future.

[blois, 2013/04/02 20:25:30]

Can we guarantee that the fields x & y will not be renamed via minification?

[Jacob, 2013/04/02 23:57:13]

I doubt we can.  
On 2013/04/02 20:25:30, blois wrote:

+    return new Point(result.x, result.y);

[Jacob, 2013/03/21 23:11:51]

why not just make _DomPoint implement Point so this isn't required?

[blois, 2013/04/02 20:25:30]

That seems like a heavier solution than necessary here, this should be a fairly
lightweight conversion and I'd prefer to do the conversion (though went in the
opposite direction for ClientRect).

[Jacob, 2013/04/02 23:57:13]

Why not make both cases consistent?
On 2013/04/02 20:25:30, blois wrote:

[blois, 2013/04/05 18:03:07]

Had a good discussion with Stephen on this, would be happy to discuss again,
there's not a real clear answer but:

1) There needs to be a conversion for points coming into these methods as they
are most likely not going to be _DomPoints.
2) There's probably no win by caching the converted _DomPoint
3) For conversion vs implements of the return value, the cost to conversion is
accessing each DOM property at conversion time, even if the properties are not
needed (2x higher conversion cost for ClientRect compared to DomPoint)
4) The cost to 'implements' is that the compiler may not know the actual
implementation type is and need to add get$x() methods. These adds quite a bit
of unwanted overhead, but whether or not this is added changes daily with the
dart2js compiler.

Result:
Conversion overhead for ClientRect is most likely too high, implements better
for that (2x as many fields).
Inclination that potential compiler misunderstanding of types for DomPoint
implementing Point outweighs conversion costs.

+  }
+
+  @DomName('DOMWindow.convertPointFromPageToNode')
+  @SupportedBrowser(SupportedBrowser.CHROME)
+  @SupportedBrowser(SupportedBrowser.SAFARI)
+  @Experimental
+  Point convertPointFromPageToNode(Node node, Point point) {
+    var result = _convertPointFromPageToNode(node,
+        new _DomPoint(point.x, point.y));
+    return new Point(result.x, result.y);
+  }
+
+  /**
+   * Checks whether [convertPointFromNodeToPage] and
+   * [convertPointFromPageToNode] are supported on the current platform.
+   */
+  static bool get supportsPointConversions => _DomPoint.supported;
 $!MEMBERS
 }