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

> it will always only be possible for authors to specify strings as values for attributes.

No, not if the spec is changed. The spec was changed in order to add Custom Elements, and it's possible to further change it to allow non-string attributes.

> But that’s the point I’m trying to make: you don’t have to do any serialization/deserialization; you can simply have a property that is not bound to an attribute.

Then, how does the server send data to the client? It sends it as a string, which needs to be deserialized. Those strings can be inside HTML attributes. Deserializing strings is still great, when it comes to parsing an initial HTML payload, but once we have things rolling on the client-side at runtime, we can completely avoid the string-based requirement (assuming we make changes to the spec).

Basically, we still need serialization/deserialization for when we want to generate actual HTML to save somewhere or two send from a server; it is great. We just need to give Custom Elements more freedom.

@sebmarkbage (one of React's creators) mentioned this [string-based problem](http://www.2ality.com/2015/08/web-component-status.html#web_components_versus_react).

Plain JavaScript properties aren't exactly the same as attributes, they are not accessible through HTML. Libraries like React ultimately send their `props` via HTML attributes (as strings) to the built-in elements in the leaf-most components. This is flawed.

This change isn't even a difficult change to make, and would bring the web forward more.

The suggestion to "just use JS properties" is only a temporary workaround, not a solution. The completely solution is to allow non-string attributes. The explicit benefits:

1. Performance increase
1. Cleaner code
1. We still have the ability to serialize/deserialize when sending/receiving HTML code to/from a server when that is what we want. For example, for serialization, a Custom Element can simply ensure that JS object stored in an attribute has a `toString` method that performs the serialization. When a Custom Element receives an arg via `setAttribute`, then if the value is a string (which can be caught in `attributeChangedCallback`), then the Custom Element can perform the conversion, and use `setAttribute` again to store the actual JS object to use during runtime. Additionally, for further performance increase, the Custom Element can store that plain JS object in a regular JS property if desired.

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