Comment by mg | Hacker News Reader

Comment by mg | Hacker News Reader

The gist of it seems to be that attributes sometimes behave like properties.

Setting 3 attributes on an html element:

    <input id=good x=morning value=hn>

Then logging 3 properties with the same names:

    <script>
        e = document.querySelector('input');
        console.log(e.id); 
        console.log(e.x);
        console.log(e.value);
    </script>

Will output

    good
    undefined
    hn

I'm not sure why. The article says it's because "Element has an id getter & setter that 'reflects' the id attribute". Which sounds logical. But MDN does not mention a getter function for "value" for example:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

It even calls "value" a property AND an attribute: "...access the respective HTMLInputElement object's value property. The value attribute is always..."

And HTMLInputElement lists "value" under "properties":

https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl...

So maybe it's not as easy. Maybe <element some=thing> sometimes sets a property and sometimes sets an attribute.

There are two different objects here. In HTML, you have an <input> element with a "value" attribute [0]. An <input> element also has an internal value, which is initialized using the "value" attribute.

In JavaScript, you have an HTMLInputElement with a "value" property [1]. Getting the "value" property of an HTMLInputElement reads from its <input> element's internal value, and setting the "value" property of an HTMLInputElement writes to its <input> element's internal value. (The "value" attribute remains unchanged, since it is only used for initialization.) The DOM object is just modeling the actual element.

In general, the property on the DOM object will not exist unless it is specifically documented to, such as "id" and "value".

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl...

It's a matter of getters and setters being defined for well-known attributes on the DOM element indeed. This is why it doesn't work of 'x', the 'x' HTML attribute doesn't have a getter and a setter defined on the 'x' property of the DOM element (You can try defining custom getters and setters with defineProperty that call getAttribute and setAttribute if you want to experiment - I haven't experimented but I expect this to work and I think that's how predefined properties work).

For 'value', MDN says:

> it can be altered or retrieved at any time using JavaScript to access the respective HTMLInputElement object's value property

While it doesn't say it is implemented using a setter and a getter (I suspect because it doesn't need to go into such details that are confusing if you don't know this mechanism), I think this is what it implies. I believe this can be found in the spec of the Javascript implementation of DOM.

So it is as "easy" as it looks (note my phrasing totally allows you to find it looks difficult): for well-known HTML attributes, there are usually getters and setters for the corresponding DOM property. Usually, it's the same string, sometimes there's a conversion, for instance with booleans (for the open and the hidden attributes).

So is "id" stored as a property or as an attribute?

Yes.

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.

[1] https://dom.spec.whatwg.org/#ref-for-dom-nonelementparentnod...

An attribute. From https://jakearchibald.com/2024/attributes-vs-properties/#ref...

> 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.

value is different. From https://jakearchibald.com/2024/attributes-vs-properties/#val...

> the value property does not reflect the value attribute. Instead, the defaultValue property reflects the value attribute.

Follow the link for the full explanation.

value is a property and an attribute. Your x is only an attribute.

Reply on news.ycombinator.com