> When a property reflects an attribute, the attribute is the source of the data. When you set the property, it's updating the attribute. When you read from the property, it's reading the attribute.
It might depends on the implementation, and I've haven't dug into actual implementations but you pretty much need an attribute mapping (from names to values) for many things and that's how I would store it.
There might be additional optimizations or storage features for certain attributes. For example for id, since you mention this attribute specifically, you pretty much want document.getElementById() to be fast, you probably don't want it to traverse the whole DOM tree each time is called, so there's likely an additional mapping from ids to DOM elements stored somewhere per document, that is to update each time the id attribute is changed (though the spec [1] does appear to say anything about the speed characteristics of getElementById; in practice I personally certainly assume it's quasi instantaneous when using it).
For other attributes, more generally, you need to store the attribute value, not the property value (which you can cache, though), because the property value can be coerced. For instance, hidden="hidden" or hidden="HIDDEN" both lead to .hidden == true. But you need the exact value for getAttribute or for HTML serialization.
