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 to receive 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):

> How do you pass data when everything is a string? 

(@sebmarkbage Your input on this would be highly appreciated!)

The criticism here (regarding strings and HTML attributes) is huge! It is a reason why people don't like the web. For example, JavaScript libraries made for animating DOM elements using CSS matrix3d (find a bunch of them [listed here](https://forums.infamous.io/c/similar-projects)) *always* complain about the awful concept of having to convert matrix number arrays into CSS matrix3d strings just so they can be converted back to numbers on the HTML-engine side. That's flawed, and we shouldn't have to do that.

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.

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

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.


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

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