How about setAttributeNode() then?

Here are all the interesting counters:

Element.getAttributeNode: http://www.chromestatus.com/metrics/feature/timeline/popularity/107
Element.getAttributeNodeNS: http://www.chromestatus.com/metrics/feature/timeline/popularity/110
Element.setAttributeNode: http://www.chromestatus.com/metrics/feature/timeline/popularity/108
Element.removeAttributeNode: http://www.chromestatus.com/metrics/feature/timeline/popularity/109
Document.createAttribute: http://www.chromestatus.com/metrics/feature/timeline/popularity/111
Document.createAttributeNS: http://www.chromestatus.com/metrics/feature/timeline/popularity/112 (already removed from Blink)

setAttributeNode(), at ~0.15% is also above the threshold for removal. The only ones clearly below are getAttributeNodeNS() and removeAttributeNode().

I assume that the way things would be spec'd is to have getAttributeNode() return one of the objects in the children array and for setAttributeNode(node) to just call setAttribute(node.name, node.value)?

If we are going to have createAttribute(), and getAttributeNode() / setAttributeNode(), I would expect these signatures:

Attr createAttribute(DOMString localName)
Attr? getAttributeNode(DOMString name)
Attr? setAttributeNode(Attr attribute)

And roughly equivalent semantics to how they are implemented today, including throwing "InuseAttributeError".

Note that createAttribute() is different between Gecko and WebKit/Blink. Gecko's behavior makes more sense given the lack of namespaces.

In other words, the association with an element is coming back just to support throwing an exception? If so it's just as well to make setting/getting the Attr.value use the associated element as well.

Getting rid of that association seemed like a very nice thing...

There was always an assocation. An element holds a list of attributes after all. Given that, throwing for

  document.head.setAttributeNode(document.body.attributes[0])

seems cheap. How did you envision getting rid of it?

Since the Attr.value setter in the current spec doesn't seem to update the associated Element's attribute, I assumed the plan was to let an Attr not known about where it came from at all, so that the setter wouldn't actually do anything useful.

Instead of me making guesses, how about you tell me how simple you think Attr can realistically become, and I can try to add Blink use counters to check specific scenarios?

An Attr object *is* an attribute. Therefore updating an Attr object's value, updates an attribute (they're the same). I see now that the specification does invoke the right algorithm for the value setter, but forgets to fill in the element argument. That's a bug.

So to answer your question: Attributes will have to remain mutable objects. However, hopefully they do not need to inherit from Node and hopefully they do not need to have children.

OK, in that case I'll close https://codereview.chromium.org/203313002/ and lower my expectations for Attr simplification :)

Philip, I changed my mind and you are correct. Could we start measuring that? Not having an association between an attribute and its element would be great. I'm updating the specification to align with your goals.

Philip, usage is too high a for a deprecation for these?

I just filed bug 26596 which would amount to surrender, keeping a connection between Attr and its Element.

After the previous round of comments I added the AttrSetValueWithElement use counter, which leaves little hope for simplification:
http://www.chromestatus.com/metrics/feature/timeline/popularity/303

If there's anything left worth trying/measuring, let me know.

*** Bug 25370 has been marked as a duplicate of this bug. ***

Done: createAttribute[NS]: https://github.com/whatwg/dom/commit/522710bc4be13d2e1d826f94c54d1de9956ec920 (Fallout is bug 26599 on abstracting out a common algorithm.)

Todo: Element.prototype.getAttributeNode[NS], Element.setAttributeNode[NS], removeAttributeNode (no NS version), NamedNodeMap.prototype.setNamedItem[NS].

As discussed on IRC it probably makes no sense to try to remove any of these as the complexity in all of them is the concept of attributes holding a reference to their element and we cannot get rid of that.

https://github.com/whatwg/dom/commit/5a881d9b5f328f8e32f0fa8e73b4e8799772cb0c

https://github.com/whatwg/dom/commit/12d011437faef5ada7b816c94aab39b10cdb2f4b

All these methods are back now :-( Sad times. Will try to look into doing a bit more consolidating of algorithms.