Port DocumentFragment to the new wrapperless DOM.

client/html/generated/html/dartium/Clipboard.dart

Index: client/html/generated/html/dartium/Clipboard.dart
diff --git a/client/html/generated/html/dartium/Clipboard.dart b/client/html/generated/html/dartium/Clipboard.dart
index 29989bcc102b91bc409c5c73ebb6ed5a2848494e..69b4e7ff3eaea0918672092d7d3163a06546a1e8 100644
--- a/client/html/generated/html/dartium/Clipboard.dart
+++ b/client/html/generated/html/dartium/Clipboard.dart
@@ -14,7 +14,7 @@ class _ClipboardImpl extends _DOMTypeBase implements Clipboard {
 
   DataTransferItemList get items() => _wrap(_ptr.items);
 
-  List get types() => _wrap(_ptr.types);
+  List<String> get types() => _wrap(_ptr.types);
 

[Jacob, 2012/03/06 05:09:00]

can you keep CLs purely regenerating the DOM bindings separate from CLs with
actual changes. That will save a lot of time looking at the diffs.

[nweiz, 2012/03/06 20:10:47]

Do you mean the CLs shouldn't include unrelated DOM regenerations like this one?
Or do you mean they shouldn't include DOM any regenerations, even for the
template changes included in the main CL?

If it's the latter, I disagree; bundling those regenerations with the CLs that
produced them makes it easier for other people working on the bindings (since
they don't have to deal with a bunch of unrelated changes) and makes rollbacks
much more feasible.

[Jacob, 2012/03/06 22:41:59]

I mean avoid unrelated DOM regenerations whenever possible.  Naturally actually
regenerating the DOM to show what your .py script changes did is a good thing.
On 2012/03/06 20:10:47, nweiz wrote:

   void clearData([String type = null]) {
     if (type === null) {