New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Polymer's declarative event listener names have issues with casing #4888

Open
sorvell opened this Issue Oct 17, 2017 · 4 comments

Comments

Projects
None yet
5 participants
@sorvell
Member

sorvell commented Oct 17, 2017

Polymer adds event listeners to elements declaratively using attribute names in HTML as input. For example, <a on-click="foo"> in an element template adds a listener as if the user did: <a>.addEventListener('click', e => this.foo(e)).

Since HTML attribute names are not case sensitive, supporting any casing requires a convention. For properties Polymer does dash->camel casing to map attribute names to properties names (foo-bar becomes fooBar) but it does not do this for events. Notably Polymer notification events include dashes (e.g. name-changed) so we expect lots of user code relies on this convention.

This means that it's currently not possible to declaratively listen to events like camelEvent, CAPSEvent, or PascalEvent.

We could consider introducing a new syntax to support this. A couple of options:

  • Use _ in events to indicate "remove the _ and replace the next character with uppercase".
  • Add a special attribute name like polymer-events within which the value is used to declare events like `polymer-events="lowercaseevent: handler1, cameEvent: handler2, CAPSEvent: handler3" ...

This will cause Polymer to fail ~6 tests (as of this issue) at https://custom-elements-everywhere.com/

@JosefJezek

This comment has been minimized.

Show comment
Hide comment
@JosefJezek

JosefJezek commented Apr 18, 2018

@sorvell @TimvdLippe any progress?

@TimvdLippe

This comment has been minimized.

Show comment
Hide comment
@TimvdLippe

TimvdLippe Apr 18, 2018

Contributor

No progress yet. The desired solution is still under discussion. The root issue is that this how the platform currently works and we have not decided how to address this (whether to solve it in the platform or in Polymer specifically)

Contributor

TimvdLippe commented Apr 18, 2018

No progress yet. The desired solution is still under discussion. The root issue is that this how the platform currently works and we have not decided how to address this (whether to solve it in the platform or in Polymer specifically)

@robdodson

This comment has been minimized.

Show comment
Hide comment
@robdodson

robdodson Apr 18, 2018

Contributor

After seeing that a few other libraries on custom-elements-everywhere trip over this I've started just using all lowercase event names with no separators. It looks messy, but it does match how the platform does most modern events like touchstart and pointerdown.

Contributor

robdodson commented Apr 18, 2018

After seeing that a few other libraries on custom-elements-everywhere trip over this I've started just using all lowercase event names with no separators. It looks messy, but it does match how the platform does most modern events like touchstart and pointerdown.

@esprehn

This comment has been minimized.

Show comment
Hide comment
@esprehn

esprehn Jun 13, 2018

fwiw my understanding when working on specs was that all future events will be all lowercase. Ex. See fetch observer events.

esprehn commented Jun 13, 2018

fwiw my understanding when working on specs was that all future events will be all lowercase. Ex. See fetch observer events.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment