This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25016 - AttrExodus: Element.getAttributeNode
Summary: AttrExodus: Element.getAttributeNode
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
: 25370 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-03-12 02:28 UTC by Philip Jägenstedt
Modified: 2014-08-19 10:21 UTC (History)
3 users (show)

See Also:


Attachments

Description Philip Jägenstedt 2014-03-12 02:28:44 UTC
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.
Comment 1 Anne 2014-03-17 15:24:45 UTC
How about setAttributeNode() then?
Comment 2 Philip Jägenstedt 2014-03-18 08:10:58 UTC
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)?
Comment 3 Anne 2014-03-18 10:19:52 UTC
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.
Comment 4 Philip Jägenstedt 2014-03-18 17:14:20 UTC
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...
Comment 5 Anne 2014-03-18 17:21:14 UTC
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?
Comment 6 Philip Jägenstedt 2014-03-18 17:49:23 UTC
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?
Comment 7 Anne 2014-03-18 17:53:47 UTC
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.
Comment 8 Anne 2014-03-18 17:55:46 UTC
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.
Comment 9 Philip Jägenstedt 2014-03-18 18:01:39 UTC
OK, in that case I'll close https://codereview.chromium.org/203313002/ and lower my expectations for Attr simplification :)
Comment 10 Anne 2014-08-18 11:15:39 UTC
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.
Comment 11 Anne 2014-08-18 11:25:36 UTC
Philip, usage is too high a for a deprecation for these?
Comment 12 Philip Jägenstedt 2014-08-18 12:14:42 UTC
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.
Comment 13 Anne 2014-08-18 14:20:30 UTC
*** Bug 25370 has been marked as a duplicate of this bug. ***
Comment 14 Anne 2014-08-18 15:45:17 UTC
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.
Comment 16 Anne 2014-08-19 10:21:27 UTC
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.