Allow for something other than MDL icons for the menu button.

[Lattyware]

I am currently porting a project (massivedecks) to use elm-mdl (from muicss integrated manually) - we used fontawesome for icons in the past, and the material design icon set is missing a number of icons used, so I have stuck with fontawesome and simply not included the MDL icons - that all seems fine and is working well, except the menu, which appears to only have support for MDL icons for the menu button.

It would unblock us to allow arbitrary content for the menu button as a replacement for the icon (I can also see this holding value for those that want text instead of an icon, for example). Otherwise we have to include two icon fonts, when one would do fine.

[OvermindDL1]

As a work-around for now in your site CSS you can override the those to make them invisible and add an :after element that adds whatever you need for a font (via some parent div with, say, a data-myicon="somefontawesome" value or so, can set it with something like:

some[data-myicon] > selector {
  make it invisible however you want, like width=0px should work and put the :after in the right place
}

some[data-myicon] > selector:after {
  content: attr(data-badge);
}

I doubt that is the right setting or if the attr works from a parent, but there is always some way to do it via css.

[debois]

@Lattyware: This is something we'd like to do, but a little time might pass before anyone gets around to it. (We'd take a PR, of course.)

In the short term, is @OvermindDL1's workaround an option for you?

@aforemny: Is this something you'd be interested in looking at?

[aforemny]

@debois Yes I am! :)

[aforemny]

In the mean-time, here is a more elaborate example of @OvermindDL1's work-around.

You hide the menu's icon using CSS and add a pseudo element that references the FontAwesome icon by it's UTF-8 code and apply the .fa styling.

[aforemny]

When allowing menus to be opened by arbitrary elements, the tooltip implementation comes to mind. Menus are different from tooltips in that on opening they are decoding information from the element that opens them as well as the menu itself.

However, if we are requiring menus to be the next sibling of whatever opens them, the current implementation adapts easily. I hesitated to implement menus like this because of this implicit assumption. Do you agree that it is sensible for menus to be the next sibling of whatever opens them? If so, I will go ahead and implement that.

[debois]

Yes! Very neat. I made some comments directly on the commit.

[OvermindDL1]

I personally would very much like Menu and Tooltip to have a similar API, either a wrapper (which I am not big on) like Menu, or sibling elements like Tooltip (though make the documentation very loud about them needing to be immediate siblings, and raise messages if possible to determine that in code too (not easy if so).

[Lattyware]

@debois I'll probably just hold off on the transition over using the workaround - it's not being done out of necessity, just to move away from some custom code elm-mdl could replace.

Great to see the activity on this project - looks like this is being handled already, but I'll look for chances to contribute myself if and when I get the time.