By schalkneethling


2011-05-14 18:04:41 8 Comments

After the changes made in jQuery 1.6.1, I have been trying to define the difference between properties and attributes in HTML.

Looking at the list on the jQuery 1.6.1 release notes (near the bottom), it seems one can classify HTML properties and attributes as follows:

  • Properties: All which either has a boolean value or that is UA calculated such as selectedIndex.

  • Attributes: 'Attributes' that can be added to a HTML element which is neither boolean nor containing a UA generated value.

Thoughts?

5 comments

@subtleseeker 2018-12-25 17:35:07

After reading Sime Vidas's answer, I searched more and found a very straight-forward and easy-to-understand explanation in the angular docs.

HTML attribute vs. DOM property


Attributes are defined by HTML. Properties are defined by the DOM (Document Object Model).

  • A few HTML attributes have 1:1 mapping to properties. id is one example.

  • Some HTML attributes don't have corresponding properties. colspan is one example.

  • Some DOM properties don't have corresponding attributes. textContent is one example.

  • Many HTML attributes appear to map to properties ... but not in the way you might think!

That last category is confusing until you grasp this general rule:

Attributes initialize DOM properties and then they are done. Property values can change; attribute values can't.

For example, when the browser renders <input type="text" value="Bob">, it creates a corresponding DOM node with a value property initialized to "Bob".

When the user enters "Sally" into the input box, the DOM element value property becomes "Sally". But the HTML value attribute remains unchanged as you discover if you ask the input element about that attribute: input.getAttribute('value') returns "Bob".

The HTML attribute value specifies the initial value; the DOM value property is the current value.


The disabled attribute is another peculiar example. A button's disabled property is false by default so the button is enabled. When you add the disabled attribute, its presence alone initializes the button's disabled property to true so the button is disabled.

Adding and removing the disabled attribute disables and enables the button. The value of the attribute is irrelevant, which is why you cannot enable a button by writing <button disabled="false">Still Disabled</button>.

Setting the button's disabled property disables or enables the button. The value of the property matters.

The HTML attribute and the DOM property are not the same thing, even when they have the same name.

@Willem van der Veen 2018-11-28 11:41:01

Difference HTML properties and attributes:

Let's first look at the definitions of these words before evaluating what the difference is in HTML:

English definition:

  • Attributes are referring to additional information of an object.
  • Properties are describing the characteristics of an object.

In HTML context:

When the browser parses the HTML, it creates a tree data structure wich basically is an in memory representation of the HTML. It the tree data structure contains nodes which are HTML elements and text. Attributes and properties relate to this is the following manner:

  • Attributes are additional information which we can put in the HTML to initialize certain DOM properties.
  • Properties are formed when the browser parses the HTML and generates the DOM. Each of the elements in the DOM have their own set of properties which are all set by the browser. Some of these properties can have their initial value set by HTML attributes. Whenever a DOM property changes which has influence on the rendered page, the page will be immediately re rendered

It is also important to realize that the mapping of these properties is not 1 to 1. In other words, not every attribute which we give on an HTML element will have a similar named DOM property.

Furthermore have different DOM elements different properties. For example, an <input> element has a value property which is not present on a <div> property.

Example:

Let's take the following HTML document:

 <!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">  <!-- charset is a attribute -->
  <meta name="viewport" content="width=device-width"> <!-- name and content are attributes -->
  <title>JS Bin</title>
</head>
<body>
<div id="foo" class="bar foobar">hi</div> <!-- id and class are attributes -->
</body>
</html>

Then we inspect the <div>, in the JS console:

 console.dir(document.getElementById('foo'));

We see the following DOM properties (chrome devtools, not all properties shown):

html properties and attributes

  • We can see that the attribute id in the HTML is now also a id property in the DOM. The id has been initialized by the HTML (although we could change it with javascript).
  • We can see that the class attribute in the HTML has no corresponding class property (class is reserved keyword in JS). But actually 2 properties, classList and className.

@Šime Vidas 2011-05-14 18:38:55

When writing HTML source code, you can define attributes on your HTML elements. Then, once the browser parses your code, a corresponding DOM node will be created. This node is an object, and therefore it has properties.

For instance, this HTML element:

<input type="text" value="Name:">

has 2 attributes (type and value).

Once the browser parses this code, a HTMLInputElement object will be created, and this object will contain dozens of properties like: accept, accessKey, align, alt, attributes, autofocus, baseURI, checked, childElementCount, childNodes, children, classList, className, clientHeight, etc.

For a given DOM node object, properties are the properties of that object, and attributes are the elements of the attributes property of that object.

When a DOM node is created for a given HTML element, many of its properties relate to attributes with the same or similar names, but it's not a one-to-one relationship. For instance, for this HTML element:

<input id="the-input" type="text" value="Name:">

the corresponding DOM node will have id,type, and value properties (among others):

  • The id property is a reflected property for the id attribute: Getting the property reads the attribute value, and setting the property writes the attribute value. id is a pure reflected property, it doesn't modify or limit the value.

  • The type property is a reflected property for the type attribute: Getting the property reads the attribute value, and setting the property writes the attribute value. type isn't a pure reflected property because it's limited to known values (e.g., the valid types of an input). If you had <input type="foo">, then theInput.getAttribute("type") gives you "foo" but theInput.type gives you "text".

  • In contrast, the value property doesn't reflect the value attribute. Instead, it's the current value of the input. When the user manually changes the value of the input box, the value property will reflect this change. So if the user inputs "John" into the input box, then:

    theInput.value // returns "John"
    

    whereas:

    theInput.getAttribute('value') // returns "Name:"
    

    The value property reflects the current text-content inside the input box, whereas the value attribute contains the initial text-content of the value attribute from the HTML source code.

    So if you want to know what's currently inside the text-box, read the property. If you, however, want to know what the initial value of the text-box was, read the attribute. Or you can use the defaultValue property, which is a pure reflection of the value attribute:

    theInput.value                 // returns "John"
    theInput.getAttribute('value') // returns "Name:"
    theInput.defaultValue          // returns "Name:"
    

There are several properties that directly reflect their attribute (rel, id), some are direct reflections with slightly-different names (htmlFor reflects the for attribute, className reflects the class attribute), many that reflect their attribute but with restrictions/modifications (src, href, disabled, multiple), and so on. The spec covers the various kinds of reflection.

@schalkneethling 2011-05-15 17:44:38

Hey Sime, I am guessing this is pretty ambiguous, especially if you have a look over here: w3.org/TR/html4/index/attributes.html, and there is no clear cut answer. One basically needs to follow what is stated in the summary on the jQuery blog and even then, the one will map to the other and work in both instances with a slight performance hit should you incorrectly use prop when you need to use attr

@Šime Vidas 2011-05-15 19:22:28

@oss Your link refers to a list of HTML attributes. That list is not ambiguous - those are attributes.

@SKing7 2015-08-19 12:02:33

are there some documents about the relation ? @ŠimeVidas

@sstur 2016-07-02 00:40:32

Where could I find a complete list of attributes to properties (like for -> htmlFor) and similarly a list of properties that take their initial value from an attribute, yet do not reflect it (input.value). I expect this would be somewhere in the source of a library like github.com/Matt-Esch/virtual-dom but it's not really documented.

@Šime Vidas 2016-07-02 02:17:46

htmlFor and className are the only ones whose names are different from their corresponding attributes, I think. Not sure about there being a complete list; maybe we could make one, if you give me a good use case for it :)

@Dina 2016-08-17 07:18:18

@ŠimeVidas I need such a list because I need to output all properties and attributes of an element and I don't want any duplicates which might confuse whoever's getting that list (I need the properties to write rules for identifying elements on the page).

@Manu Chadha 2018-05-10 20:23:24

wonderfully explained. Thanks

@cimak 2019-06-25 11:45:56

great explanation but you didn't mention about setAttribute and how it works when no attribute was initially set. <input type="text"/> has no value attribute, but both getAttribute('value') and input.value will return empty string. Furthermore setAttribute('value', newVal') (and subsequent) will change both attribute and value/defaultValue properties. But if you now set input.value as a empty string (which already is), subsequent setAttribute calls will affect only attribute and defaultValue property, value property stays the same.

@Šime Vidas 2019-06-25 14:03:51

@cimak It seems that form fields can be in an “initial” state: As long as the field isn’t edited — either directly on the page, or by setting its .value property — the setAttribute call will effectively re-initialize the element. Interesting behavior.

@Daniel Ruf 2011-05-14 18:27:35

well these are specified by the w3c what is an attribute and what is a property http://www.w3.org/TR/SVGTiny12/attributeTable.html

but currently attr and prop are not so different and there are almost the same

but they prefer prop for some things

Summary of Preferred Usage

The .prop() method should be used for boolean attributes/properties and for properties which do not exist in html (such as window.location). All other attributes (ones you can see in the html) can and should continue to be manipulated with the .attr() method.

well actually you dont have to change something if you use attr or prop or both, both work but i saw in my own application that prop worked where atrr didnt so i took in my 1.6 app prop =)

@schalkneethling 2011-05-15 14:08:37

Hey Daniel, I did read that. Just seems there is know clear cut definition to separate the two, as some of what Sime mentions below can also be added to the HTML element, for example alt. Will continue to read some of the HTML spec and see if there is indeed a way to clearly distinguish the two in practice.

@Luzado 2018-02-05 14:25:31

That document relates to SVG not HTML.

@sibidiba 2011-06-16 19:58:12

The answers already explain how attributes and properties are handled differently, but I really would like to point out how totally insane this is. Even if it is to some extent the spec.

It is crazy, to have some of the attributes (e.g. id, class, foo, bar) to retain only one kind of value in the DOM, while some attributes (e.g. checked, selected) to retain two values; that is, the value "when it was loaded" and the value of the "dynamic state". (Isn't the DOM supposed to be to represent the state of the document to its full extent?)

It is absolutely essential, that two input fields, e.g. a text and a checkbox behave the very same way. If the text input field does not retain a separate "when it was loaded" value and the "current, dynamic" value, why does the checkbox? If the checkbox does have two values for the checked attribute, why does it not have two for its class and id attributes? If you expect to change the value of a text *input* field, and you expect the DOM (i.e. the "serialized representation") to change, and reflect this change, why on earth would you not expect the same from an input field of type checkbox on the checked attribute?

The differentiation, of "it is a boolean attribute" just does not make any sense to me, or is, at least not a sufficient reason for this.

@Samuel 2013-05-14 13:22:47

This is not an answer but I'm agree with you; it's totally insane.

@mike nelson 2013-08-07 07:02:46

Yes this concept sucks and should not been standardised so badly. This was one of the cases (like innerHTML for example) that was good in old IE and should have been adopted by the standards. Properties and attributes were synchronised wherever possible, even custom attributes, making very nice readable js dot syntax. HTML5 makes custom HTML tags first class citizens, custom attributes should also be. This feature being removed since old IE is still a real issue - we are only just now seeing a lot of corporates traditionally stuck with IE for old systems now finding them broken in IE10.

@Tim Down 2013-10-23 10:03:17

It's not insane. You've misunderstood. The checked attribute is represented by the defaultChecked property (likewise for a text input the value attribute is represented by the defaultValue property). A second property, checked, is required to represent whether the checkbox is checked because this is an intrinsic part of a checkbox's functionality: it is interactive and can be changed (and reset to the default, if a form reset button is present) by the user, in a way that another attribute such as id is not. It's nothing to do with the fact that it's a boolean attribute.

@pedz 2014-07-08 02:23:10

@TimDown -- Thanks. That actually got me over the WTF? hump.

@dallin 2015-08-05 23:18:47

@TimDown I still feel it is "insane" because any logical approach would make the property name and the attribute name match, or at least not have an attribute name and property name match that are not related (i.e. the checked attribute refers to the defaultChecked property while the checked property is unrelated). In fact, the logical approach that everyone assumes is the case at the start would be to not separate the attributes and properties at all. Attributes should not be immutable, but should always reflect the property values. There shouldn't be a distinction between the two.

@Ahmad Alfy 2018-10-28 18:53:35

It's not insane if you understand why it is forged this way. It was made like this because forms have a reset method and that reset method need to read the original data from the HTML attribute.

@Bhagvat Lande 2019-02-17 12:54:21

I am agreed with you , but this concepts having huge benefits , modern Java Script framework like AngularJs/Angular,Reactjs and many more are built with this .

Related Questions

Sponsored Content

8 Answered Questions

[SOLVED] What is the difference between Bower and npm?

  • 2013-09-05 16:53:19
  • Games Brainiac
  • 306956 View
  • 1700 Score
  • 8 Answer
  • Tags:   javascript npm bower

27 Answered Questions

[SOLVED] What does "use strict" do in JavaScript, and what is the reasoning behind it?

9 Answered Questions

[SOLVED] Why does HTML think “chucknorris” is a color?

69 Answered Questions

[SOLVED] What is the most efficient way to deep clone an object in JavaScript?

22 Answered Questions

[SOLVED] What are valid values for the id attribute in HTML?

  • 2008-09-16 09:08:52
  • Mr Shark
  • 412312 View
  • 1887 Score
  • 22 Answer
  • Tags:   html

26 Answered Questions

[SOLVED] What's the difference between the atomic and nonatomic attributes?

32 Answered Questions

[SOLVED] What is the difference between a field and a property?

  • 2008-11-17 08:41:38
  • Anonymous
  • 391074 View
  • 991 Score
  • 32 Answer
  • Tags:   c# properties field

32 Answered Questions

[SOLVED] What's the difference between using "let" and "var"?

38 Answered Questions

[SOLVED] How do I remove a property from a JavaScript object?

20 Answered Questions

[SOLVED] What is the difference between call and apply?

Sponsored Content