Update element.attributes getter steps to be less vague

[lukewarlow]

The getter steps were previously quite vague simply referring to "the associated NamedNodeMap" rather than referencing the attribute list concept.

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (only for aborting and events): …
  • Node.js (only for aborting and events): …
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

I agree that it's a bit vague and can be better, but this is incorrect. A node's attribute list is a list, not a NamedNodeMap.

[lukewarlow]

https://dom.spec.whatwg.org/#concept-element-attribute

Elements also have an attribute list, which is a list exposed through a NamedNodeMap. Unless explicitly given when an element is created, its attribute list is empty.

I thought the exposed through a NamedNodeMap bit was enough? Or does the getter steps need to explicitly specify how to do that?

[lukewarlow]

Hmm looking a bit more https://dom.spec.whatwg.org/#namednodemap it seems that the NamedNodeMap has an associated element, not the other way around as the getter is currently defined. But yeah it seems exposing the list directly is wrong.

There doesn't seem to be a spec way to make a namednode map from an attribute list? Would return this's attribute list as a NamedNodeMap work? Or does it need to be more precise? It's at least a little bit clearer than currently?

[annevk]

To make it explicit you would define an element's associated attribute object (a NamedNodeMap) and then return that when appropriate.

[lukewarlow]

I'm gonna close this as I don't think it's going to be particularly clearer after any change I make