0

I am trying to understand the short entry on IDL in the MDN Glossary.

In particular, I am struggling with the behavior described in the 4th paragraph under the "Content versus IDL attributes" header.

Most of the time, IDL attributes will return their values as they are really used. For example, the default type for <input> elements is "text", so if you set input.type="foobar", the <input> element will be of type text (in the appearance and the behavior) but the "type" content attribute's value will be "foobar". However, the type IDL attribute will return the string "text".

I will list a series of questions, along with my current 'informed guesses' in bulletpoints. I would like to either confirm my understanding, or expose my lack of it. Any input, clarification, or critique is appreciated (the questions may be fully off-base).

What does 'their values as they are really used' mean in this context (their default value [e.g, "text"], or the value set in a specific context [e.g, "foobar"])?

  • default (in the example, "test") - hence the final sentence of the quote.

Is the <input> element's type an IDL or content attribute?

  • (technically both? but inasmuch as we access it through input.type it is an) IDL attribute

If IDL attributes are set using element.foo, doesn't input.type qualify as setting an IDL attribute (in which case the "type" content attribute should not be "foobar")?

  • This misses a key behavior of IDL attributes w.r.t. content attributes: content atttributes can be set through IDL attributes, while leaving the IDL attribute itself unchanged.
Improve this question

1 Answer 1

Reset to default
1

What does 'their values as they are really used' mean in this context (their default value [e.g, "text"], or the value set in a specific context [e.g, "foobar"])?

The type isn't just a field to store some value, right? It's an important characteristic of the <input /> element and should be understood and used by the browser. Browser will render different control and/or it's behavior depending on that field (compare <input type="text" />, <input type="file" />, <input type="date" />).

Having variety of browsers with different feature sets, they're not stopping working when receive unknown values. In case of input's type attribute, they will just fallback to the text when given value is unknown.

So text will be the really used one, while foobar is still stored as it was originally set and can be accessed via attributes.

Is the element's type an IDL or content attribute?

You're right, it's both: IDL and content attribute, depending on how it is accessed. It stores the original value and you can access it via element.attributes['type'] and you can get actual (working / supported) value via IDL.

If IDL attributes are set using element.foo, doesn't input.type qualify as setting an IDL attribute (in which case the "type" content attribute should not be "foobar")?

It is, but IDL attribute isn't just a box where you can put whatever you want. It will take your value, store to the attributes dictionary and try to use with various validations and fallbacks. In case it can't use that value, it will use one of the fallback options it finds the best.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

cheers. to reiterate a couple things: (1) regardless of if the value is supported, any set value is stored in the attributes property of the corresponding DOM object? (2) if we instead use input.type="file", should we expect to see the IDL attribute change properly to "file" (as opposed to "foobar" which is invalid and leaves the IDL attribute as the default "text")? (3) the attributes property of a DOM object does not have entries corresponding to their IDL attributes? (can we 'get' an IDL attribute?)
@shea (1) yes (2) absolutely. If you set some valid value (e.g. input.type = "file") you'll see it via both content and IDL attributes. And when you set something invalid it will set it to the default, not leave as is. So if input had type="file" and you set it to foobar, accessing input.type you'll get text, not file. (3) attributes is how you can access content attributes, they represent what was set to the element. <input /> won't have anything in attributes, but you can get any of IDL (e.g. input.type will still return the default text).

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.