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

For primitive types, serde isn't hard. It could even be part of a simple spec. Numbers, Dates, String[], Number[], Date[]. Edit: Or it could just be JSON.

For complex types it is. But why and when do you need to store complex types in the DOM? Isn't that always a bad idea?

I'm a seasoned web dev, but haven't been working on complex frontend apps, because I believe complexity and frontend web don't go together. So I may very well miss some use-cases.

For custom elements you may want to store data or methods that modify the element’s behavior.

Methods as in callbacks? So, code? Do you then store a closure or such? Or a pointer to one (i.e. the function/name)? And how or what data would modify behaviour?

As said: I'm unfamiliar with these concepts as I actively try to avoid them :)

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

How do you read it in the web component afterwards? Passing it via property sounds quite useful.

Web components are implemented using custom elements which are just plain JS classes that extend the HTMLElement class, so you would access the property the same way you would access a property in a normal JS class.

Thanks understood, that makes it quite simple and intuitive thinking about it.

The author of the thread is arguing against properties.

Yes, I know. I wasn't making a prescriptive comment about whether or not developers should use properties, I was just making a descriptive comment about how properties are accessed in a web component to answer the specific question politelemon asked.

Event listeners? Image data?

element.srcObject is very useful for <video> elements when the srcObject is a direct stream feed from the camera. I don’t even know how I would go about passing that as a string attribute.

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

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"?)

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