Create Multiple Instances of ResponsiveMultiLevelMenu with unique trigger ID's

[native-apps]

I would assume the best option (i may be wrong here) to have is another Option called something like triggerClassName (or ID) to trigger a target menu when using multiple instances of the plugin. Trigger should be able to work from outside of the menu container for the sake of better layout control. The reason for removing the button outside of the menu is so the menu can have a width that is separate from the button & container.

// assign the name of the trigger class
    $( '#dl-menu-2' ).dlmenu({
         animationClasses : { classin : 'dl-animate-in-2', classout : 'dl-animate-out-2' },
         backLabel: 'Back',
         useActiveItemAsLink: true,
         triggerClassName: 'dl-trigger-2'
      });    

This addition was added to the script so multiple instances could be used : #7

The reason for this request to have the trigger outside of the menu is for better control over the menu width. As you can see in this screenshot is during the animation the menu is displaying the width of the container (which is determined by how many characters are in the label).

The overall objective is to use multiple menus, and have the buttons to display inline without affecting the width of the menus. Currently the way that the trigger button is inside the container, overlapping would not work due to z-indexing issues. Currently i've achieved a temporary fix by setting a no-wrap overflow style to the container and a fixed-width to the menus which works, but you can see the menu showing a more narrow width that reflects the width of the button-trigger during animation. Also, in mobile mode, the menus are set to 100% width, but the triggers had to be absolutely positioned to be clickable, but it runs into more z-indexing issues. Relative positioning would be much more ideal.

These next two screenshots are Mobile view, and the menus are set to full-width 100% so there is no problem with the width during the animation. Also, the button were positioned absolutely for now, but relative would be ideal and can be accomplished once the buttons are working from outside the container.

[rejas]

MIght be too much in this pull request, you seem to have put all my fork-modifications in it. Lets ask the other way round: Whats missing in my fork?

[native-apps]

Considering forking this & converting this to a Polymer Element to avoid this multiple instance conflict. i will post the link if I the conversion is successful.