Re: [w3c/webcomponents] [idea] Allow HTML Element attributes to accept any type of value, not just strings. (#519)

> I think libraries/frameworks should interact directly with the property instead of with the attribute, having the attributeChangedCallback only be used to allow authors to provide a value to the property from HTML.

That would work, but it's not a convention that everyone is guaranteed to follow. On the other hand, it is guaranteed that `getAttribute` *will always* be used to get values from the original HTML, and likewise pairing `setAttribute` with that guarantee would be something that everyone would be able to follow.

As @sebmarkbage mentioned, they try to use properties when possible in React, and setAttribute is a fallback. If we make the fallback (setAttribute) work with non-string values, libraries wouldn't need to have a runtime whitelist of what properties to use and when to fall back on setAttribute. HTML element attributes are the guaranteed description of what data an characterizes an element, so I think relying on those is better than properties because properties aren't guaranteed to exist, but attributes are. Servers can't set properties, they can only set attributes, and I think that having a client-side library depend on attributes will make interop between server and client better without having to use (possibly erroneous) whitelists.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/519#issuecomment-225454611