"Attr? setAttributeNode(Attr attr);"

[senolv]

https://dom.spec.whatwg.org/#dom-element-getattributenodens-namespace-localname-localname

Attr? setAttributeNode(Attr attr); and all the other methods like ...AttributeNode() are we now encouraged to use again? or should we prefer attributes.setNamedItem or Element.setAttribue?

[ArkadiuszMichalski]

They have been restored in one package because usage some of them was hight (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27344 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25016). In some case they are redefined and now works identically (https://github.com/whatwg/dom/issues/117). The best would be no longer use them but it's depends how you works around attrs. Using reflect, Element.setAttribute()/getAttribute()/hasAttribute()/removeAttribute() in most case are sufficient. And some other thoughts about this mess: https://annevankesteren.nl/2014/08/attributes

[senolv]

This is a really sufficient pro answer, thanks a lot.

[annevk]

Yeah, I guess I should add a note that .attributes is largely there for historical reasons, as we do with some other features.

[senolv]

May be this question could help you too.

Ok let us concentrate on using:

Element.setAttribute()/getAttribute()/hasAttribute()/removeAttribute()

But how can we determine what nodeType we have -if we need this- without using:

attributes or getAttributeNode(), since getAttribute() returns a String where .nodeType will end up with undefined?

[ArkadiuszMichalski]

As I wrote earlier it depends on how you work with attributes. But in practice attrs not participates in tree so you don't get mixed other nodes with attrs, you don't have to verify attrs. And there are plans to stop inherits Attr from Node (still discussion https://github.com/whatwg/dom/issues/102). Start thinking about the attributes not as the nodes because it was a mistake which is hard to correct now.