[dom] setAttributeNode and setAttributeNodeNS can be an aliases (#117)

Another thing I found when investigating https://code.google.com/p/chromium/issues/detail?id=502301

In Blink/WebKit, setAttributeNode and setAttributeNodeNS are simply aliases. This means that there is no *namespace and local name flag*, and a case-insensitive search for an existing attribute is always done, for HTML documents. (Per spec it would be lowercasing `attr.localName` instead.)

An ad-hoc test, where Edge behaves like Blink/WebKit, while Gecko is the only engine to end up with two attributes:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3761

What the spec says is probably web compatible, but with some strangeness:
 1. As of https://github.com/whatwg/dom/pull/75, `createAttribute` will lowercase the input, so also lowercasing `attr.localName` is unlikely to be needed for compat.
 2. By doing **get an attribute by name** and removing the found attribute, there can still be more attributes by the same name, so no interesting invariant is upheld: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3762

So what to do?

My proposal is to make setAttributeNode do the equivalent of `getAttributeNodeNS(attr.namespaceURI, attr.localName)` with no lowercasing or case-insensitive lookup. setAttributeNodeNS would be an exact alias, and we could consider removing it. Usage is [super low](https://www.chromestatus.com/metrics/feature/timeline/popularity/216).

CC @bzbarsky @Ms2ger 

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/117