search

divshot / ele-web

Ele, the in-browser development environment for Web Components.
https://ele.io/
MIT License
42 stars 9 forks source link

Dashless element name error duplicates the preview iframe #22

Open fastdivision opened 10 years ago

fastdivision commented 10 years ago

We should catch the error:

Uncaught SyntaxError: Failed to execute 'registerElement' on 'Document': Registration failed for type 'sarcasm'. The type name is invalid.

And tell beginners they need a dash in their element name. Also, don't duplicate the iframe on an error.

bcherny commented 9 years ago

+1 I just got Uncaught SyntaxError: Failed to execute 'registerElement' on 'Document': Registration failed for type 'list'. The type name is invalid.. Having a more specific error (maybe Polymer requires that all component names contain a dash character) would have been nice.

The rule that names must contain a dash is unusual, why does polymer impose that constraint?

mbleigh commented 9 years ago

@eighttrackmind It's not Polymer, it's the Web Components spec. The idea is that by requiring a dash in the name (which no native elements have) there's no chance of accidentally registering over an existing tag. An interesting and pragmatic solution, but can bite you if you're unaware.

bcherny commented 9 years ago

That's really interesting, thanks for the quick response.

It's clever but seems like an odd constraint - to avoid overloading native elements a custom element must have a dash in its name, but to avoid overwriting native attributes custom attributes should start with data-. It also makes it very difficult to introduce dash-cased native tag names in the future, should the w3c/vendors decide to go down that route.

It also doesn't solve the problem of name collisions. Since web components are imported into a global namespace, there will almost certainly be collisions for large applications with lots of 3rd party components (if I understand how web components work correctly). The dash-case requirement is seems like a pretty gnarly workaround that makes this issue a bit less likely to occur.

I feel like a more normalized and scalable solution would be to overload XML namespaces, so my custom tag could be <abc:list></abc:list>. Albeit it's a bit uglier.

Alternatively, components could be explicitly scoped like imports in most languages, eg. <list rel="import" href="/components/list.html"></list>.

mbleigh commented 9 years ago

There are definitely some interesting edge issues around imports, namespace collisions, etc. Once you get used to the dashes, though, it feels pretty natural. I was a bit surprised that they didn't go for XML namespaces, but there's probably a good reason for it.