Use DOM for marker content (allows listeners to work)

[tst-dhudlow]

See #288

May not be exactly the right solution, but it does seem to work.

[thexs-dev]

Any idea when this fix will be released? Or how to use it within a project (bower path, version)? Thanks

[jesusabarca]

This fixed my issue :)

[ebidel]

@tst-dhudlow can you take a look at my comments? Interested in getting this merged.

[thexs-dev]

I have been using the modified code and it's working fine for my purpose of having binding and interaction within the info-window I have found though, a couple of issues as follow Apologies in advance for the format I am using, but I don't know how to it better

1. When using a paper-dropdown-menu element within the info-window, if you pan/zoom, then click on a market and open the dropdown, the map applies back the fit-to-markers (resize, center). This happens with Polymer versions 1.4.0 and 1.5.0 To avoid this issue I moved from a paper-dropdown-menu to a paper-dialog with a paper-dropdown-menu. With that the map stays where it was when opening the dialog
2. The second issue only happens with version 1.5.0. In either case, using a paper-dropdown-menu or a paper-dialog, after I click on a marker I would get errors in the console as follow, when opening the info-window, Uncaught TypeError: Cannot read property 'addEventListener' of null (iron-a11y-keys-behavior.html:404), and when closing the info-window, Uncaught TypeError: Cannot read property 'removeEventListener' of null (iron-a11y-keys-behavior.html:421). Other than the error messages, the app seems to be working fine.

This is the code I am using, in case you want to reproduce these issues. https://jsfiddle.net/9s9yx8j1/ Just replace the google-map with the modified version of google-map-marker, and try with Polymer version 1.5.0

[mlisook]

@tst-dhudlow I'm sorry, but the concept of the wrapping div around the content tag is just not going to work. Its not just plain text nodes, either, as the earlier dialog implied.

I'll admit that when I first saw this I thought it was clever, brilliant even. Now, however, I know more than I ever thought I wanted to about shadow.

See this JS Bin with the chrome browser to illustrate.

The div around the content tag becomes part of the shadow (or shady) dom. Inside the content are the light dom. The children of a web component element are its light dom, not its shadow + light dom. When this works under shady it is because the polyfill assembles all the elements in the regular dom and it (the polyfill) has no way to prevent a native function like children from operating as it always does in regular dom. In native shadow dom that div is just not in the source tree of the regular dom, so, children[0] refers to the first element inside the content tag.

With chrome's support for shadow dom pretty robust, the Polymer team is recommending to run with shadow as the default (e.g. see what's generated by the polymer cli) and just fall back to shady if the browser doesn't support shadow. We're just not going to be able to have a fix that doesn't work in shadow.

[ebidel]

I think my comments in https://github.com/GoogleWebComponents/google-map/pull/294#discussion_r67224111 still need to be addressed.

[mlisook]

@ebidel The method in your comment from last week will work to allow the content of a child, like the google-map-marker, to be moved into a parent's shadow dom (google-map).

I set up a JS Bin with an ultra simplified demo (ultra, like not even a google-map). It is analogous though. Infowindow creates a div inside the map div for its styled contents, then translates that into place within the map div. The JS Bin works on both shadow and shady.

What I don't know, however, is the inner workings of Infowindow. Based on the last comment by @Fausto-theXS and my comment 11 days ago about ink bearing / ripple elements, it seems like the Infowindow has its own content / mutation observer. It may not be compatible with the types of action that happen in material design elements. In the sample I attached last week, it can be seen that the content of the infowindow has its height and width set to 0 when the ripple fires. I have no idea why, but the elements inside do go to 0 x 0 on ripple. Its also unclear what effect styling of the content would have on moving the elements from light dom to shadow/shady. Especially in shadow, the classes from outside wouldn't apply after moving, right?

This will be extremely difficult to test.

[mlisook]

I modified that last JS Bin to include a style on one of the elements moving. The style is quashed under shadow dom, but shows under shady, as I suspected.

[tst-dhudlow]

@mlisook I can try your method to move the content and test it in shadow to see if it works, but if you know what it should look like already, feel free to PR into my branch and I'll merge it so it goes into this PR.

[mlisook]

@tst-dhudlow I can do that (PR into your branch), but I'm in an area with only sketchy internet access until after the holiday.

With that it should be possible to support everything but styles. As far as I can tell there's no way the Infowindow will support style classes under shadow dom. To have full support we'd have to go big - not using infowindow at all. That would involve making google-map-marker a visual component that floats its content over the map on demand (like the paper-map-info, (or see demo), I did to get my current project working), but styling as close as possible to infowindow and probably duck typing the infowindow public interface. Not sure if management would entertain that, @ebidel your thoughts?

[ebidel]

I'm hesitate to support custom info windows. It's not a common case. Could you not add custom info windows yourself with the underlying api calls?

On Thu, Jun 30, 2016, 8:06 AM Murray Lisook [email protected] wrote:

@tst-dhudlow https://github.com/tst-dhudlow I can do that (PR into your branch), but I'm in an area with only sketchy internet access until after the holiday.

With that it should be possible to support everything but styles. As far as I can tell there's no way the Infowindow will support style classes under shadow dom. To have full support we'd have to go big - not using infowindow at all. That would involve making google-map-marker a visual component that floats its content over the map on demand (like the paper-map-info https://github.com/mlisook/paper-map-info, (or see demo https://mlisook.github.io/paper-map-info/), I did to get my current project working), but styling as close as possible to infowindow and probably duck typing the infowindow public interface. Not sure if management would entertain that, @ebidel https://github.com/ebidel your thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GoogleWebComponents/google-map/pull/294#issuecomment-229652132, or mute the thread https://github.com/notifications/unsubscribe/AAOigBBEucGJ_UYaCOyFtecEytzcfNT-ks5qQ79agaJpZM4IWJF9 .

[thexs-dev]

@ebidel Is there a "Polymeric" way of doing that? I mean a single reusable Infowindow object (new this.api.InfoWindow()), that I can invoke on-google-map-marker-click event and open it with a paper-card element as content?

I'd rather do that than having thousands of infowindows in the DOM, when the user would click on just a few of them -- a huge performance improvement

[mlisook]

@Fausto-theXS the reusable window that is invoked on-google-map-marker-click is how the paper-map-info (demo) works.

[mlisook]

@ebidel I understand and agree completely.

I don't think the styles thing is as important as events either, although it is outside developer's expectations, since something as straightforward as:

<style>
    foo {
      color: red;
    }
</style>
<google-map latitude="37.779" longitude="-122.3892" >
  <google-map-marker latitude="37.779" longitude="-122.3892">
    <span class="foo">Go Giants!</span>
  </google-map-marker>
</google-map>

Will never work to style the text under shadow dom with the native infowindow (but does under shady).

[jonadeline]

Hi guys, I developed custom-gmap-infowindow element to customize the infowindow. It's based on @mlisook plastic-map-info. Do not hesitate to contribute to enhance the thing.