HTML Attributes vs. DOM Properties

I really dislike automatic conversion between cases. There does not seem to be any established convention of how to handle uppercase acronyms across all different ecosystems that use camelCase, so

``` document.getElementById('example-div').dataset.myID == "1" ```

becomes:

``` <div id="example-div" data-my-i-d="1"></div> ```

What does `data--my-cool-attribute` supposed to become?

These are also accessible to a degree from css

I avoid all of the kebab/camel conversions by using the methods:

Element.hasAttribute('data-thing')

Element.getAttribute('data-thing')

Element.setAttribute('data-thing', '...')

Much more clear what I'm doing without the awkward translating when I inevitably have to inspect/debug in the DOM.

It’s an interesting and another way to communicate across JavaScript contexts.

By contexts here I’m not specifically talking about different Iframes — then it would be beholden to the same origin restrictions and probably have to use postmessage - but I mean in the context of a browser extension, where you create a parallel JavaScript execution context that has access to the same DOM

These are also called isolated worlds in the language of the dev tools protocol

MDN article Using data attributes describing HTML syntax, JavaScript access and CSS access, and a caveat about accessibility: https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Us...

Also https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att..., which says:

> The data-* global attributes form a class of attributes called custom data attributes, that allow proprietary information to be exchanged between the HTML and its DOM representation by scripts.

Most modern UI frameworks wouldn’t work at all if this limitation “simply” existed. Being able to store non-string values on DOM nodes is an upside.

Acting this flippant isn’t helpful.

I agree, except with the “simply” part. This is not simple at all, unless you also demand that every property can only ever be a string. Otherwise, you need to think of conversions (eg from and to numbers), and what about properties that can be set to objects? Or properies that don’t correspond to attributes at all?

I agree that any sort of convention/rule here that’d be 100% fixed would’ve been better, but it wouldn’t be simple.

This means you couldn't non-string values on DOM interfaces, and that includes methods, so most of the DOM's functionality goes out the window.

Making attributes and properties symmetric to one another would be difficult for the existing DOM API: methods like `addEventListener` are (prototype) properties on individual DOM elements, but would be nonsensical string attributes. Making your idea concrete:

    // our document is like:
    // <foo bar="asdf">
    let foo = document.querySelector('foo'); 
    console.log('bar', foo.bar); // cool, prints asdf
    foo.bar = 'nice'; // <foo> element is now <foo bar="nice">
    foo.addEventListener('some-event', e => console.log(e)); // wait, what?

    HTMLElement.addEventListener(foo, 'some-event', e => console.log(e));

all of the things in this article represent complexity and behaviours that don't add anything to anyone's lives.

A cynic might point out it added a lot of makework to the lives of its creators. And that this is why we can't have nice things like proper specs instead of 'living' ones.

When you want to pass an object to a web component without going through JSON or some other stringification procedure.

When you don’t want it coerced into a string?

I believe it's quite useful for framework developers for not required to build an abstract layer upon the already-exist-and-well-designed DOM layer to manage the state transitions or event handlings or something similar, you can't do too much if you are constrained to use only string values to encode/decode the inner state/data on the DOM.

When there is no need to appear in the HTML

Your sentence can be understood in two ways, I'll answer the question "Why use domElement.attrname instead of the corresponding domElement.setAttribute('attrname') and domElement.getAttribute('attrname')?".

It can look cleaner (matter of taste). It looks like a native JS assignment, and it's shorter.

For open and hidden, it's way more intuitive and convenient to set and get booleans than testing the existence of the corresponding HTML attribute (Still not a fan of this thing, years after having learned this).

(but maybe you meant "Why use domElement.randomprop instead of something like domElement.dataset.randomprop"?)

That's all true, but is there anything practical you can do with an attribute node, and el.attributes, that you can't do with setAttribute/getAttribute/getAttributeNames/hasAttribute?

You can't even move attribute nodes between elements. You can't event reorder attribute nodes within an element.

The object exists as long as the DOM node (the thing with the attributes) exists, so the lifecycle is the same.

The DOM node could be cloned, or go through serialisation and deserialisation, in which case it's now a completely different DOM node (although with the same attributes), so it won't have the non-default properties of the other node.

Weird comment. There's no substantial difference in behavior here (aside from the existing distinction between attributes and properties).

How does that difference manifest?

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

value is a property and an attribute. Your x is only 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...

I know they're two different things. I wouldn't bother writing an article comparing two things that are the same, even though it wouldn't take long.

This has nothing to do with web components. This is the behavior of built in HTML elements:

https://developer.mozilla.org/en-US/docs/Glossary/IDL#conten...

If anything, web components make this behavior easier to control. They represent the ground truth rather than providing a leaky abstraction. The article demonstrates this in several places.

I didn't say it was for default configuration, just configuration. The class attribute works within this system. I, as the owner of the document, configure the class attribute. I can change its configuration over time, but only I do that.

An alternative system would be where the browser adds and removes classes of its own, in response to things like hover/focus state. Thankfully it doesn't, and pseudo-classes are used instead.

Yeah, I deliberately avoided that terminology because few people outside of spec authors call them IDL attributes, and calling both things attributes is very confusing.

Consider how some browsers will remember what you input into forms when you hit the back button: I think representing this as a cached version of the modified DOM makes a lot more sense than whatever magic browsers currently use to remember it.

That would not work either:

A control's value is its internal state. As such, it might not match the user's current input.

For instance, if a user enters the word "three" into a numeric field that expects digits, the user's input would be the string "three" but the control's value would remain unchanged. Or, if a user enters the email address " awesome@example.com" (with leading whitespace) into an email field, the user's input would be the string " awesome@example.com" but the browser's UI for email fields might translate that into a value of "awesome@example.com" (without the leading whitespace).

From the standard: https://html.spec.whatwg.org/multipage/form-control-infrastr...

Yeah, I get your point. On the other hand, I prefer the serialisation of the light DOM to reflect only changes I've made as the author.

The serialisation isn't expected to represent page state. Imagine how that would work with <canvas>, or even things like event listeners.

That's why I said it should also have a pseudo class. Similar to :checked on inputs.

That’s my case across all others too, so much eassier to debut by checking the dom in an instant rather go through the debugger process

You'll see this syntax on my blog because it's what Prettier does, and I really like Prettier.

Nope, just el.propertyName. el.getProperty isn't a thing.