Implement measurement using futures

client/html/src/DocumentFragmentWrappingImplementation.dart

Index: client/html/src/DocumentFragmentWrappingImplementation.dart
diff --git a/client/html/src/DocumentFragmentWrappingImplementation.dart b/client/html/src/DocumentFragmentWrappingImplementation.dart
index 54b9644270c644e46ebb47b3d345c6e82aae628b..a7f67d54d9a3b9f41f14cfbfdffaba33a500a4bf 100644
--- a/client/html/src/DocumentFragmentWrappingImplementation.dart
+++ b/client/html/src/DocumentFragmentWrappingImplementation.dart
@@ -127,13 +127,20 @@ class EmptyStyleDeclaration extends CSSStyleDeclarationWrappingImplementation {
   }
 }
 
-class EmptyClientRect implements ClientRect {
-  num get bottom() => 0;
-  num get top() => 0;
-  num get left() => 0;
-  num get right() => 0;
-  num get height() => 0;
-  num get width() => 0;
+Future<CSSStyleDeclaration> _emptyStyleFuture() {

[nweiz, 2011/10/28 03:58:38]

This pattern (initialize then complete immediately) seems like something that
should be done with a static method on Completer or Future, but I guess that's
something for a different CL.

[Jacob, 2011/10/31 22:09:50]

I agree.  Ideally the completer class should have a method that initializes,
completes immediately after a minimal async interval.

+  final completer = new Completer<CSSStyleDeclaration>();
+  completer.complete(new EmptyStyleDeclaration());

[nweiz, 2011/10/28 03:58:38]

It seems potentially dangerous to complete this synchronously, if it's done
asynchronously for real Elements.

[Jacob, 2011/10/31 22:09:50]

Good point. Fixed these two cases.  

+  return completer.future;
+}
+
+class EmptyElementRect implements ElementRect {
+  final ClientRect client = const SimpleClientRect(0, 0, 0, 0);
+  final ClientRect offset = const SimpleClientRect(0, 0, 0, 0);
+  final ClientRect scroll = const SimpleClientRect(0, 0, 0, 0);
+  final ClientRect bounding = const SimpleClientRect(0, 0, 0, 0);
+  final List<ClientRect> clientRects = const <SimpleClientRect>[];

[nweiz, 2011/10/28 03:58:38]

What's the reasoning behind specifying SimpleClientRect here rather than
ClientRect or just "const []"?

[Jacob, 2011/10/31 22:09:50]

that way

clientRects is List<ClientRect> will return true
and 
clientRects is List<FooBar> will return false

[nweiz, 2011/11/01 00:49:22]

But why not "const <ClientRect>[]"?

[Jacob, 2011/11/01 02:42:39]

I agree.  const <ClientRect>[] is better. Fixed.

+
+  const EmptyElementRect();
 }
 
 class DocumentFragmentWrappingImplementation extends NodeWrappingImplementation implements DocumentFragment {
@@ -222,6 +229,12 @@ class DocumentFragmentWrappingImplementation extends NodeWrappingImplementation
     return _on;
   }
 
+  Future<ElementRect> get rect() {
+    final completer = new Completer<ElementRect>();
+    completer.complete(const EmptyElementRect());
+    return completer.future;
+  }
+
   Element query(String selectors) =>
     LevelDom.wrapElement(_ptr.querySelector(selectors));
 
@@ -231,18 +244,6 @@ class DocumentFragmentWrappingImplementation extends NodeWrappingImplementation
   // If we can come up with a semi-reasonable default value for an Element
   // getter, we'll use it. In general, these return the same values as an
   // element that has no parent.
-  int get clientHeight() => 0;
-  int get clientWidth() => 0;
-  int get offsetHeight() => 0;
-  int get offsetWidth() => 0;
-  int get scrollHeight() => 0;
-  int get scrollWidth() => 0;
-  int get clientLeft() => 0;
-  int get clientTop() => 0;
-  int get offsetLeft() => 0;
-  int get offsetTop() => 0;
-  int get scrollLeft() => 0;
-  int get scrollTop() => 0;
   String get contentEditable() => "false";
   bool get isContentEditable() => false;
   bool get draggable() => false;
@@ -264,8 +265,10 @@ class DocumentFragmentWrappingImplementation extends NodeWrappingImplementation
   Set<String> get classes() => new Set<String>();
   Map<String, String> get dataAttributes() => const {};
   CSSStyleDeclaration get style() => new EmptyStyleDeclaration();
-  ClientRect getBoundingClientRect() => new EmptyClientRect();
-  List<ClientRect> getClientRects() => const [];
+  Future<CSSStyleDeclaration> get computedStyle() =>
+      _emptyStyleFuture();
+  Future<CSSStyleDeclaration> getComputedStyle(String pseudoElement) =>

[nweiz, 2011/10/28 03:58:38]

Is there any reason not to have this call computedStyle and avoid defining
_emptyStyleFuture?

[Jacob, 2011/10/31 22:09:50]

It matters very little.  My code is more verbose than needed but I think makes
the intent clearer.

+      _emptyStyleFuture();
   bool matchesSelector([String selectors]) => false;
 
   // Imperative Element methods are made into no-ops, as they are on parentless
@@ -362,4 +365,4 @@ class DocumentFragmentWrappingImplementation extends NodeWrappingImplementation
     throw new UnsupportedOperationException(
       "WebKit drop zone can't be set for document fragments.");
   }
-}
+}