The idiomatic Polymer way to send events out from a custom element is via `fire('triggered')` or `fireAsync('triggered')` calls, with the client side intercepting them programmatically as `findView.on('triggered') = _handleFindViewEvent;` or statically in the HTML as `<spark-find-view on-triggered="{{handleFindViewEvent}}">`. I think it would be preferable to keep this convention. The main gain is that it's familiar to Polymers devs and that both ways of event interception can be used interchangeably.

On the other hand, it's certainly harder to use right now than the `onXyz` idiom, because the event ID in `...on('triggered')` is uncontrolled, unlike in `.onTriggered()`. Also, Polymer so far isn't planning to add a more declarative way of specifying what events an element can fire or forward from the contained elements, so the `fire`-based event signature is also a little harder to figure out than just scan for `onXyz` methods. However: I'm not happy with that position, and am planning to add such a declarative way through SparkWidget (hopefully to become an inspiration for Polymer).

All that is just to explain the situation now and in the near future: given that, I'd be slightly happier to see spark-find-view to use `fireAsync` here.