Removing CssValue APIs

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

 // Copyright (c) 2012, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 part of $LIBRARYNAME;
 
 $if DART2JS
 $(ANNOTATIONS)class $CLASSNAME$EXTENDS$IMPLEMENTS native "@*DOMWindow" {
 $else
 $(ANNOTATIONS)class $CLASSNAME$EXTENDS$IMPLEMENTS$NATIVESPEC {
@@ skipping 207 matching lines @@
 $else
   /// Checks if _setImmediate is supported.
   static bool get _supportsSetImmediate => false;
 
   /// Dartium stub for IE's setImmediate.
   void _setImmediate(void callback()) {
     throw new UnsupportedError('setImmediate is not supported');
   }
 $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
 }