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

becomes:

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

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.

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.

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

Acting this flippant isn’t helpful.

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

Maybe I’ve just been writing backend code for too long. I see an interface like this and I figure there’s some weird shit going on under the hood, and some kind developer from the past gave me the best and safest wrapper she could.

    // 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));

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.

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

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.

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.

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

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

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

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

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.

When and where would the average js developer learn this?