Updated dom related reference files according to new IE spec

[zhengbli]

(Open a new PR that sorts the old dom files first for better diff)

The IE team started to issue new specs in the format of XML files instead of webidl files for upcoming API changes. The new dom.generated.d.ts and webworker.d.ts are generated from the new XML specs to be consistent with IE Dom API changes.

Related to PR #2645.

Issues that would be fixed:
#2437 Missing properties: document.pointerLockElement and MouseEvent.movement
#2416 WheelEvent constructor in lib.d.ts
#2029 Type definition of CustomEvent constructor needs parameter(s).
#1852 DOMStringMap is defined as an empty interface - this makes it awkward to use
#1850 "SOURCE"
#1618 "getElementsByTagName('svg')" does not returns NodeList of SVGSVGElement, but generic NodeList.
#1302 add declarations for HTML Touch events to lib.d.ts
#1224 EventListener interface does not accept objects with a handleEvent method

(not sure) #1075 IDBKeyRange definition is degraded
#674 MouseEvent constructor is missing parameters
#314 SourceBuffer.appendBuffer() is missing overload for ArrayBufferView param in lib.d.ts

[msftclas]

Hi @zhengbli, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Zhengbo Li). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

[mhegazy]

some comments:

• documentation seems to be lost. we need to copy these over to the new typings , see interface Document for examples
• interface Console methods, not all of them have to be "any" for instance:
  count(countTitle?: string): void; instead of count(countTitle?: any): void;
• Does IDBKeyRange really have methods bound, lowerBound, only. upperBound? or are these instance methods? you need to check if they marked as static or not
• can you sort the name of events before emitting the addEventListener calls, e.g in interface IDBOpenDBRequest, can we make addEventListener(type: "upgradeneeded", ... come at the end.
• For interfaces extending EventTarget do we still need addEventListener definition, e.g. MSStreamReader
• in interface XMLHTTPRequest, send(data?: string), should be before send*(data: any)
• in webworker.generated.d.ts, I do not think Audio, Image, an d Option should be defined.
• in getElementsByTagName, there are new element names that have capitalization, my understanding is that this function is case insensitive, can you check if this is true for new events, and if so, i would rather they all stay lowercase for consistency.
• same as previous comment but for addEventListener

[zhengbli]

I updated the files according to the comments. And because addEventListener is actually case sensitive, therefore I didn't change that part.

[mhegazy]

TextTrack.mode type is any|number, it should be any
Document.open should return Document | Window

other than that looks good 👍

[DustinWehr]

What is the recommendation for using Map and Set when compiling with --target ES5? Right now I'm using a <reference...> to lib.es6.d.ts, which makes compile succeed, but seems wrong.

Apologies if this is the wrong place to ask this; this pull request is referenced in https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes

[mhegazy]

@DustinWehr can you explain your scenario? what other types do you need from ES6 definitions that are not in lib.d.ts.

[DustinWehr]

@mhegazy - Just Map and Set. To be honest, the only reason I'm using them instead of some other library is because they were imported by default with TypeScript 1.4. Perhaps I should be using different libraries. I see now this is discussed in #3005 and #3069. Wasn't worth bothering you guys about.

[mhegazy]

@DustinWehr the issue is these were IE-specific and were removed as part of the cleanup. it should be safe to include just the definitions in a file in your project, and it should behave the same as in 1.4.

interface Map<K, V> {
    clear(): void;
    delete(key: K): boolean;
    forEach(callbackfn: (value: V, index: K, map: Map<K, V>) => void, thisArg?: any): void;
    get(key: K): V;
    has(key: K): boolean;
    set(key: K, value: V): Map<K, V>;
    size: number;
}
declare var Map: {
    new <K, V>(): Map<K, V>;
    prototype: Map<any, any>;
}

interface Set<T> {
    add(value: T): Set<T>;
    clear(): void;
    delete(value: T): boolean;
    forEach(callbackfn: (value: T, index: T, set: Set<T>) => void, thisArg?: any): void;
    has(value: T): boolean;
    size: number;
}
declare var Set: {
    new <T>(): Set<T>;
    prototype: Set<any>;
}