{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/webcomponents/issues/519","repository_url":"https://api.github.com/repos/w3c/webcomponents","labels_url":"https://api.github.com/repos/w3c/webcomponents/issues/519/labels{/name}","comments_url":"https://api.github.com/repos/w3c/webcomponents/issues/519/comments","events_url":"https://api.github.com/repos/w3c/webcomponents/issues/519/events","html_url":"https://github.com/w3c/webcomponents/issues/519","id":159304785,"number":519,"title":"[idea] Allow HTML Element attributes to accept any type of value, not just strings.","user":{"login":"trusktr","id":297678,"avatar_url":"https://avatars.githubusercontent.com/u/297678?v=3","gravatar_id":"","url":"https://api.github.com/users/trusktr","html_url":"https://github.com/trusktr","followers_url":"https://api.github.com/users/trusktr/followers","following_url":"https://api.github.com/users/trusktr/following{/other_user}","gists_url":"https://api.github.com/users/trusktr/gists{/gist_id}","starred_url":"https://api.github.com/users/trusktr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/trusktr/subscriptions","organizations_url":"https://api.github.com/users/trusktr/orgs","repos_url":"https://api.github.com/users/trusktr/repos","events_url":"https://api.github.com/users/trusktr/events{/privacy}","received_events_url":"https://api.github.com/users/trusktr/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2016-06-09T00:17:30Z","updated_at":"2016-06-12T17:29:10Z","closed_at":null,"body":"#517 covers two things: \r\n\r\n1. ability to define attributes for custom elements (and optionally specify getters/setters for those attributes)\r\n2. Ability for DOM API to accept anything, not just strings, for attributes.\r\n\r\nI'd like #517 to be about the first idea, and would like to make this issue specifically about the ability for DOM APIs like `setAttribute`/`getAttribute` to be able to accept any JavaScript values besides strings so that we can avoid performance costs from serialization/deserialization. We would be able to pass objects, arrays, numbers, instances of custom classes, etc.\r\n\r\nPlease see #517 for details (maybe I can move those details here...).\r\n\r\nFor example, imagine some error component specialized in displaying errors, who's error attribute can accept an actual instance of an `Error`:\r\n\r\n```js\r\ntry {\r\n    // ...\r\n}\r\ncatch (err) {\r\n    let errorDisplay = document.createElement('error-display')\r\n    errorDisplay.setAttribute('error', err)\r\n    document.querySelector('#error-list').appendChild(errorDisplay)\r\n}\r\n```\r\n\r\nOr, using the setter/getter feature described in #517:\r\n\r\n```js\r\ntry {\r\n    // ...\r\n}\r\ncatch (err) {\r\n    let errorDisplay = document.createElement('error-display')\r\n    errorDisplay.error = err\r\n    document.querySelector('#error-list').appendChild(errorDisplay)\r\n}\r\n```\r\n\r\nI really think making APIs easier to use (f.e. opt-in setters/getters mechanism for attributes on Custom Elements, not requiring serialization/deserialization by allowing attributes to accept values other than strings, etc), is a good goal for Web stack to have!"},"comment":{"url":"https://api.github.com/repos/w3c/webcomponents/issues/comments/225449595","html_url":"https://github.com/w3c/webcomponents/issues/519#issuecomment-225449595","issue_url":"https://api.github.com/repos/w3c/webcomponents/issues/519","id":225449595,"user":{"login":"trusktr","id":297678,"avatar_url":"https://avatars.githubusercontent.com/u/297678?v=3","gravatar_id":"","url":"https://api.github.com/users/trusktr","html_url":"https://github.com/trusktr","followers_url":"https://api.github.com/users/trusktr/followers","following_url":"https://api.github.com/users/trusktr/following{/other_user}","gists_url":"https://api.github.com/users/trusktr/gists{/gist_id}","starred_url":"https://api.github.com/users/trusktr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/trusktr/subscriptions","organizations_url":"https://api.github.com/users/trusktr/orgs","repos_url":"https://api.github.com/users/trusktr/repos","events_url":"https://api.github.com/users/trusktr/events{/privacy}","received_events_url":"https://api.github.com/users/trusktr/received_events","type":"User","site_admin":false},"created_at":"2016-06-12T17:29:10Z","updated_at":"2016-06-12T17:29:10Z","body":"> it will always only be possible for authors to specify strings as values for attributes.\r\n\r\nNo, 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.\r\n\r\n> 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.\r\n\r\nThen, 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).\r\n\r\nBasically, 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.\r\n\r\n@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).\r\n\r\nPlain 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.\r\n\r\nThis change isn't even a difficult change to make, and would bring the web forward more.\r\n\r\nThe 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:\r\n\r\n1. Performance increase\r\n1. Cleaner code\r\n1. 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."}}
{"actor":{"display_login":"trusktr"}}