Prevent event bubbling in polyfill

[stefanjudis]

When using polymer components and firing events, the original events are still bubbling up. For example when I create a custom element which includes an input field and I define my custom element to trigger a change event on change of this included input field the custom element will trigger 'change' twice.

For example we create this element:

<polymer-element name="sj-checkbox" attributes="size">
  <template>
    <style>
    /* all my styles here */
    </style>
    <div class="switch {{size}}">
      <div class="switch__circle">
          <input id="switcher" class="switch__input" type="checkbox" on-change="changeHandler" checked="checked">
          <div class="switch__innerCircles"></div>
          <label class="switch__label" for="switcher">Switch me!!!</label>
        </div>
      </div>
    </div>
  </template>
  <script>
    Polymer( 'sj-checkbox', {
      size: 'medium',
      changeHandler: function( event ) {
        this.fire(
          'change',
          {
            id: event.target.id
          }
        );
      }
    } );
  </script>
</polymer-element>

and attach this event handler:

<script>
  ( function( document ) {
      var switchList    = document.getElementById( 'switchesComponents' );

      switchList.addEventListener( 'change', changeHandler, false );

      function changeHandler( event ) {
          var notification = document.getElementById( 'switchesComponentsNotifications' );

          notification.innerHTML = '!!! ' + event.detail.id +' switched !!!';
      }
  } )( document );
</script>

The event handler will be triggered two times. Once for the input element that should be hidden inside of the shadow DOM (but isn't because of the not supporting browser) and once for the change event of the new custom element.

[sjmiles]

Call event.stopPropagation() inside of your sj-checkbox's changeHandler.

[stefanjudis]

Yes, true. That would work, but shouldn't polymer keep track of that somehow?

I mean, I shouldn't be forced to stop propagation only for the fallback case. If it works for supporting browsers, it should be the job of the dependent polyfill to prevent the same behaviour in fallback case.

Not a big deal for me, but a thing of principles though. 😉

[sjmiles]

Ok, I wasn't understanding that when you wrote 'fallback', you mean
polyfill (fwiw, there are other things in ShadowDOM called 'fallback').

Yes, the polyfills and the native semantics should behave the same.

For the majority of (bubbling) events, propagation is important, and
control is given to the user. In those cases, stopPropagation is the
answer.

To be honest, I wasn't aware that the spec has a list of 'non-propagating'
events at Shadow boundaries. I don't understand where that came from so
I'll have to talk to the implementors.

On Wed, Sep 25, 2013 at 12:36 PM, Stefan Judis [email protected]:

Yes, true. That would work, but shouldn't polymer keep track of that
somehow?

I mean, I shouldn't be forced to stop propagation only for the fallback
case. If it works for supporting browsers, it should be the job of the
dependent polyfill to prevent the same behaviour in fallback case.

Not a big deal for me, but a thing of principles though. [image: 😉]

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/296#issuecomment-25117909
.

[stefanjudis]

Okay - will read about this "other things in Shadow DOM called 'fallback'". 😉

And thanks for investigating.

[sjmiles]

Sorry for being vague about 'fallback', I don't think it's relevant or I would have been clearer. There are references to 'fallback' content here: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html.

Thanks for bringing this problem to our attention. :)

[dfreedm]

Should be fixed as of googlearchive/ShadowDOM@b04881f