@ErinCoughlan I got the datepicker positioning working without too much hassle, however I ran in a couple of issues that could be solved in the panel:

1. The withOffsetX and withOffsetY only accept string offsets and didn't work (nor complain) at all when supplied a number. I think that we could safely assume that if it's a number, it's in pixels and we can append the unit automatically.
2. Currently the offsets need to be known ahead of time, however it would be useful if we could pass in a function that determines the offset later. The API could look like this:

mdPanelPosition.withOffsetX(function(dimensionOfTargetElement) {
  return whateverOffsetShouldBeSet; // this can be based on the passed in dimensions.
});

Point 2 could technically be done in the open callback, however in slower browsers (e.g. IE and Edge) the adjustment is pretty visible.

@crisbeto I like the idea of allowing a function as well as assuming the 'px' if supplied a number. I think that can help prevent some user errors. Please file separate Issues for each of those bugs and we can tackle them to improve the datepicker.

@ErinCoughlan another one I ran into: at the moment, you can set the panel to close via clicking outside or pressing escape, however the datepicker also has the case where it closes the calendar if the user tabs away. Do you think it makes sense to have the "close on" keys configurable through $mdPanel or just continue handling it within the calendar?

@crisbeto I think tab makes a lot of sense. That's also used in popovers, basically if you tab past the end, focus leaves instead of being trapped.

I'm wondering two things in terms of use and API:

1. Should tab outside panel always close the panel if trapFocus is false? This is more from an accessibility point of view and perhaps it doesn't make sense to be a requirement at the panel level, but I think it's usually the case.
2. What other keys can/should close the panel? The only others I can think of it ctrl + ? For a help panel, but I'm not sure that's a common case. I ask because I'm trying to figure out how flexible this needs to be.

1. This might be tricky to get right on something as generic as the panel. That's why I'm on the fence on whether it makes sense.
2. I can't think of any off the top of my head, apart from escape and tab.

@ErinCoughlan I went back to this after #9651 got merged and I noticed a couple of issues:

1. Since the files currently get compiled in alphabetical order, the panel ends up being after most components. This means that it's hard to override it's CSS. Should we sort it to the top during builds?
2. When offsetting the position, you can't animate a transform. This is because the offsets are done with transforms as well. This may be kind of tricky, but perhaps we should have the content be compiled inside of an empty div inside the .md-panel? Then we could apply the animation to that div.