{"action":"created","issue":{"url":"https://api.github.com/repos/drufball/layered-apis/issues/2","repository_url":"https://api.github.com/repos/drufball/layered-apis","labels_url":"https://api.github.com/repos/drufball/layered-apis/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/drufball/layered-apis/issues/2/comments","events_url":"https://api.github.com/repos/drufball/layered-apis/issues/2/events","html_url":"https://github.com/drufball/layered-apis/issues/2","id":294151645,"number":2,"title":"Custom elements require dashes in the name","user":{"login":"domenic","id":617481,"avatar_url":"https://avatars0.githubusercontent.com/u/617481?v=4","gravatar_id":"","url":"https://api.github.com/users/domenic","html_url":"https://github.com/domenic","followers_url":"https://api.github.com/users/domenic/followers","following_url":"https://api.github.com/users/domenic/following{/other_user}","gists_url":"https://api.github.com/users/domenic/gists{/gist_id}","starred_url":"https://api.github.com/users/domenic/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/domenic/subscriptions","organizations_url":"https://api.github.com/users/domenic/orgs","repos_url":"https://api.github.com/users/domenic/repos","events_url":"https://api.github.com/users/domenic/events{/privacy}","received_events_url":"https://api.github.com/users/domenic/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-02-03T22:44:08Z","updated_at":"2018-04-26T15:15:51Z","closed_at":null,"author_association":"COLLABORATOR","body":"Requiring dashes in the name of layered API custom elements seems unfortunate, and removes the ability to build something like MathML as a layered API without changing the layered API spec to include dashes in all the element names.\r\n\r\nNone of the proposed solutions below feel particularly satisfying:\r\n\r\n- Allow layered APIs to violate namespacing requirements. This breaks one of the fundamental tenants of layered APIs, and also makes it impossible for the polyfill fallback to achieve parity.\r\n- Remove the dash requirement for custom elements in general. If layered APIs really become the way we create all new HTML elements, then we don't need to worry as much about namespace conflicts, since layered APIs must be explicitly registered. Additionally, [scoped custom element registries](https://github.com/w3c/webcomponents/issues/716) make it even easier to give a specific meaning to an un-dashed tag name without taking it over for the entire page, making this solution more feasible.\r\n\r\nIf we embrace this restriction, instead of fighting it, we have a couple routes to go\r\n\r\n- Prefixing all layered APIs with a standard prefix, e.g. `<std-infinitelist>`.\r\n- Using the unorthodox, but allowed, convention of \"ends with a dash\", e.g. `<infinitelist->`."},"comment":{"url":"https://api.github.com/repos/drufball/layered-apis/issues/comments/384678840","html_url":"https://github.com/drufball/layered-apis/issues/2#issuecomment-384678840","issue_url":"https://api.github.com/repos/drufball/layered-apis/issues/2","id":384678840,"user":{"login":"prushforth","id":2437285,"avatar_url":"https://avatars0.githubusercontent.com/u/2437285?v=4","gravatar_id":"","url":"https://api.github.com/users/prushforth","html_url":"https://github.com/prushforth","followers_url":"https://api.github.com/users/prushforth/followers","following_url":"https://api.github.com/users/prushforth/following{/other_user}","gists_url":"https://api.github.com/users/prushforth/gists{/gist_id}","starred_url":"https://api.github.com/users/prushforth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/prushforth/subscriptions","organizations_url":"https://api.github.com/users/prushforth/orgs","repos_url":"https://api.github.com/users/prushforth/repos","events_url":"https://api.github.com/users/prushforth/events{/privacy}","received_events_url":"https://api.github.com/users/prushforth/received_events","type":"User","site_admin":false},"created_at":"2018-04-26T15:15:51Z","updated_at":"2018-04-26T15:15:51Z","author_association":"NONE","body":"I interpret this in terms of [speculative polyfills](https://www.w3.org/2001/tag/doc/polyfills/#don-t-squat-on-proposed-names-in-speculative-polyfills) for a (proposed, nearly standard) but as yet unknown element.\r\n\r\n> If we embrace this restriction, instead of fighting it, we have a couple routes to go\r\n\r\nAnother possibility: Could we use the \"is\" attribute?  `<infinitelist is=\"std-infinitlist\">` ?   When the element ships, authors could remove the attribute and it would activate natively. I guess the situation where 2/4 browsers are shipping the element, could the speculative polyfill be the fallback in the 2 that haven't shipped?  The thing is still 'namespaced' by the is attribute, if that is where the browser looks for the namespace."}}
{"actor":{"display_login":"prushforth"}}