25016 2014-03-12 02:28:44 +0000 AttrExodus: Element.getAttributeNode 2014-08-19 10:21:27 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC All RESOLVED FIXED P2 normal --- 1 philipj annevk ehsan mike www-dom public-webapps-bugzilla oldest_to_newest 102226 0 philipj 2014-03-12 02:28:44 +0000 http://www.chromestatus.com/metrics/feature/timeline/popularity/107 Usage is too high to make removal realistic. Simplification with a dumber Attr interface is hopefully still possible. 102454 1 annevk 2014-03-17 15:24:45 +0000 How about setAttributeNode() then? 102534 2 philipj 2014-03-18 08:10:58 +0000 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)? 102540 3 annevk 2014-03-18 10:19:52 +0000 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. 102576 4 philipj 2014-03-18 17:14:20 +0000 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... 102577 5 annevk 2014-03-18 17:21:14 +0000 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? 102584 6 philipj 2014-03-18 17:49:23 +0000 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? 102586 7 annevk 2014-03-18 17:53:47 +0000 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. 102587 8 annevk 2014-03-18 17:55:46 +0000 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. 102590 9 philipj 2014-03-18 18:01:39 +0000 OK, in that case I'll close https://codereview.chromium.org/203313002/ and lower my expectations for Attr simplification :) 110222 10 annevk 2014-08-18 11:15:39 +0000 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. 110225 11 annevk 2014-08-18 11:25:36 +0000 Philip, usage is too high a for a deprecation for these? 110228 12 philipj 2014-08-18 12:14:42 +0000 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. 110239 13 annevk 2014-08-18 14:20:30 +0000 *** Bug 25370 has been marked as a duplicate of this bug. *** 110244 14 annevk 2014-08-18 15:45:17 +0000 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. 110246 15 annevk 2014-08-18 17:36:49 +0000 https://github.com/whatwg/dom/commit/5a881d9b5f328f8e32f0fa8e73b4e8799772cb0c 110288 16 annevk 2014-08-19 10:21:27 +0000 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.